Ariba Demonstrations

The Ariba Framework has successfully been presented on top-tier conferences, each presentation highlighting a specific functional aspect. We describe some selected demonstration scenarios on this page.

ACM SIGCOMM 2009: Reconnecting the Internet with ariba: Self-Organizing Provisioning of End-to-End Connectivity in Heterogeneous Networks

The main intention of the demonstration is to show how ariba eases application deployment upon heterogeneous net- works. We consider an exemplary scenario (as shown in Figure 2) that consists of two LANs, one running IPv4 and one running IPv6, respectively. Furthermore, one WLAN attached to notebook N1 and a bluetooth device connected to notebook N3 are deployed. The WLAN uses NAT to multiplex the single IP address of the access point to mul- tiple wireless devices. Furthermore, we employ native RF- COMM for communication between N3 and P2, using MAC addresses. Notebook N2 and N4 are dual-stacked and con- nected to both, the IPv4 and IPv6 LAN. All end-systems in this scenario run an application that requires end-to-end connectivity. In the following we refer to the instance of the application running on an end-system as node. Two nodes are directly connected, if they can com- municate through a common subset of protocols and bidi- rectional packet flow is not inhibited by middleboxes. In the exemplary scenario shown in Figure 2 nodes N1 and N4 are directly connected, whereas N1 and N3 are not. To illus- trate the establishment of end-to-end connectivity, consider a communication path between P2 and P1. Using a conven- tional approach lots of additional mechanisms are required to achieve end-to-end connectivity: First, N2 and N3 need to configure a point-to-point tunnel or personal area net- work daemon (pand ) to connect P2 via Bluetooth to the IPv4 network. Second, N2 or N3 need to be configured to forward packets from the IPv4 to the IPv6 network—this is only possible when using IPv4-mapped addresses. Finally N1 needs to forward packets for P1, and port forwarding must be configured on the NAT device. Note, that if the net- work setting is changed manual re-configuration is necessary to re-establish connectivity. During this time-consuming re-configuration process—which is usually error-prone and highly complex—end-to-end connectivity is unavailable. ariba eases this process using a generic self-organizing ap- proach: First, it does not rely on homogeneous addressing or protocols, in fact, ariba exploits different protocols to con- struct an application-layer path—looking homogeneous to the application—upon heterogeneous networks. This path is built hop-by-hop whereas each hop can run different trans- port- and network-layer protocols. Furthermore, it consid- ers that network settings are dynamic and may change over time. For example, notebook N1 may get connected directly to notebook N3 and updated to support 6-to-4. In this case ariba adapts and incrementally optimizes connectivity. For this purpose ariba uses an overlay with a consistent identi- fier -based addressing scheme to overcome network hetero- geneity: Nodes using the same application are connected by a logical overlay structure that allows forwarding packets us- ing node identifiers (e. g., using one-hop or Chord key-based routing protocols). The overlay is constructed incrementally: First, a joining node contacts another node—running the same ariba-based application—it has direct connectivity with. For example, N1 may use N2 to join the overlay. The joining node must establish connections to its logical neighbors in the overlay. Neighbors are discovered by issuing queries inside the over- lay network using key-based routing. For example, if P2 is logical neighbor of N1, the query reaches P2. P2 has two options: P2 might try to establish a direct connection to N1—which is not possible due to heterogeneity—or use the overlay path the query originated to establish a connection. In the latter case, N2 (or N4) and N3 would be used to con- struct a relay path between N1 and P2. Relay paths may fail if the network setting is changed. In this case the node can re-establish relay paths by partially repeating the join phase for overlay stabilization. For an instant decision whether two nodes can communi- cate directly and to optimize the length of relay paths ariba implements an unintrusive extension: Connectivity Domain management. The extension monitors overlay connections and relay paths to identify regions with direct connectivity— so called Connectivity Domains—and assigns a Connectivity Domain Identifier (CDID) to each Connectivity Domain. Using a gossip mechanism nodes inform each other about

IEEE INFOCOM 2010