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 networks. 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 multiple wireless devices. Furthermore, we employ native RFCOMM for communication between N3 and P2, using MAC addresses. Notebook N2 and N4 are dual-stacked and connected 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 communicate through a common subset of protocols and bidirectional 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 conventional 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 network 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 network 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 approach: First, it does not rely on homogeneous addressing or protocols, in fact, ariba exploits different protocols to construct 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 transport- and network-layer protocols. Furthermore, it considers 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 identifier -based addressing scheme to overcome network heterogeneity: Nodes using the same application are connected by a logical overlay structure that allows forwarding packets using 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 overlay 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 construct 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 communicate 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 changes in connectivity characteristics (i. e., a Connectivity Domain split or merge) and resolve conflicting CDIDs. All nodes include CDIDs in their routing information. Thus other nodes can immediately decide whether they can communicate directly with a certain node by comparing CDIDs, which can also be used to discover shorter relay paths [3]. For demonstration purpose, the network settings shown in Figure 2 can be modified by connecting and removing relaying nodes, as well as connecting nodes to different networks interactively. ariba will automatically sustain connectivity between nodes. To visualize internal protocol functionality the application additionally shows its local view of the network: relay paths traversing the node and logical neighbors.In its current form our approach has the following open issues: First, the overlay re-join mechanisms may suffer from overlay partitioning, and second, relay paths may degrade in case of network setting reconfiguration. However, our approach is feasible in a practical setting and allows easy deployment, as shown in the demonstration.

IEEE INFOCOM 2010