National Laboratory for. Information ... performance of the proposed approach in a lab environment .... name-exchange is done in IPv6 extension headers.
Name-based Shim6: A name-based approach to host mobility Zhongxing Ming
Javier Ubillos
Mingwei Xu
Dept. of Comp. Sci. & Tech., Tsinghua Univ., Tsinghua National Laboratory for Information Science and Technology
Communication Networks and Systems laboratory Swedish Institute of Computer Science
Dept. of Comp. Sci. & Tech., Tsinghua Univ., Tsinghua National Laboratory for Information Science and Technology
ABSTRACT
receive a new IP-address which belongs to the addressrange of the new network provider. The root of this problem lies in the dual role of IPaddresses. An IP-address plays both the roles of a topological-locator as well as an end-system identifier. It is impossible for a host, which has multiple changing locators, to maintain a session over address changes without specialized application-layer libraries. If a stationary host with multiple interfaces, e.g. a HDSPA connection and a Wi-Fi connection wishes to switch the active interface (multihoming), or if a mobile host changes networks, e.g. a laptop with a single wi-fi interface moves from one access point (AP) to another, the connection initiated using the original address must break down. This is a well known problem-area with multiple proposed architectural solutions [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17] (discussed further in Section 6). All these solutions introduce new layers of indirections and, either introduce some kind of indirection , e.g. triangular routing in MIP [4], or introduce new elements and/or requirements on the infrastructure, e.g. LISP [7]. In the scenario when both end-points change their entire locator set simultaneously, a problem arises as neither node have the means to reach the other to update their respective locator sets. The typical solution require new infrastructure (a rendezvous point) to be introduced in the network, e.g. as introduced by HIP [18, 19]. Also, by breaking with applications assumptions about IPs a risk is introduced. If an application expects there to be a strong connection between a socket and IP-address used, the application might open up subsequent links to the same IP even if that IP has been re-assigned to a different host. In this paper we introduce Name-based shim6 to solve host mobility problem in IP networks. Traditional shim6 [20] provides a multi-homing solution which does not require any infrastructure. Shim6 provides a shim-layer at the network-layer. It allows the application to bind
The addressing scheme of today’s Internet expects network nodes to be static and use a single interface. Communication flows bind to specific IP-addresses, making the IP-address act both as a topological locator as well as an end-point identifier. Mobile hosts break with this model , which makes it difficult to maintain a connection during address change. A typical method to solve this problem is adding a layer of indirection by providing a name-space split between locators (IP-addresses) and end-point identifiers (names). In this paper we introduce name-based sockets and apply a name-based approach to improve Shim6 (a host-based multihoming solution) to support host mobility. Name-based sockets does not introduce a new name-space split, but uses the already deployed identity/locator-split scheme, domain names for names and IP-addresses for locators. This makes the name-split fully backwards compatible and does not require new infrastructure. We show how a name-based approach intrinsically transforms a multihoming solution into a mobility solution and how the existing infrastructure is sufficient to provide the necessary signaling to support both unilateral and bilateral mobile scenarios. We evaluate the performance of the proposed approach in a lab environment and show that it achieves promising recovery time in both scenarios.
1. INTRODUCTION Routing in IP-networks assumes a hierarchical scheme. Historically, this model has been successful, however this hierarchical model assumes that individual hosts or networks have a single point of attachment and do not move. Nodes and networks which do have multiple points of attachment (multihomed) or transient points of attachment (mobil) become, from the point of view of the network, separate instances of hosts/networks. The consequence is that a connection may not persist over multiple attachment points, or changing points. To provide address (locator) agility a host or network must either disseminate the change to the Internet [1] or 1
to a pseudo IP-address which it in turn can swap out with other addresses which reach the same end-point. There are however, drawbacks using pseudo IP addresses. It introduces a new layer of indirection, which requires management. Also, an address in use in one session may have been assigned to a different host. Introducing a name-based approach to shim6 receives several advantages: The name-based approach allows us to change the Shim6 semantics by replacing the pseudo IP-address with a name. This way, a host’s locator becomes both practically and semantically decoupled from its identifier (name). Also, by moving the responsibility of resolving names (e.g. looking up a Fully Qualified Domain Name (FQDN) in Domain Name System (DNS) ) to the Operating System (OS), Shim6 may provide locator-agility at its discretion (e.g. shim6 functionality) without disturbing the upper layers. The contribution of this paper is as follows: 1) We propose and implement name-based sockets as a socketAPI abstraction so that an application developer may use names instead of IP-addresses. 2) We improve Shim6 and integrate it with name-based sockets to provide mobility and multihoming. 3) We evaluate the performance of the proposed mechanism using a real testbed. The rest of this paper is organized as follows. We first discuss the problem which name location splits typically face (Section 1, related solutions and how they differ from a name-based approach. In the next sections Section 2 - Section 3 we describe the structure and elements of the name-based shim6 implementation. Section 4 describes the different mobile scenarios and how namebased shim6 behaves in them. In Section 5, we discuss the implementation and evaluate it. Section 6 discuss related work. Finally we conclude in Section 7.
move as well.
2.2
Name-based sockets
Name-based sockets (NBS) provide a socket-API abstraction where an application developer may use names instead of IP-addresses. Traditionally, the application does the resolution from a name (FQDN) to an IP-address and provides this address to the OS. This means that when the application calls the OS to open a connection, it opens a connection to a specific IP-address, not a specific host. Using name-based sockets, the application only needs to manage the name, and binds its connections to names. This allows the OS to manage the addresses (locators) without disrupting the application. This results in the possibility of providing locator-agility, where the OS may change addresses during a communication for e.g. redundancy, performance and mobility reasons. Name-based sockets provide a new address family (AF NAME) for applications to use. This allows applications to open a socket to a remote name (FQDN). In conjunction to this, the address family AF NAME also provides semantics to deal with names. For example, the bind() call allows the application to bind to a specific name rather than a specific IP-address. Name-based sockets do the name-exchange in a piggyback manner, in which the hosts exchange names inband, and which allows the host to check if a correspondent host supports name-based sockets or not. The name-exchange is done in IPv6 extension headers. Hence, if a remote host does not recognize the extension, the name header is silently ignored and the originating host may conclude that there is not bi-lateral NBS support.
2.3 Using NBS to improve Shim6 2. THE NAME-BASED SHIM6 STRUCTURE
By using a name rather than a locator as the identifier that an application binds to, we can overcome the limitation that shim6 imposes when the locator used as ULID becomes invalid. The application binds to a name, and the OS is responsible for managing the locators. This change allows us to drop the primarylocator (the one used as ULID) and replace it with others. Name-based shim6 also implements a new state called NO LOC (explained in section 3.3). This state allows the connection to be preserved during periods of complete disconnection, when the locator-list is empty.
2.1 Shim6 mechanism Shim6 [20] is a network layer solution to provide host multihoming, which was designed within the Internet Engineering Task Force (IETF). It provides a stable IP address for the application to identify the connection and keeps a list of locators available to the remote host. The communicating hosts continually exchange their available locators through which they can be reached as the locator set changes (in this paper, we use IP address and locator interchangeably). Shim6 uses REAchability Protocol (REAP) [21] to test the existing locator’s reachability. However, as shim6 uses one of the locators as the Upper Layer Identifier (ULID), if that locator becomes invalid the connection MUST be dropped [20]. As a consequence, shim6 is not suitable for mobility as there might very well be periods when a host has zerolocators in its locator-list and the primary locator (the one used as ULID) is likely to become invalid during a
2.4 Using DNS as a rendezvous point The modifications described above only work for the scenarios where a single host moves. In such scenarios, the moving host who has been disconnected still retains at least one live locator to the non-moving party to which it may send an updated locator-list. However, in the scenario where both hosts have switched their entire locator-set, there is no known locator to update 2
to. To solve this kind of problems, a rendezvous point is required. A rendezvous point is a well known point where clients may both register a locator on which they can be reached or query for a locator to a client they wish to communicate with. A good example is DNS. An user may query DNS for locators to a host of which the client knows the name, but does not have a locator to. For instance, to be able to reach “www.eff.org”, we need to query DNS for working locators. The locators may change over time, but the name remains constant. In a name-oriented architecture, it is natural to use DNS as a rendezvous point (perhaps in conjunction with alternatives). Whenever a host transits from the NO LOC state (having zero locators) to the “Exploring / InboundOK” state (receives a working locator), it also updates its mapping in DNS. This way, if a host has no working locators to its correspondent party, it can query DNS for a new working locator [19].
Figure 1: REAP Connection Recovery such case the ULID must have become invalid). In the
3. THE REACHABILITY PROTOCOL (REAP) mobile scenario where hosts switch from one network
to another, it is very likely that the host first losses its address and needs several seconds to get a new one. In such cases, connection will be dropped by conventional Shim6. As we suggest in section 2.3: if the ULID is used as just a transport level identifier to identify a session handle, this problem can be solved. In fact, when the ULID no longer depends on IP, Shim6 may preserve and recover the connection in despite of renumbering, as long as a new locator can be got within a desired interval of time (explained in section 3.3). To decouple ULID from IP, we propose to use names as Shim6’s Upper Layer Identifiers. Using names as ULIDs provides a premise for connection to be recovered, as names won’t change during movement. To make use of names, we integrate Shim6 with Name Based Sockets (NBS). With NBS, applications and transport protocols operate exclusively based on names, while the discovery, selection, and updating of IP addresses are performed at the IP layer. Shim6 uses the names provided by NBS as ULIDs and performs IP management in network layer. How to exchange names to identify communication sessions is specified by the NBS publications [23, 24] and is beyond the scope of this paper.
A protocol called REAP is specified by Shim6 [21]. It is a companion protocol that is used to detect and recover from a path failure when one host (or both hosts) experiences a locator change. In this section we will first introduce the basic idea of REAP and then describe how we extend REAP to solve mobility problems.
3.1 The REAP concept REAP is used as a reachability detection protocol to detect changes in reachability and to perform recovery if a path failure occurs. In the normal case, if a locator being used by one host becomes unreachable or invalid, the path between the communicating hosts will become unusable and the connection between the hosts will eventually timeout and break. REAP monitors the path state by periodically sending keep alive messages. When a path-failure is detected, REAP automatically selects an alternative locator and establishes a new path to keep the connection alive. When a new locator is found, Shim6 maps the locator to its ULID. Hence, from the perspective of upper layer protocols, locators do not change and the connection simply continue working. A typical life cycle of a TCP connection over Shim6 is as follows (figure from S. Barre [22]).
3.3 Context preservation when movement occurs
3.2 Name extension to Shim6 and REAP to implement mobility
Three states are defined in traditional Shim6, which are:
Although Shim6 is able to provide connection recovery for multihomed hosts, by its original design, it does not attempt to solve the related problem of host mobility. This is because the confusion avoidance mechanism defined in rfc5533 [20] implies that the context must be removed when the host losses all its locators (as in
• Operational. • Exploring. • InboundOK. 3
In the Operational state, the underlying address pairs are assumed to be operational. In the Exploring state, a node hasn’t seen any traffic from the peer for more than a certain period of time. In the InboundOK state, this node sees traffic from the peer, but the peer may not yet see any traffic from this node, so the exploration process needs to continue [21]. When a host moves, it is very likely that the host will experience a period of time that all its addresses are lost. In traditional Shim6, the connection will be directly dropped. If we use a state named ’Dead’ to represent the situation that the communication is terminated, the traditional Shim6 state machine can be illustrated as figure 2.
Figure 3: Modified Shim6 state machinie and call the latter double move scenario.
4.1
Single move scenario
In the single move scenario, the moving host starts the REAP update process to re-establish the Shim6 context with the correspondent host. Meanwhile, DNS is updated by the moving host with the moving host’s new address. Note that updating DNS is unnecessary if it can be guaranteed that the correspondent host will not move during the time of disconnection. However, as it is impossible to give such guarantee, it is necessary to use a rendezvous point to follow the trail of the correspondent host, which in our case is the DNS (discussed further in section 4.2). Figure 4 shows the above logic. Figure 2: Traditional Shim6 state machinie With the existence of names, shim6 is able to provide hosts with mobility functionality. In the moving process, name plays the role of identifying the two sides. When movement occurs, Shim6 does not destroy the context of the connection immediately, but allows the context to survive for a period of time. When a new address is achieved, Shim6 updates the context and REAP informs the peer of the address change. After that, connection is recovered. A modified state machine (figure 3) is defined to specify the behaviors in mobile scenarios. Denote by NO LOC the state that the host has no available locator. When a host has zero working locator, it transits to the NO LOC state. A timer is used to monitor how long the host stays in the NO LOC state. If the host achieves a new address within a pre-defined period of time, the host leaves NO LOC state and start the REAP path exploration process [21] to recover the connection. If the timer should expire, the context would eventually be dropped.
Figure 4: Single move event diagram.
4.2
Double move scenario
When both hosts move simultaneously, neither one will be able to receive the REAP update message (as is described in section 2.4), thus REAP will fail in finding a new operational locator pair. Under such circumstances, both hosts need to query DNS for the correspondent host’s address. When new addresses are retrieved, both hosts initiate REAP update process to recover the connection. Figure 5 shows the above logic. While using DNS requires that the name must be a FQDN, the proposed name-based Shim6 does not make
4. CONNECTION RECOVERY IN MOBILE SCENARIOS In this section, we will first describe the basic scenario in which only one host moves, and then discuss the more complicated scenario in which both hosts move simultaneously. We call the first case single move scenario, 4
In name based Shim6, SRD equals to the time required by Shim6 and REAP to recover the connection. For single move scenario, SRD is just Shim6 and REAP delay. For double move scenario, things turn out to be more complicated as there can be an ’overlap’ between the handover processes of the two hosts (figure 6). And besides, DNS querying is involved as well. Denote by Overall Handover Time (OHT) the duration from the time when the first host starting moving to the time when the second host finishes moving. In double move scenario, SRD equals to the OHT plus the DNS query delay plus the Shim6 and REAP delay.
Figure 5: Double move event diagram. it a necessity for hosts to use FQDNs. If the names used by both sides are FQDNs, name-based Shim6 is able to provide solution to the extreme case the both hosts move simultaneously. If they are not, hosts can still get the benefits from name-based Shim6 to recover the connection in the single move scenario as well as the multihoming scenario.
4.3
Figure 6: Handover overlap in double move scenario.
Recovery time
How fast a connection will be recovered when movement occurs is a crucial issue. Denote by Upper Layer Recovery Time (ULRT) the time during which the upper layer session (TCP or UDP) is interrupted due to movement. Denote by Link Layer Handover Time (LLHT) the time during which the link layer traffic is interrupted due to link layer renumbering. LLHT stands for the duration between the transmission break due to address change until the transmission of the first frame via the new address. Denote by Solution Recovery Delay (SRD) the time required by a mobility solution to recover the connection when link layer renumbering has finished. In this paper, we use tU LRT , tLLHT and tSRD to stand for the values of ULRT, LLHT and SRD. For any mobility solution, it is trivial to have the following equation: tU LRT = tLLHT + tSRD
(1)
For any given host, LLHT is decided by how fast the host moves from one network to another as well as the hardware technology, which can not be optimized. However, we can optimize SRD through carefully designing the mobile solution. It is reasonable to assume that a good mobility solution should have a short SRD that does not occupy the main part of its ULRT. In other words, except for LLHT, SRD should not contribute much to ULRT. In this paper, we regard an ULRT as reasonable if it closely resembles the corresponding LLHT. 5
In section 4, we will investigate the Upper Layer Recovery Time of the proposed name based Shim6 via a testbed and show it achieves reasonable recovery time in mobile scenarios.
5.
IMPLEMENTATION AND EVALUATION
In this section we will investigate the performance of the proposed name-based Shim6 via a testbed implemented using household PCs. First, we will describe the implementation details. Second, we will introduce the results of our experiments. Finally, we will discuss how name-based Shim6 achieves reasonable recovery delay in mobile scenarios.
5.1 Testbed implementation An experimental implementation was developed under Ubuntu Linux operating system. NBS is developed as a standard Linux distribution, which introduces a new protocol family, PF NAME. Currently, we have versions for kernel 2.6.25, 2.6.27, 2.6.28 and 2.6.29 . We use the open source Shim6 code LinShim6[3] as the basic Shim6 implementation and integrate it with Name Based Sockets. Shim6 is completely transparent to NBS, which means that NBS never knows that there is a ’shim layer’ in the network layer. We setup our own DNS server using BIND (BIND 9), which is the most commonly used DNS server on the Internet [25]. The topology of the testbed is shown in figure 7. To serve as a router as well, the DNS server is configured
D-Link Detection Search Execution Total
to be able to forward packets. The hosts and the DNS server are connected via a household switch.
520 1630ms 288ms 2ms 1920ms
Spectrum24 1292ms 98ms 3ms 1393ms
ZoomAir 902ms 263ms 2ms 1167ms
Orinoco 1016ms 87ms 1ms 1104ms
Table 1: Handover time for different IEEE 802.11b cards onds, and for double move scenario, the ULRT is approximately 2.75 seconds. While it takes longer to recover the connection for double move than single move, it is reasonable because there is an overlap between the handover processes of the two hosts (figure 6).
Figure 7: Testbed topology As mobile event is just the same as renumbering event, during the connection, we use the ’ifconfig’ command to artificially change the IP addresses of both hosts to simulate mobile events. To simulate concurrent move, we first delete one host’s address and then delete that of another host, when both hosts loss their addresses, we reconfigure them with new addresses in arbitrary order. The testbed was exhibited at IETF 79, Beijing and has a video version on youtube [26]. (For the video version, we use virtual machines rather than real PCs).
5.3
Results analysis
The LLHT in our experiment is measured using ICMP and wireshark. In our test, from the point of view of the handover process, being unable to disseminate ICMP packets means the network card loses its address and being able to disseminate ICMP packets again means the network card has been recovered via a new address. By continuously capturing the ICMP packets which are sent out from the moving host, we measured the mean LLHT of our tested hosts to be around 1.5 seconds. H´ector Velayos and Gunnar Karlsson measured the handover time for different IEEE 802.11b cards and give the similar result as our wired Ethernet cards [27]. Table 1 shows their results. Although the handover mechanisms are different, the handover times for both wired and wireless cards are all around 1 - 2 seconds, which means it is impossible to recover a connection in less than 1 - 2 seconds. For single move, the ULRT is dominated by its LLHT, which contributes 91% of the total recovery delay, while Shim6 only contributes 9%. This means that for the single move scenario, the name based Shim6 achieves a reasonable recovery delay in single move scenario. In the double move scenario, due to the existence of overlap handover, the overall handover time is very likely to be longer than the OHT of single move scenario. As a result, the delay introduced by Shim6 may take up an even smaller fraction in the total session recovery time than single move scenario, which provides name based Shim6 with a reasonable recovery time in double move scenario as well. While the Upper Layer Recovery Time may suffer from DNS delay in the double move scenario and becomes much longer than that of single move, it is actually not a problem because DNS responses fairly fast. Bernhard Age et al [28] studies various DNS resolvers around the world and found that there are only less than 1% of the cases for which DNS resolvers take more that 100ms to answer, figure 9 shows their result of the
5.2 Test results To show the benefits of name based Shim6, we present the effect of a mobile event on the throughput of a TCP session in figure 8. A TCP session is established between host A and host B. During the connection, we first make one host move and then move both hosts simultaneously. We use wireshark to capture the throughput of the session.
Figure 8: Throughput graph In our experiment, host A moves from 2000::/64 to 2001::/64 at approximately 50 seconds after starting the wireshark client and both hosts move simultaneously at approximately 80 seconds. The throughput drop represents the full recovery time, including the handover time during the mobile events. For single move scenario, the ULRT is about 1.65 sec6
plicity. In contrast to other mobility solutions, .e.g, Mobile IP (MIP) [4], which requires infrastructure (a homing agent) or e.g. Host Identity Protocol (HIP) [3] which requires new DNS resource records (infrastructure change) and a new indirection to provide locatoragility in a corresponding manner, name-based Shim6 does not require changes in multiple parts of the Internet architecture. It also limits the changes to hosts, and retains backwards compatibility with non-upgraded hosts and network elements. Name-based Shim6 provides redundancy in the same form as ordinary shim6 [20] and e.g. Multi-Path TCP (MPTCP) [29]. It does so in a host-based manner, in contrast to e.g. performing multi-homing in the routing domain [7, 10, 12, 16, 6] or solutions which affect both host- and routing-domain such as INLP [11] and Name Overlay (NOL) [13]. In name-based shim6 (as with traditional shim6), no infrastructure changes are needed. All negotiations are done by the peers. However, name-based shim6 is not capable of load sharing. It does select one, and only one interface. As opposed to .e.g. MPTCP [29], which is a transport-layer solution to multi-path data transmission. However, it is not an unreasonable or unfeasible function, which can do very well in a future version of name-based shim6. Traffic engineering is not enabled with name-based shim6 (which is host-based). However, in combination with e.g. NOL, a site-wide traffic-engineering could be done. For traffic-engineering to be done, either the traffic-engineering entity needs to be able to control the routing, or it needs to be able to communicate preferences to the transmitting host(s). The in-network solutions mentioned previously are better fitted for this task.
CCDF of response times for different DNS resolvers.
Figure 9: CCDF of response times for different DNS resolvers
6. RELATED WORK This section discusses and compares name-based shim6 with other solutions in similar domains. The section discusses, in a sequential order, the semantic differences in the addressing models, the needed lookup-substrates for the identifier/locator indirections, simplicity of approaches, redundancy, multi-path delivery and finally traffic engineering possibilities. Name-based shim6 provides applications with an alternative (name-based) interface. This change makes it possible to break with assumptions made by the legacy interface. The typical pseudo-address solutions to the identity/locator-split problem use an address formatted data structure as an end-point identifier [3, 20, 29, 9]. This will lead to problems when an unaware application assumes that the IP-address used to open a socket is still valid to reach a particular host subsequently. Name-based Shim6 enables application to explicitly use the new interface as well as the end-point identifiers (names), which solves the above problem. Other identity/locator split schemes, host-based [3, 20, 29, 9, 8], network-based [7, 10, 12, 16, 6], as well as hybrid models [11, 5], all face a common issue: managing the introduced identifier/locator indirection layer. Name-based sockets stand out in this respect by reusing an already deployed name-to-address resolution system - DNS. A consequence is that upgraded hosts and applications are still backwards compatible. FQDN are used already to name individual hosts. The consequence is that, if the corresponding party not support namebased sockets, the communication simply falls back on the legacy paradigm. The proposed name-based approach aims towards sim-
7.
CONCLUSION
This paper has presented name-based shim6, a namebased improvement on a host-based multihoming solution to solve host mobility problems in IP networks. We apply a name-based approach to improve Shim6 to support host mobility by integrating Shim6 with namebased sockets. We use DNS as a rendezvous point to coordinate address information for when both hosts move simultaneously. Using DNS makes the name/addresssplit fully backwards compatible and hence does not require new infrastructure. We evaluate the performance of the proposed approach by implementing the protocol and test it in a lab environment. Results show that our approach achieves promising recovery time when hosts move. Finding mechanisms to provide security guarantee for name resolution remains as a challenging issue for future research.
8.
REFERENCES
[1] D. M. Vince Fuller. (2006, Mar.) Open issues with 7
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11] [12]
[13]
[14]
[15]
[16]
ipv6 routing / multihoming. [Online]. Available: http://www.ietf.org/proceedings/65/slides/grow1.pdf J. Saltzer, “On the naming and binding of network destinations,” RFC1498 (Informational), Internet Engineering Task Force, Aug 1993. R. Moskowitz, P. Nikander, P. Jokela, and T. Henderson, “Host identity protocol,” RFC5201, Internet Engineering Task Force, Apr 2008. C. Perkins, “Ip mobility support for ipv4,” RFC3344, Internet Engineering Task Force, Aug 2002. M. Menth, M. Hartmann, , and D. Klein, “Global locator, local locator, and identifier split (gli-split),” Apr. 2010. P. Frejborg, “Hierarchical ipv4 framework,” draft-frejborg-hipv4-13, Internet Engineering Task Force, Mar 2011. D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, “Locator/id separation protocol (lisp),” draft-ietf-lisp-11, Internet Engineering Task Force, Mar 2011. X. Xu, “Routing architecture for the next generation internet (rangi),” draft-xu-rangi-04.txt, Aug. 2011. R. Stewart, “Stream Control Transmission Protocol,” RFC 4960 (Proposed Standard), Internet Engineering Task Force, sep 2007, updated by RFC 6096. [Online]. Available: http://www.ietf.org/rfc/rfc4960.txt D. Massey, L. Wang, U. Memphis, B. Zhang, U. Arizona, and L. Zhang, “A proposal for scalable internet routing and addressing,” draft-wang-ietf-efit-00, Feb 2007. R. Atkinson, “Ilnp concept of operations,” draft-rja-ilnp-intro-10, Feb 2011. R. Whittle, “Ivip (internet vastly improved plumbing) architecture,” draft-whittle-ivip-arch-04, Mar 2010. Y. Wang, J. Bi, and J. Wu, “Nol: Name overlay service for improving internet routing scalability,” in AFIN 2010, 2010. A. Jonsson, M. Folke, and B. Ahlgren, The split naming/forwarding network architecture [Elektronisk resurs], 2003. H. Balakrishnan, K. Lakshminarayanan, S. Ratnasamy, S. Shenker, I. Stoica, and M. Walfish, “A layered naming architecture for the internet,” in Proceedings of the 2004 conference on Applications, technologies, architectures, and protocols for computer communications, ser. SIGCOMM ’04. New York, NY, USA: ACM, 2004, pp. 343–352. C. Vogt, “Six/One Router: A Scalable and Backwards-Compatible Solution for
[17]
[18]
[19] [20]
[21] [22]
[23]
[24]
[25]
[26] [27]
[28]
[29]
8
Provider-Independent Addressing,” in ACM International Workshop on Mobility in the Evolving Internet Architecture (MobiArch), Seattle, WA, USA, 2008. B. Ahlgren, J. Arkko, L. Eggert, and J. Rajahalme, “A node identity internetworking architecture,” in INFOCOM 2006. 25th IEEE International Conference on Computer Communications. Proceedings, april 2006, pp. 1 –6. J. Laganier and L. Eggert, “Host identity protocol (hip) rendezvous extension,” draft-ietf-hip-rfc5204-bis-01, Sep 2011. L. Eggert, J. Laganier, L. M, and S. M, “Hip resolution and rendezvous mechanisms,” 2004. E. Nordmark and M. Bagnulo, “Shim6: Level 3 multihoming shim protocol for ipv6,” RFC5533, June 2009. J. Arkko and I. van Beijnum, “Failure detection and locator pair,” RFC 5534, June 2009. S. Barre and O. Bonaventure, “Improved path exploration in shim6-based multihoming,” in IPv6’07, Kyoto, Japan, Aug 2007. C. Vogt, “Simplifying internet applications development with a name-based sockets interface,” Feb. 2010. [Online]. Available: http://www.sics.se/nbs/pub/vogt-2009-nameoriented-sockets.pdf J. Ubillos, M. Xu, and Z. Ming, “Name based sockets,” draft-ubillos-name-based-sockets-02, Jul 2010. D. Moore, “Don moore’s may 2004 dns internet survey,” 2004. [Online]. Available: http://mydns.bboy.net/survey/ M. Zhongxing and J. Ubillos. (2010, Nov.) Name-based shim6 online demo. H. Velayos and G. Karlsson, “Techniques to reduce the ieee 802.11b handoff time,” in IEEE International Conference on Communications, 2004. B. Ager, W. M¨ uhlbauer, G. Smaragdakis, and S. Uhlig, “Comparing dns resolvers in the wild,” in Proceedings of the 10th annual conference on Internet measurement, ser. IMC ’10. ACM, 2010, pp. 15–21. A. Ford, C. Raiciu, M. Handley, S. Barre, and J. Iyengar, “Architectural guidelines for multipath tcp development,” RFC6182, Internet Engineering Task Force, Mar 2011.
