Overview

The key idea behind AVES is to virtualize non-IP hosts by a set of IP addresses assigned to waypoints. The waypoints then act as relays to connect IP hosts to non-IP hosts. Figure 3 illustrates this idea. In this example, there are two reusable-IP networks connected to the IP Internet, and the reusable-IP hosts $B$ and $C$ are virtualized by the IP addresses of waypoints $W_2$ and $W_4$. As a result, IP initiators $A$ and $D$ can connect to responders $B$ and $C$ through the waypoints. Note that the bindings between non-IP hosts and waypoint IP addresses are initiator-specific. That is, each IP initiator has its own view. In our example, to $A$, $B$ is bound to $IP_{W_2}$ and $C$ is bound to $IP_{W_4}$. On the other hand, to $D$, $B$ is bound to $IP_{W_4}$ and $C$ is bound to $IP_{W_2}$. This ability to simultaneously bind an unlimited number of non-IP hosts to a waypoint IP address allows AVES to provide connectivity to an unlimited number of non-IP hosts. Another point worth noting is that the number of waypoint IP addresses only limits the number of non-IP hosts that each IP initiator can simultaneously connect to. Thus, for all practical proposes AVES requires only a small number of IP addresses, say a few tens, to achieve high connectivity.

Figure 3: Overview of AVES

More precisely, to implement AVES, a service provider deploys a small number of IP waypoints ($W_1$ - $W_4$) and AVES-aware DNS servers (not shown) for the reusable-IP domains. The waypoints have the following characteristics: (1) Waypoints are assigned IP addresses, possibly more than one per waypoint, in which case each IP address is logically a distinct waypoint. Here we assume only one IP address is assigned per waypoint. (2) Waypoints are capable of performing address (and protocol, in the case of IPv6) translation, they serve as relays for traffic crossing heterogeneous address spaces. (3) Because waypoints are network agents, they can be deployed non-intrusively without global coordination. Under AVES, for IP initiator $A$ to connect to reusable-IP responder $B$, it first performs a DNS name lookup for $B$; this marks the beginning of a session. The name lookup operation serves two purposes. First, the DNS name will uniquely identify the responder even though it does not have a unique IP address. Second, when the DNS query is processed by an AVES-aware DNS server, the non-IP host is bound to the IP address of a chosen waypoint, in this case $IP_{W_2}$. Again, this binding is initiator-specific so that a waypoint IP address can be bound to multiple non-IP hosts simultaneously. Instructions are then sent by the AVES-aware DNS server to $W_2$ so that it can correctly relay packets. $IP_{W_2}$ is returned to $A$ in the DNS reply with the time-to-live field set to zero (i.e. no caching of IP address records is allowed; however name server records can be cached). The session is now established, and $A$ can open arbitrary connections to $B$ through $W_2$. A session is terminated when a timeout occurs after a period of inactivity. Afterwards, an initiator can regain connectivity by starting another session. This example illustrates several key ideas underlying AVES:

• Virtual expansion of IP address space - A waypoint IP address can virtually represent, or virtualize, an unlimited number of non-IP responders in the IP Internet simultaneously because the binding is initiator-specific. Hence, AVES virtually expands the IP address space, achieving high connectivity when only a small number of IP addresses are used.

• Heterogeneity hiding - From the point of view of an IP initiator, with AVES, all responders appear to be IP hosts with IP addresses. Thus, there is no need to modify existing IP hosts or IP network routers to achieve connectivity.

• Transparent access - An initiating IP host accesses AVES transparently via DNS host name resolution. The IP address of the selected waypoint is returned to the initiating IP host. The service abstraction provided by AVES is therefore simply an IP address, which is most compliant with existing applications.

In the following, we first explain the data path operations, then we explain the control path operations for configuring the data path and discuss deployment scenarios in relation to our case study in Section 2. The connectivity achieved by AVES is summarized precisely in Section 4.