= 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:[[BR]]
''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:[[BR]]
''Using Legacy Applications in
Future Heterogeneous Networks with ariba''
'''

The main objective of this demo is to show how ariba provides an invariant network substrate to legacy applications while hiding network issues like mobility, NAT, protocol heterogeneity, and network topology dynamics. Like in [2] we consider a heterogeneous network setup as shown in Figure 2 that consists of two LANs, one running IPv4 and one running IPv6, respectively. Furthermore, an IPv4 WLAN access point 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 wireless devices. Furthermore, we employ native serial RFCOMM for communication between N3 and P2 (note that P2 is not using IP). Notebooks N2 and N4 are dual-stacked and connected to both IPv4 and IPv6 LANs.

In our demonstration we use two off-the-shelf servers as legacy applications: a web server on P2 using bluetooth, and a Jabber server on notebook N1 connected to the IPv4 WLAN access point and the IPv6 LAN. For setting up these servers without ariba several issues have to be addressed: To access those servers from any device participating in the demo is subject to manual configuration and error-prone. For example, to connect to the IPv4 LAN using bluetooth a personal area daemon (pand) is needed. Furthermore, a translation mechanism is required to forward IPv4 packets to the IPv6 network. Servers located behind NAT middleboxes would impose further problems that require manual configuration such as port forwarding.

Through the integration of ariba with OCALA the presented scenario is handled in a self-organizing and transparent way. Consider a scenario, when P1 wants to access the web server on P2 using a web browser: first, the web browser issues a DNS request for p2.spovnet.aribaocd. OCALA captures this request and uses the OC-D implementation to map
it to an ariba node identifier and return a private IP destination address to the legacy application. Second, ariba transparently establishes a relay path between P1 and P2 using N1, N2 or N4, and N3 to provide end-to-end connectivity across the heterogeneous network. This is accomplished by ariba in a self-organizing manner without infrastructure-support or
manual configuration.

As mentioned before ariba is able to adapt when the network topology changes. Therefore it is possible to interactively remove or establish new connections between the devices by
plugging and unplugging Ethernet cables. For example, N2 may get disconnected from the IPv6 network. ariba detects such network dynamics and transparently establishes new routes in a collaborative fashion to re-route traffic: Now, traffic that formerly traversed N2 is now sent through N4. Note that without ariba topology changes would require manual re-configuration of gateways. During that time connectivity is not available to the application.