| 11 | | All end-systems in this scenario run an application that |
| 12 | | requires end-to-end connectivity. In the following we refer |
| 13 | | to the instance of the application running on an end-system |
| 14 | | as node. Two nodes are directly connected, if they can com- |
| 15 | | municate through a common subset of protocols and bidi- |
| 16 | | rectional packet flow is not inhibited by middleboxes. In the |
| 17 | | exemplary scenario shown in Figure 2 nodes N1 and N4 are |
| 18 | | directly connected, whereas N1 and N3 are not. To illus- |
| 19 | | trate the establishment of end-to-end connectivity, consider |
| 20 | | a communication path between P2 and P1. Using a conven- |
| 21 | | tional approach lots of additional mechanisms are required |
| 22 | | to achieve end-to-end connectivity: First, N2 and N3 need |
| 23 | | to configure a point-to-point tunnel or personal area net- |
| 24 | | work daemon (pand ) to connect P2 via Bluetooth to the IPv4 network. Second, N2 or N3 need to be configured to |
| 25 | | forward packets from the IPv4 to the IPv6 network—this is |
| 26 | | only possible when using IPv4-mapped addresses. Finally |
| 27 | | N1 needs to forward packets for P1, and port forwarding |
| 28 | | must be configured on the NAT device. Note, that if the net- |
| 29 | | work setting is changed manual re-configuration is necessary |
| 30 | | to re-establish connectivity. During this time-consuming |
| 31 | | re-configuration process—which is usually error-prone and |
| 32 | | highly complex—end-to-end connectivity is unavailable. |
| 33 | | ariba eases this process using a generic self-organizing ap- |
| 34 | | proach: First, it does not rely on homogeneous addressing or |
| 35 | | protocols, in fact, ariba exploits different protocols to con- |
| 36 | | struct an application-layer path—looking homogeneous to |
| 37 | | the application—upon heterogeneous networks. This path |
| 38 | | is built hop-by-hop whereas each hop can run different trans- |
| 39 | | port- and network-layer protocols. Furthermore, it consid- |
| 40 | | ers that network settings are dynamic and may change over |
| 41 | | time. For example, notebook N1 may get connected directly |
| 42 | | to notebook N3 and updated to support 6-to-4. In this case |
| 43 | | ariba adapts and incrementally optimizes connectivity. For |
| 44 | | this purpose ariba uses an overlay with a consistent identi- |
| 45 | | fier -based addressing scheme to overcome network hetero- |
| 46 | | geneity: Nodes using the same application are connected by |
| 47 | | a logical overlay structure that allows forwarding packets us- |
| 48 | | ing node identifiers (e. g., using one-hop or Chord key-based |
| 49 | | routing protocols). |
| | 11 | |
| | 12 | 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). |
| | 13 | |
