An Architecture for Mobility Support in a Next Generation ... - CiteSeerX

An Architecture for Mobility Support in a Next Generation Internet Walter Wong, Rodolfo Villaça, Luciano Paula, Rafael Pasquini, Fábio L. Verdi, Maurício F. Magalhães Department of Computer Engineering and Industrial Automation (DCA) School of Electrical and Computer Engineering (FEEC) State University of Campinas (UNICAMP) P.O. Box 6.101 - 13083-970 - Campinas - SP - Brazil Email: {wong, villaca, luciano, pasquini, verdi, mauricio}@dca.fee.unicamp.br

Abstract—The current internetworking architecture presents some limitations to naturally support mobility, security and multihoming. Among the limitations, the IP semantic overload seems to be the primary issue to be considered. The IP address is used as identifier in the transport layer and as topological locator in the network layer, creating an interdependency between the layers. In this paper we present a next generation internetworking architecture to solve the IP semantic overload by introducing an identity layer located between the network and transport layers. This new layer provides a stable cryptographic identifier for end-hosts and seamlesslly allows the deployment of new services, such as mobility, multihoming and security. Our proposal can be incrementally deployed in the Internet through the use of a Distributed Hash Table to integrate the domains, creating an overlay network based on the identity layer. A prototype was implemented and evaluated considering some mobility scenarios, including intra-domain, inter-domain and simultaneous node mobility.

I. I NTRODUCTION The current Internet architecture presents some technical barriers to the introduction of new services [1]. Among these limitations, the IP semantic overload seems to be one of the primary issues that retards the natural deployment of new services, such as mobility and multihoming. As pointed by Saltzer [2], there is an ambiguity of network objects and their locations. The IP address is both used as object identifier in the transport layer and as topological locator in the network layer, creating an interdependency between the identity of an endhost and its location resulting in a lack of a stable identifier. Some proposals, e.g. LIN6 [3] and FARA [4], introduce an identification name space to overcome the lack of a stable endto-end identifier, releasing the IP address of this function. Also, this new namespace creates an overlay network based on the identity which allows the deployment of the aforementioned services. In this paper we propose a new Internet architecture to naturally suppport new services by introducing an identity name space between the network and transport layers. The architecture adopts a global identity space and does not require global addressing or a shared internetworking protocol. It allows the integration of new concepts, such as dynamic network composition, with other recent architectural concepts, such as

splitting locators1 from identifiers. Instead of mapping humanreadable host names directly into network addresses, as in the Internet’s Domain Name System (DNS), the architecture firstly maps host names to hosts identifiers. A second resolution translates end-host identifiers to host addresses that are suitable for network-layer data forwarding. The architecture manages the global name and identity spaces, whereas the address space is local to each individual autonomous network. The identity namespace creates an overlay network which provides routing services based on the identity layer, enabling the communication between the autonomous domains, as described in [5]. The architecture assumes that each node belongs to a completely autonomous network and the communication between these nodes occurs solely taking into account global identifiers. The architecture has a control plane similar to the one proposed in TurfNet [6] and in Plutarch [7], and is responsible for the name resolution, location management, security and legacy application support. Although the idea of providing new services based on an overlay network and stable identifiers is not new, some of them require changes in the operating system, which may become a burdensome task to overcome. Our main contribution is to provide a next generation Internet architecture to support new services while transparently attend legacy applications without any modifications in the operating system. Our architecture can also be incrementally deployed over the current Internet through the use of a global mapping service like a Distributed Hash Table (DHT), connecting all autonomous domains in the identity overlay network. The architecture’s security model works on the identity layer, providing authentication, data integrity and confidentiality. We employ the cryptographic host identifier described by Nikander et al [8] to add security mechanisms for endhosts to self-claim their identities embedding security on the communication. The architecture provides a routing service based on the identifiers by adopting the model described by Ahlgren et al [9] and integrates it with the identity-based overlay network. We extend the proposed routing model by going deeper in name resolution, service discovery, control plane and legacy application support. A prototype was imple1 A locator is commonly used as a topological network address, e.g., IP address.

mented to validade our proposal considering mobility, multihoming, identity-based routing and legacy application support. We performed intra-domain, inter-domain and simultaneous node mobility during a file transfer using a legacy application. The organization of this paper is as follows. Section 2 presents the related work. Section 3 describes the architecture proposal and discusses the project decisions. Section 4 presents the implementation and evaluation of the prototype. Finally, Section 5 summarizes this paper and discusses future work. II. R ELATED WORK The architecture proposed in this paper uses the routing model proposed by the Node Identity Internetworking Architecture (NodeID) [9]. The NodeID architecture simplifies the current Internet topology by considering the existence of a Core on the top level of the Internet, which encompasses all static domains, and non-core domains attached to the edge of the Core domain, e.g. PANs and VANs, as shown in Fig. 1. There are few domains in the Core and they remain mostly static. Non-core domains are considered dynamic and attach to the edge of the Core arranging into a tree-like structure. Each domain has a NodeID Router (NR) responsible for the communication with other domains. The NR’s main role is to map and translate different internetworking technologies between the domains. NRs attached to the Core have their identities and locator stored in a Distributed Hash Table (DHT), which is distributed across the Core.

Fig. 1.

Node ID Architecture.

The NodeID architecture considers that all entities have a Node Identifier (NID). The NID is a static flat identifier which allows hosts to communicate even during mobility events. The NodeID architecture proposes a routing model based on the end-host NIDs and their NRs attached to the Core NIDs, called Core Gateways NID (NIDGW). The flat routing model in the NodeID architecture considers three regions: the edge tree, the Core, and between Cores. In the edge tree, the NodeID adopts a static route approach. NIDs that are not resolved locally (inside a given domain) are forwarded towards the Core based on the NID. In the Core, Core NRs resolve the destination Core NR in the DHT and forward the packets to

the destination. This loosely-coupled route approach avoids the insertion of all NIDGWs in the DHT, which may compromise the scalability and efficiency. Routing between Cores uses the DHT to resolve the destination Core NR into a locator and forwards packets to the destination Core NR of the end-host. III. A RCHITECTURE P ROPOSAL In this section we present our architecture proposal. Firstly, we describe the requirements for mobility and multi-homing support. Then we propose mechanisms to fullfill these requirements to transparently support legacy applications. A. Requirements The first requirement for the mobility support is the introduction of a static identifier to which legacy applications can bind during mobility events. This identifier should be static and globally identify an end-host over the Internet. Also, there must be a mechanism to route packets in the overlay network created by the introduction of the identity. The second requirement is an infrastructure to which a mobile node may update its current location and remain reachable to other end-hosts. The third requirement is the mobility transparency to higher layers. Legacy applications should be supported transparently and communications should remain open even during mobility events. Finally, the forth requirement is to offer a security mechanism to authenticate and protect the communications between end-hosts. All the requirements are individually discussed below. 1) Identification: We propose the insertion of a new name space to globally identify end-hosts over the Internet. The new name space is located between the network and transport layers and consists of static identifies. We employ cryptographic identifiers as proposed by Nikander et al [8], where the identifiers are the public key of a pair of asymmetric key and the hash of these identifiers are the 128-bit identifier (ID) of an end-host. The ID provides a stable end-point to which applications can bind, preventing the disruption of the connection during mobility events. The ID dynamically binds to the network layer, naturally enabling the mobility since the IP semantic overload problem is solved. Therefore, the network layer is just responsible for the packet delivery service, not identifying the end-hosts anymore. The packet delivery service based on the identity is provided by the overlay network created by the insertion of the identity name space in the network stack. The routing model is based on the flat routing scheme of the NodeID architecture. The routing scheme uses a static routing approach towards the Core and takes into account two identifiers to take the routing decision: the destination identifier (ID) and the destination Core Router (or Gateway ID) IDGW. This approach establishes a loosely-coupled routing where packets are firstly routed based on their destination ID and then on their destination IDGW when reaching the Core. The advantage of this approach is the simplicity of the flat routing scheme and presents a compatible model of the current Internet, where the Core represents the

current Internet and the edge-trees represent the PANs and VANs that connect to the Internet. Figure 2 shows the identification header (IDH) of our proposal used by the identity-based routing model. It has a 4-bit field for the version, 4-bit field for the message type, 8bit reserver field for further use (e.g. quality of service), 16-bit field for the payload length and four 128-bit fields to store the source and destination pair of identifiers ID and IDGW.

Fig. 2.

Identification header (IDH).

2) Mobility/Multi-homing Support: Although the mobility feature comes naturally from the identity-locator splitting, additional mechanisms are required to completely support the mobility. One of these mechanisms is the location management of the mobile nodes (MN). Nodes which are mobile must have a common place to update their location after a mobility event, maintaining its reachability over the Internet. The location management is achieved through the use of the Domain Name Service (DNS) and a rendezvous mechanism responsible for the node’s location storage. Some proposals [11] consider the DNS as not suitable for dynamic information storage, e.g. MN locator, since the DNS relies heavily on caching. Dynamic networks, where MNs move in a short period of time, may require the use of zero TTL DNS registries, increasing the load on root servers. This is a tradeoff between scalability and fast locator updates. Since the DNS was not conceived for mobile environment, we propose the separation of the name resolution from the locator update mechanism. The DNS will map the name resolution into a pair of identifiers, the destination endhost ID and the destination IDGW, which are static and do not change frequently2. The Rendezvous Server (RVS) will be responsible for the identity to locator resolution. Our proposed RVS differs from HIP proposal [12], since in our architecture it maps identifiers into locators and also acts as a location update place. Likewise the DNS, there is a local RVS in each domain where all nodes update their locators. We separate the mobility event in two types: intra-domain and inter-domain. In the intra-domain mobility, the MNs move within a domain, restricting the signalling to the local scope of the mobility. This approach is similar to micro-mobility, where the information related to the mobility is hindered within the 2 In

general, such identifiers will never change.

domain, preventing the overhead due to the control plane signalling over the Internet. The inter-domain mobility scenario is similar to the macro-mobility. MNs are located in different domains and move to other (also different) domains. In this case, the signalling is propagated over Internet, informing all Gateways in the path about the mobility event. One optimization for the location management is a mechanism to implicitly detect mobility events. In an intra-domain mobility scenario, whenever a MN moves within a domain, it sends a control message informing its new locator to all Correspondent Nodes (CN). In an inter-domain scenario, the control message is not present since the domains may use different internetworking technologies. To avoid inter-domain mobility scenarios where the MN moves to another domain and becomes unreachable, we propose a cache-based mechanism to implicitly detect the mobility event of peers. For each peer, the MN has an entry mapping the CN’s ID to the locator associated with a validity. After the mapping expiration, the MN must query the domain’s RVS for a updated mapping for that ID. If the MN had moved, the CN will receive the updated locator, restoring the previous communication. This mechanism is particularly interesing in inter-domain mobility scenarios where the MN receives data flow using a stateless protocols such as UDP. Normally the receiving CN does not send any piggyback message to the MN, so the MN does not know when the CN has moved. With the timeout mechanism, the MN will periodicaly query the domain’s RVS for the updated location of the CN, maintaining the correct ID to locator association even when the CN moves. In a scenario where the MNs are using a stateful protocol, e.g. TCP, there is another implicit optimization. As the TCP is bidirectional, both MNs can update their peer’s ID to locator mapping by inspecting the current mapping on the IDH since the communication is secured. Thus, both MNs reduce the number of queries at the RVS and the signalling needed to maintain the end-to-end connectivity. Figure 3 shows an intra-domain mobility scenario where two mobile nodes A and B are transfering a file. Node B moves within the same domain and gets its new locator. B updates its current locator in the RVS and sends a control message directly to A informing its new locator. Thus, B remains globally reachable since it updated its locator in the RVS and also restored the ongoing communication with A. Figure 4 shows a inter-domain mobility scenario. The main difference between this scenario and previous one is the absence of control messages informing the new locator. The MN does not send a control message since the CN may use different internetworking technology. The MN uses the timeout mechanism to request a newer ID to locator mapping at the domain’s RVS. The simultaneous node mobility is a special case of the mobility scenarios. Two MNs are communicating when both MNs move to other locations. After the MNs receive their new locators, they update their locators in the domain’s RVS and send a control message to the peer informing its new locator. As the control message was sent to the old locator, it will not reach the destination. After the ID

Fig. 5. Fig. 3.

to locator mapping expires in one MN, a new ID to locator resolution is made, retrieving the CN’s current locator and restoring the communication.

Fig. 4.

Multi-homing scenario.

Intra-domain mobility scenario.

Inter-domain mobility scenario.

Figure 5 shows a multi-homing scenario where node A is multi-homed and is downloading a file from node B. A is currently using the link 1 to reach B when it fails. Then A dynamically switch to link 2 without breaking the file transfer. The architecture transparently supports the multi-homing since legacy applications bind to the identity instead of the locator, allowing the dynamic change of the network interface. 3) Transparency: Legacy applications are transparently supported through the use of legacy name resolution proxies and legacy packets interceptors. The former intercepts all name resolutions from legacy applications and translates to identifiers resolution. Given a FQDN of an end-host, the proxy will request a TXT type registry in the DNS, containing the destination ID and the destination IDGW of the end-host. Based on the type of the name resolution (A or AAAA), the proxy will return either the 32-bit identifier or the 128-bit identifier. The 32-bit identifier is derived from the ID and is used to support legacy IPv4 applications. The legacy packets

interceptor mechanism is necessary since all legacy packets need the identification header to use the provided services. Legacy packets are captured by using Iptables modules and inserted in our architecture. Every single packet receive the IDH and is encapsulated in an IP+UDP tunnel. Finally, the packet issent to the destination end-host. Once arriving at the destination, the IDH is removed and the packet is delivered correctly (and transparently) to the legacy application. 4) Security: For the security requirement, we propose the use of cryptographic identifiers and secure ways to add and modify entries in the DNS and RVS. The use of cryptographic identifiers enable transaction authentication, since identifiers can be checked against the public key provided by a Public Key Infrastructure (PKI) [14]. Secure insertion or modification in the DNS are provided by the adoption of the DNSSec extension [13]. As DNS holds fairly static information about identity, nodes must authenticate before any modification in the DNS server, preventing attacks such as DNS cache poisoning. In the RVS, all nodes must establish a security association before any insertion or modification. This association is negotiated during the bootstrap process or whenever a node arrives at a new domain. MNs send their certificates to CNs to verify the authenticity, and Diffie-Hellman parameters are exchanged to establish a symmetric session key, providing endto-end authentication and confidentiality. The same security procedure is done when establishing connections with other nodes. B. Architecture Design 1) Control Plane: In order to provide mechanisms to exchange control messages between the components of the architecture, we propose a control plane responsible for control message delivery and reconfiguration of the components. Some relevant services are the MN registration procedure, flow redirection, security parameters negotiation and identifier resolution. The MN’s registration procedure occurs whenever a MN bootstraps or arrives in a new domain. In this case, the MN sends a REGISTRY control message to the local RVS informing its new locator. The REGISTRY message is propagated towards the Internet Core, informing all the

intermediate Gateways about the MN’s locator or the locator of the Gateway responsible for that MN. The flow redirection control is performed by the REDIRECT control message and is used in the intra-domain mobility scenario. Whenever a MN moves, the node sends a REDIRECT message informing its new locator to the CN. Also, there is a REDIRECT_CORE control message that is exchanged between Core Gateways to notify about MNs that are under each Core Gateway. The security parameters negotiation is performed by the SEC_CTRL control message. It is responsible for negotiating the security parameters, such as the encryption algorithm, the symmetric key and the validity. The identifier to locator resolution uses four control messages: RVS_UPDATE, RVS_ACK, RVS_REQUEST and RVS_RESPONSE. A MN updates its locator in the RVS through the RVS_UPDATE message and the RVS acknowledges with a RVS_ACK message. A MN resolves the identity into one or more locators by sending a RVS_REQUEST message and the server replies with the RVS_RESPONSE message, containing the requested information. 2) Implementation Design: Figure 6 shows our architecture proposal, mapping the proposed functionalities into modules. The functionalities are divided in external and internal modules. The external modules are components of the architecture that provide services for the end-hosts. The internal modules are components that provide services within each end-host, and are divided in data and control planes. Data plane modules are involved in the data delivery, IDH management and flat routing. The control plane is responsible for signaling messages exchanged between components of the architecture, such as registry and redirect messages.

Fig. 6.

Architecture proposal.

The external modules provide services for the nodes of the architecture, such as legacy name resolution, identity to locator resolution and service discovery. The legacy name resolution is separated in two steps: the resolution of a name (FQDN) into a pair of identifiers (ID, IDGW) and the resolution of an identifier into one or more locators. The first step is done by

querying the DNS and the second step is done by querying the RVS, or DHT in the case of routing in the Core. The service discovery mechanism is provided by a DHCP server in each domain, which must be modified to return additional parameters, such as the default router and the local RVS. The internal modules provide services to support mobility, legacy applications and security. We discuss them through an example. Firstly, legacy applications request a typical name resolution, that is intercepted by the DNSHandler module. This module is a proxy which translates standard queries (A or AAAA) into name to identifiers resolution (type TXT). The DNS TXT type in our architecture returns the destination ID and the destination IDGW. As the legacy applications are not aware about the IDGW, the DNSHandler module stores the ID to IDGW mapping in the ID Mapper (IDM) module. This information will be used for the creation of the identification header. Legacy applications bind to the ID (or the 32-bit ID) instead of the locator and send these packets to the network (Fig. 7a). Such legacy application packets are captured by the Filter module and sent to the Packet Handler module. This module inserts the IDH and uses the IDM module to obtain the destination IDGW. The IDM module was previously populated by the DNS Handler module during the name resolution procedure. After receiving the IDH, the legacy packet is forwarded to the Security module, which will search for the correspondent security association for the ID in the Security Association Database. These security associations are exchanged using the SEC_CTRL message, which uses the Diffie-Hellman algorithm during the authentication phase. The security association also establishes a symmetric key to provide end-to-end integrity and confidentiality (Fig. 7b). After the packet be encrpypted, it is forwarded to the Routing module, which resolves the ID to locator mapping in the Peer Cache and sends to the network through IP+UDP encapsulation (Figure 7c). When the packets arrive at the CN, the reverse operation is performed by the Routing, Security and Packet Handler modules to receive the packets, check the security parameters, remove the IDH and deliver the legacy packet to the application.

Fig. 7.

Packets through the modules of the architecture.

The control plane has six internal modules to provide endto-end signaling messages between nodes. The Mobility module deals with mobility related events, such as locator changes, new access point associations, and REDIRECT messages. The Security Manager module is responsible for the security association establishment based on the MN’s identifiers. The

RVS client module performs all RVS interactions, such as ID to locators resolutions and locator updates. Similar to the RVS client module, the DHT module interacts with the DHT in the Core to resolve IDGWs into locators. DHCP client module retrieves additional information related to a domain, such as the default router and local RVS. Finally, the Gateway Message Service module propagates REGISTRY messages towards the Core. This service informs all routers in the path towards the Core about routing information and registration of nodes that are below in the same tree. IV. I MPLEMENTATION AND E VALUATION This section presents the implementation of a prototype and evaluates it considering some mobility scenarios. Firstly, we describe the implementation decisions, then we present the prototype evaluation and finally we discuss the results. The prototype is a user space implementation and all prototype modules were implemented using C language. Legacy applications support uses mainly two modules: Filter and DNSHandler. The former uses the Iptables tool to capture legacy packets sent to a virtual interface whose address is the node ID. The virtual interface provides a stable network attachment point for legacy applications and it is available through the Tun/Tap module in the Linux kernel. The DNSHandler intercepts all DNS queries and changes the record type, from A or AAAA to TXT, and sends to DNS. After receiving the response, it stores both ID and IDGW in the IDM, and returns the ID or 32-bit ID to the legacy application. The service discovery feature is implemented using the DHCP. The DHCP server was modified to return the additional information of a domain, and the DHCP client was adapted to interpret these information and reconfigure the prototype. For the resolution service in the Core, the prototype used the Bamboo DHT Implementation [16] due to the possibility of either deploying a local instance or testing in the PlanetLab [18]. Figure 8 shows the overhead of the prototype in wired and wireless scenario. In the wired scenario, there is a reduction of 17,4% in the transmission rate. This overhead is due to the user space implementation and IP+UPD encapsulation. In the wireless scenario, the overhead is lower compared to the wired scenario (9,3%) since the transmission rate in wireless scenarios are slower than wired. The prototype evaluation was done considering some mobility scenarios shown in Fig. 9. We used five Pentium4 3.0 GHz HT to represent 4 domains (A, B, C, D), one static node (S) with a wireless interface, and one Pentium Duo 1.8 GHz notebook to be the mobile node (R). Each static machine runs a QEMU virtual machine [19] to host the RVS and the DNS of a domain (not included in the figure). Mobility events have two time values associated: the access point association time and the DHCP response time. We did not take into account the association time since it depends on the hardware and on the driver. The wireless card of the experiment is a DellNIC and has an association time of 1825ms. The DHCP response time varies in the prototype

Fig. 8.

Prototype overhead in different scenarios.

due to e.g., packet loss in wireless networks, as shown in the experimental results.

Fig. 9.

Mobility scenarios tested with the prototype.

The prototype was evaluated through two performance tests in the mobility scenarios described in Fig. 9: file transfer time and packet loss. We run 10 times each scenario to collect the results. Table I shows the file transfer time using the Secure Copy (SCP) tool to transfer a 224MB file between nodes. Scenario A shows two static nodes transferring the file without the prototype. Scenario B shows two static nodes transferring the same file using the prototype. Scenario C shows an inter-domain mobility with both nodes in domain A and then R moves to domain C. Scenario D shows an interdomain mobility with both nodes in their home domains and then R moves to domain A. By home domain we mean the domain where the node registered its FQDN. Scenario E shows an inter-domain simultaneous node mobility. Scenarios C and D show the delay introduced by the mobility event and also by the TCP sliding window. During the mobility event, the packet loss reduces the sliding window, decreasing the file transfer rate between the nodes. Scenario

TABLE I F ILE TRANSFER TIME USING SCP. Scen C D E

rate (MB/s) 2.18 2.18 1.3

stdev 0.04 0.04 0.15

time (s) 101.46 102.42 120.60

stdev 1.69 1.94 13.9

assoc (ms) 2313.31 2118.19 1876.64

stdev 293.05 277.19 331.48

E shows the simultaneous node mobility, which is the worst case because S will only send packets to the correct IDGW after it receives the first ACK from R informing the current IDGW. Also, it is influenced by the sliding window of TCP. The second test measured the performance through the packet loss of a UDP transmission. Tab. II shows the results obtained considering the mobility scenarios depicted in Fig. 9. The test was performed using the JTG [15] traffic generator, packet size of 1300 bytes and constant bit rate of 20 Mb/s during 60 seconds. Scenario I shows an intra-domain mobility with S and R within domain A. Scenario II shows the interdomain mobility with R moving to domain B. Scenario III shows both nodes in domain A, and R moves to its home domain C. Scenario IV shows both nodes in domain A and R moves to domain D. Scenario V shows S in its home domain A and R in its home domain C, and R moves to domain A. Scenario VI shows S in its home domain A and R in domain D, and R moves to domain A. Scenario VII shows the interdomain simultaneous node mobility, where S is in domain A and R in domain C and both nodes move to different domains.

mobility. The scenario VII is the worst case because the peer cache of both nodes must be cleaned before the convergence of the communication. V. F INAL R EMARKS In this section we present our final remarks about our proposal. We will mainly discuss the benefits of the proposed architecture considering deployment and legacy application support. The proposed architecture can be incrementally deployed over the Internet. The deployment of the architecture does not insert any modifications in the current network and requires only two steps as shown in Fig. 10: the registration of the identifier of the Core Gateway attached to the Internet in a DHT and the insertion of new DNS entries. The Core Gateways insert their IDGWs in the DHT located in the Core, creating an overlay network based on the identifiers. We assume there is a global DHT, e.g. [16], [17], to provide IDGW to locator resolution. The second step is to populate the DNS with registries mapping the FQDN into the pair of identifiers (ID, IDGW). This can be done without modifying the DNS since we use the type TXT registry, which is naturally suported by the DNS server.

TABLE II UDP PACKET LOSS . Scen I II III IV V VI VII

pkt sent 106936 106895 106821 106798 106862 106806 104074

stdev 88 85 157 91 137 89 3144

pkt loss(%) 6.01 15.46 16.81 18.46 7.23 16.93 25.78

stdev(%) 1.01 1.60 2.85 1.72 1.48 4.90 6.57

ass(ms) 2568.68 2434.46 2344.10 2622.86 2223.44 2423.96 2378.40

stdev 306.84 365.49 162.68 190.99 315.71 281.63 251.76

The data collected from the mobility scenarios shows that packet loss in the intra-domain mobility is the lowest in Table II due to the REDIRECT control message exchanged between peers. Basically, the packet loss is influenced by the association time of the wireless card (4% of the packet loss in 60 seconds) and delivery time of the REDIRECT message. Scenario V shows a small packet loss basically due to the registration procedure. The MN moves to the same domain of the sender, and registers in the domain’s router. Outgoing packets are immediately forwarded to the arriving node. Scenarios II, III, IV and VI are influenced by the ID to locator mapping timeout in the unidirectional link and communication across the Core, since it relays in the timeout mechanism to query for the new locator. The caching time is variable, and in our tests we set it to 5 seconds, affecting the communication restoration from 0 to 5 seconds depending on the TTL of the cache when the mobility event happened. So, it is expected a higher standard deviation in the mobility across the Core and packet losses using UDP traffic than intra-domain

Fig. 10.

Incremental deployment scenario.

Legacy applications are transparently supported by the architecture without any modifications in their source codes. The architecture introduces a new logical layer to identify the end-hosts over the Internet. It is seen as a logical layer because it does not introduce any modifications in the current network stack, but creates a new name space to which the legacy applications can bind. The architecture presents many benefits for the migration, such as mobility and multi-homing support and security embedded at a low cost, since many deployed infraestructure may be reused without modifications. Another benefit is the user space implementation of the architecture, which ease the migration without requiring any modifications in the operating system.

VI. C ONCLUSION In this paper we presented a next generation internetworking architecture to provide new services, e.g. mobility and multihoming, through the insertion of an identification layer. By solving the IP semantic overload, the mobility and multihoming are naturally enabled since the legacy applications have a stable identifier to bind during communications. In order to transparently support mobility, additional mechanisms were proposed such as RVS, modified DNS and mechanisms to filter and intercept legacy packets. The focus of this work was not only to support the introduction of new services but also to develop a next generation Internet architecture that attends the legacy applications without any modifications in their source code or in the operating system. To validade the proposed architecture, we implemented a prototype and performed a set of tests considering some intradomain, inter-domain and simultaneous mobility scenarios using legacy applications. We also analyzed the overhead due to the user space implementation and noticed there was an increase of 16,61% in the file transfer time. This overhead is mainly due to two factors: the user space implementation and the IP+UDP encapsulation. We chose to implement the prototype in the user space because it does not require modifications neither in the operating systems nor in the legacy applications. The proposed architecture can also be incrementally deployed over the Internet. Domains interested in joining the architecture need to register their IDGW in the DHT to communicate with each other and insert an entry in the DNS server, mapping its FQDN in the identification pair (ID, IDGW). After joining the identity-based overlay network, they are able to use all the proposed benefits of the architecture without any modifications. We envision that future applications may employ the use of identifiers instead of locators. In this way, the proposed architecture eases the introduction of an identity layer in the current network stack, since it already emulates an identity layer to provide mobility, multi-homing and legacy applications support. We are currently working on domain mobility and composition. Each domain in the architecture will have an identifier which will be used for flat routing purposes. Therefore, domains will be able to move and carry all MNs within the domain to another location, similar to a PAN or a VAN. The domain hinders the mobility event from the internal MNs, preserving any ongoing communications. The domain composition is another issue to be investigated as future work. A domain may compose with other domains to exchange services and resources through well-defined policies between the parties. This issue will be addressed in a future paper. R EFERENCES [1] R. Jain. “Internet 3.0: Ten Problems with Current Internet Architecure and Solutions for the Next Generation.” Military Communications Conference, 2006. MILCOM 2006, Washington, DC., Oct. 2006, pp. 1-9. [2] J. Saltzer. “On the Naming and Binding of Network Destinations.” RFC 1498, August 1993.

[3] M. Ishiyama, M. Kunishi, and F. Teraoka. “An Analysis of Mobility Handling in LIN6.” In Proceedings of Internation Symposium on Wireless Personal Multimedia Communication (WPMC) 2001. [4] D. Clark, R. Branden, A. Falk and V. Pingali. “FARA: Reorganizing the Addressing Architecture.” Proc. ACM SIGCOMM Workshop on Future Directions in Network Architecture (FDNA), Karlshule, Germany, August 2003, pp. 313-321. [5] W. Wong, R. Pasquini, R. Villaça, L. de Paula, F. Verdi, M. Magalhães. “A Framework for Mobility and Flat Addressing in Heterogeneous Domains.” In 250 Brazilian Symposium of Computer Networks and Distributed Systems (SBRC2007), Belém, Pará, Brazil, May 2007. [6] S. Schmid, L. Eggert, M. brunner and J. Quittek. “Towards Autonomous Network Domains.” Proc. 8th IEEE Global Internet Symposium, Miami, FL, USA, March 17-18, 2005. [7] J. Crowcroft, S. Hand, R. Mortier, T. Roscoe and A. Warfield. “Plutarch: An argument for Network Pluralism.” Proc ACM SIGCOMM Workshop on Future Directions in Network Architecture (FDNA), Karlshule, Germany, August 2003, pp. 258-266. [8] R. Moskowitz, P. Nikander. “Host Identity Protocol (HIP) Architecture.” RFC 4423, May 2006. [9] B. Ahlgren, J. Arkko, L. Eggert, J. Rajahalme. “A Node Identity Internetworking Architecture.” In Proceedings of the 9th IEEE Global Internet Symposium. In conjunction with IEEE Infocom. April 2006. [10] R. Moskowitz, P. Nikander, P. Jokela, and T. Henderson. “Host Identity Protocol (HIP) Base Exchange.” Internet-Draft, June 2007. [11] J. Jung et all. “DNS Performance and the Effectiveness of Caching.” IEEE trans. net, vol 10, no. 5, October 2002, pp. 589-603. [12] J. Laganier, and L. Eggert. “Host Identity Protocol (HIP) Rendezvous Extension.” Internet-Draft, June 7, 2006. [13] D. Eastlake. “Domain Name System Security Extensions.” RFC 2535, March 1999. [14] S. Lloyd, C. Adams. “Understanding the Public-Key Infrastructure: Concepts, Standards, and Deployment Considerations.” Sams, 1st edition, November 12, 1999. [15] Jugi’s Traffic Generator, https://hoslab.cs.helsinki.fi/savane/projects/jtg/ [16] S. Rhea, B. Godfrey, B. Karp, J. Kubiatowicz, S. Ratnasamy, S. Shenker, I. Stoica, and H. Yu. “OpenDHT: A Public DHT Service and Its Uses.” Proceedings of ACM SIGCOMM 2005, August 2005. [17] The Bamboo Distributed Hash Table, http://bamboo-dht.org/ [18] PlanetLab, http://www.planet-lab.org/ [19] Qemu, http://fabrice.bellard.free.fr/qemu/