Changes between Version 15 and Version 16 of BaseDemos


Ignore:
Timestamp:
Nov 23, 2010, 8:58:19 AM (14 years ago)
Author:
huebsch
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BaseDemos

    v15 v16  
    1010
    1111The 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.
     12
     13[[Image(sigcomm.png, align=center,660px)]]
    1214
    1315All 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).