Support for Legacy Applications

Table: Notations used in Section 5.2.

Notation	Definition
$X.hip$	home IP address of host $X$
$X.cip$	current IP address of host $X$
$C.port$	port associated to client process $C$
$i3\_hdr$	$i3$packet header (see Figure 7)
$i3\_hdr.id$	$i3$packet's identifier
$proxy\_hdr$	$i3$proxy header
$proxy\_hdr.$	flags: ID_MASK specifies that $proxy\_hdr$
$flags$	has an $i3$identifier. DATA_MASK specifies
	that the payload has an IP packet.
$H()$	well-known hash function; used to compute
	public trigger identifier for $X$ as $H(X.hip)$
$trans\_table$	translation table maintained by each $i3$proxy;
	each entry is a pair (IP address, $i3$identifier)

Figure: Legacy application support. $A.hip$ and $B.hip$ represents home IP addresses of hosts $A$, and $B$, respectively. Each host has a proxy that intercepts applications packets and send them via $i3$.

Although achieving host mobility for $i3$native applications is straight-forward, many legacy applications will remain $i3$/ROAM unaware. In designing a solution for these applications, our primary goals are to remain transparent to both applications and the TCP/IP protocol stack. The main host modification required for legacy applications is a user-level ROAM proxy. The proxy serves the following functions: (1) encapsulates and decapsulates IP packets within $i3$packets, (2) determines the triggers of remote hosts, and (3) sends the local private trigger to remote hosts. Table 1 gives the notations used in this section.

Figure: The format of the $i3$packet handled by the proxy. The fields are explained in Table 1.

Figure: The pseudo-code executed by the proxy upon receiving packets from another host via $i3$and from a host's client. The format of packet $p$ handled by the proxy is given in Figure 7. trans_table denotes a translation table that stores the association between (1) a host IP address addr, and (2) the identifier of the private trigger inserted by the proxy running on host addr.

We assume that each host $X$ has a current IP address denoted by $X.cip$ and a home IP address (e.g., the address of the host in its home network) denoted by $X.hip$. The home address is stored in the end-host's DNS record, and it is used as a source address for all packets sent by legacy applications on $X$. Each host $X$ runs a ROAM proxy $PX$ that maintains a public trigger $(id, addr)$ where $id$ is computed as a hash on $X$'s home IP address, and $addr$ contains the current address of $X$ and $PX$'s port number, i.e., $[X.cip, PX.port]$. The proxy is responsible for updating the trigger every time the host's current IP address changes.

Figure 6 shows a typical data path in a legacy application, where a client $CA$ running on host $A$ is accessing a web server $CB$ running on host $B$. (Figure 8 shows the pseudo-code executed by an ROAM proxy.) The source and the destination addresses in the headers of the packets sent by CA are the host IP addresses of $A$ and $B$, respectively. Upon capturing the packet, $PA$ encapsulates it in $i3$and proxy headers and sends it to $CB$ through $i3$using UDP. ⁶The identifier of the packet is set to $B$'s public trigger identifier, i.e., $H(B.hip)$ (see function ip_receive in Figure 8). The format of the packets handled by $i3$proxies is shown in Figure 7

When this packet arrives at $B$ (see ${\bf i3\_receive}$), $B$'s proxy ($PB$) strips off the $i3$and proxy headers and forwards the packet to the local application. In addition, $PB$ checks to see if the packet is addressed to its own public trigger. If it is, then $PB$ knows that $A$'s proxy ($PA$) does not have a private trigger for $B$, so $PB$ should send one. As an optimization, $PB$ sets a timeout to see if it can piggyback the trigger on a packet sent from $B$'s application ($CB$). Otherwise, when the timeout expires, $B$'s proxy sends the private trigger in a separate packet. An end-host chooses private triggers on a per flow or a per communication peer basis. This precludes a malicious end-host from learning the private trigger used by (the flows of) another end-host and eavesdropping on it.

Assume that $CB$ does send a packet before the timeout expires, then $PB$ piggybacks $B$'s local private trigger on the outgoing packet to $A$. Since, $PB$ does not know $A$'s private trigger, it uses $A$'s public trigger (as $H(A.hip)$). When $PA$ receives this packet, it inserts $B$'s private trigger into its translation table with $B.hip$ as the key. In addition, $PA$ sees that the packet was sent to its own public trigger, so it also sets a timeout and tries to piggyback its private trigger to $B$.

When $A$ changes its IP address from $A.cip$ to $A.cip'$ as a result of moving from one subnetwork to another, $PA$ will insert a trigger containing the new IP address $A.cip'$ into $i3$and remove the trigger containing the old IP address $A.cip$. The trigger identifier itself remains the same. Effectively, host mobility is masked by the $i3$network from the communicating peer, and end-to-end connectivity is preserved.

While each end-host initially chooses its private triggers such that they are stored on nearby servers, end-hosts may eventually move far from those servers. To address this problem, each end-host can re-sample trigger servers either periodically or once it notices that its current private triggers are experiencing a high latency. The new private triggers can be exchanged using a mechanism identical to the one used to exchange the original private triggers via the public triggers. The only change occurs in the i3_receive function: in addition to comparing the packet identifier to the the host's public trigger, we also compare it to the previous private trigger identifier, and then send out the new private trigger if necessary. This operation will be transparent to applications.