Check out the new USENIX Web site. next up previous
Next: Implementation Up: Background Previous: Background

Rendezvous-based Communication

The service model is a rendezvous-based communication abstraction. In its simplest form, a packet is a pair $(id, data)$ where $id$ is an $m$-bit identifier2 and $data$ is the payload (typically a normal IP packet payload). Receivers use triggers to indicate their interest in packets. In its simplest form, a trigger is a pair $(id, addr)$, where $id$ is the trigger identifier, and $addr$ is a node's address, consisting of an IP address and UDP port number. A trigger $(id, addr)$ indicates that all packets sent to identifier $id$ should be forwarded (at the IP layer) by the $i3$infrastructure to the node with address $addr$. More specifically, the rendezvous-based communication abstraction exports the three primitives shown in Figure 1(a).

Figure 1(b) illustrates the communication between two nodes, where receiver $R$ wants to receive packets sent to $id$. $R$ inserts the trigger $(id, R)$ into the network. When a packet is sent to identifier $id$, the trigger causes it to be forwarded via IP to $R$.

Thus, as in IP multicast, identifier $id$ represents a logical rendezvous between the sender's packets and the receiver's trigger. This level of indirection decouples the sender from the receiver and enables them to be oblivious to the other's location. However, unlike IP multicast, hosts in $i3$are free to place their triggers. This can alleviate the triangle routing problem in Mobile IP. In addition, $i3$ can be generalized to support multicast, anycast, and service composition. For more details refer to [6].


next up previous
Next: Implementation Up: Background Previous: Background
Shelley Zhuang 2003-03-03