by Greg Nawrocki

Three Networking / Grid computing questions for Vint Cerf

news
Sep 13, 20054 mins

A few months ago (when he was still at MCI), we asked Vint Cerf a few network-specific questions about Grid. Here’s what he had to say:

1. A recent Nemertes study said that 62% of organizations are using MPLS today or plan to deploy it. We’ve seen a ton of industry interest in the convergence of web services and Grid services — but there has been very little discussion (at least in the news) about the connection between Grid computing and MPLS. Is there a connection? Does the MPLS architecture have any interesting implications for Grid, in your opinion?

The notion of “deploying MPLS” is a little odd. MPLS is an infrastructure technology. Typically, users don’t see it since the typical interface to an MPLS-enabled network is still IP. In that sense, the use of MPLS is not unlike earlier use of Frame Relay and ATM to transport IP packets. MPLS, like its earlier counterparts, is used for two purposes: creation of managed underlying infrastructure for traffic engineering of IP-based networks and to separate virtual private networks from each other). MPLS uses a two layer stacked-label design to accomplish these tasks, at least in some implementations.

The value of MPLS is that it runs at the same speeds as IP these days, unlike Frame Relay and ATM that both showed some inability to scale up to the increasingly high speeds of the Internet backbones. However, one should be careful about assuming that MPLS will continue to scale without limit. It could be that it, too, will find itself running out of capacity, only to be replaced by optical packet switching or some other technology yet to be invented.

For that reason, it is important to take care, architecturally, to maintain a common IP interface at the edge of the Internet (or virtual private networks) so as to allow migration from one underlying infrastructure to another.

2. In a recent InfoWorld article, you highlighted some of the key enhancements in IPv6:

-facilitates identification all the way to the end device

-auto discovery and configuration -facilitates apps that require fast, plug-and-play connections among peer devices on the edge of the network

-eliminates the need for NAT (network address translation)

There seem to be strong similarities between these new improvements in IPv6 — and the areas that the Grid community is working hardest to address (identification/authorization, application performance, etc.). What can/should the Grid community take into consideration (in your opinion) with respect to making best use of new directions in IPv6 for the Grid environment?

In most ways, the Grid is a much higher layer construct than the IPv6 Internet layer. Consequently, it is important to take some care not to bind Grid overly closely to the network layer of the Internet architecture. Grid may be able to derive some important utility when running over IPv6 (authentication, dynamic reconfiguration, mobility) but for the same reason as the cautionary notes above concerning MPLS. IPv6 may someday have to be replaced with something else and one would want the Grid structure to survive operation in a mixed environment. In fact, we want GRID to work in mixed IPv4/IPv6 environments, too, so we should be cautious about binding Grid too closely to either one. The identifiers that Grid should rely on for identification of sources and the like ought to be at higher levels of abstraction than IP addresses, in my opinion.

3. Do you see any possible future directions for how resources (both hardware and software) are registered, discovered and identified in Grid environments? Will there be a next-gen resource registry (like the DNS on steroids)?

There certainly could be a higher level of resource registration. I would expect that registration of services would want to be bound to an identifier space that is well above IP addresses. These identifiers could be found to IP addresses dynamically or they could be bound to domain names that are in turn bound to IP addresses. But one would want the identifiers to survive changes in the IP layer. Examples of such bindings can already be found in instant messaging services such as ICQ, MSN, AIM and the like. There, the instant messaging identifiers are bound dynamically to the IP addresses of the clients. These change with time and the systems are generally very adaptive to these changes. I think the Grid environment needs to have similar flexibility. One might turn to the Object Identifier community for some insights into the possible uses of new classes of identifiers for service and data objects.