Changes between Version 4 and Version 5 of BaseDemos

Timestamp:

Nov 23, 2010, 8:21:49 AM (13 years ago)

Author:

huebsch

Comment:

--

BaseDemos

@@ -8 +8 @@
 '''
 
+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'''