Check out the new USENIX Web site. next up previous
Next: Scenario 2 - General Up: Control Path Operations Previous: Control Path Operations

Scenario 1 - Intranet Deployment

Let us reconsider the scenario discussed in Section 2. CMU can deploy AVES to restore bi-directional connectivity within the CMU intranet so that DSL users will be able to access their home computers directly from any host within the CMU intranet. To do so, CMU would deploy waypoints and upgrade its local DNS servers to make them AVES-aware. By upgrading the local DNS servers, initiator-specific bindings can be created easily since an initiator's IP address is now available in the IP headers of its DNS queries to the AVES-aware local DNS servers.

Figure 5: Control path operations for intranet deployment

Figure 5 shows how this scheme works. Under this scheme, reusable-IP networks will use a common domain name suffix, say, for easy identification. In our example, the reusable-IP network has a domain name $D_1$ - $D_n$ are upgraded AVES-aware local DNS servers. The control path operations are as follows. Initiator $A$'s DNS query for $B$ is directly sent to one of the AVES-aware local DNS servers, $D_1$ (step 1). $D_1$ is by configuration aware of the IP address of the AVES-aware NAT gateway $R$ and the reusable-IP address of $B$. Upon receiving the DNS query, $D_1$ selects at random a waypoint among a set it knows, in this case $W$, and sends a SETUP message to $W$ (step 2).[*] The SETUP message contains $IP_A$, $IP_R$, and $IP_B'$, which are necessary to create a data path translation table entry on $W$. When $W$ receives the SETUP message, it examines its data path translation table to see if it can accept the request. Let us denote a translation table entry $\mathcal{E}$ on $W$ more compactly by $\{IP_{initiator}, IP_{NAT},
IP_{responder}'\}$. Then, $W$ can accept the request for initiator $IP_A$, NAT gateway $IP_R$, and responder $IP_B'$ if and only if,

$\forall \mathcal{E},$ $IP_{initiator} = IP_A \Rightarrow$ $(IP_{NAT},IP_{responder}') = (IP_R,IP_B').$

That is, if $W$ already has a translation table entry for initiator $IP_A$, and the responder of that entry is not the same as the one in the SETUP message, then $W$ must reject the request and reply with a REJECT message because $W$ cannot be used to relay a particular initiator to more than one responder. On receiving a REJECT message, for simplicity, the AVES-aware DNS server will simply do nothing and let the initiator perform the DNS name lookup again to retry. In our example, the admission control criterion is satisfied, so $W$ accepts the request, creates the corresponding translation table entry, and sends back an ACCEPT message (step 3). Finally, when $D_1$ receives the ACCEPT message, it responds to $A$'s DNS query for $B$ with the IP address of the selected waypoint, $IP_W$, with the time-to-live field set to zero (step 4). Note that the messages between waypoints and the AVES-aware DNS servers are authenticated to prevent unknown sources from gaining control of the system. Also, the messages can be lost in the network. Waypoint failure and packet loss are simply handled by initiator $A$'s DNS query timeout/retry mechanism. Limitations of this scheme are discussed in Section 6.

next up previous
Next: Scenario 2 - General Up: Control Path Operations Previous: Control Path Operations