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 B. de Paula, Rafael Pasquini, Fábio L. Verdi, Maurício F. Magalhães School of Electrical and Computer Engineering (FEEC) State University of Campinas (UNICAMP) - 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 a primary issue to be considered. In this paper we present a next generation internetworking architecture to overcome 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 seamlessly allows the deployment of new services, such as mobility, multi-homing and security. A prototype was implemented and evaluated considering some mobility scenarios, including intra-domain, inter-domain and simultaneous node mobility.

1 Introduction 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 multi-homing. 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 end-host 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 end-to-end identifier, releasing the IP address of this function. Also, this new name space 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 support 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 locators from identifiers. The identity name space 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 proposed architecture has similar functionalities 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 mobility, multi-homing with security embedded and transparently attend legacy applications. 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 proposed by Moskowitz et al [8] to add security mechanisms for end-hosts to self-claim their identities. 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 previous service model by proposing additional mechanisms for name resolution, service discovery, control plane and legacy application support. To evaluate our proposal, a prototype was implemented and tested considering mobility, multi-homing, identity-based routing and legacy application support. 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.

2 Related work The architecture proposed in this paper adopts 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.

ity 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.

3 Architecture Proposal In this section we present our architecture proposal. First, we describe the requirements for mobility and multihoming support. Then, we propose mechanisms to fulfill these requirements to transparently support legacy applications. The first requirement for the mobility support is the introduction of a static identifier to which legacy applications can bind during mobility events. 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 consists of security mechanisms embedded in the architecture to authenticate and protect the communications between end-hosts. All the requirements are individually discussed below.

3.1

Figure 1. Node ID Architecture. The NodeID architecture considers that all entities have a Node Identifier (NID). The NID is a static flat identifier used to globally identify the end-hosts over the internet, natively enabling services like mobility and multi-homing. The NodeID architecture proposes a routing model based on a pair of identifiers: the end-host NID and the identifier of the end-host NR attached to the Core, called Core Gateways NID (NIDGW). First, a packet using identifiers is routed on the end-hosts identifiers. If the destination end-host is located in another edge-tree, then the packet is routed on the NIDGW until it reaches the destination NR attached to the Core. Once arriving in the destination NR, the packet is routed on the end-host identifier again. 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 statically forwarded toward the Core. 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 scalabil-

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 Moskowitz 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, similar to the NID of the NodeID Architecture. The ID provides a stable end-point to which applications can bind, preventing the connection disruption 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 identifier relies on the overlay network created by the introduction 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 the PANs and VANs that connect to the Internet. Figure 2 shows the identification header (IDH) of our proposal used by the identifier-based routing model. It has a 4-bit field for the prototype version, 4-bit field for the message type, 8-bit reserved field for further use (e.g. quality of service), 16-bit field for the payload length, four 128-bit fields to store the source and destination pair of identifiers ID and IDGW. Finally, the legacy packet is carried in the data field.

Figure 2. Identification header (IDH).

3.2

Mobility/Multi-homing Support

Although the mobility feature comes naturally from the identity-locator split, additional mechanisms are required to fully support the mobility. One of these mechanisms is the location management of the mobile nodes. Mobile nodes 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. mobile node’s locator, since the DNS relies heavily on caching. Dynamic networks, where nodes 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 trade-off 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 into a pair of static identifiers, the destination end-host ID and the destination IDGW. The Rendezvous Server (RVS) will be responsible for the identifier to locator resolution. Our proposed RVS differs from Host Identity Protocol (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: intradomain and inter-domain. In the intra-domain mobility, the mobile nodes move within a domain, restricting the signaling to the local scope of the mobility. This approach is similar to micro-mobility, where the information related to the

mobility is hindered within a domain, preventing the overhead due to the control plane signaling over the Internet. The inter-domain mobility scenario is similar to the macromobility. Mobile nodes that move to different destination domains propagate signaling over the Internet, informing all Gateways in the path about the mobility event. In an intra-domain mobility scenario, the mobile node sends a control message informing its new locator to all peer nodes and also updates its current ID to locator mapping in the RVS. In an inter-domain mobility scenario, the architecture does not employ the end-to-end control message informing the mobile node’s new locator, since it may be using a different internetworking technology. To avoid inter-domain mobility scenarios where the mobile nodes become unreachable after an inter-domain mobility, we propose a cache-based mechanism to implicitly detect the mobility event of peers. For each peer, a mobile node has an entry mapping the peer node’s ID to the locator with an expiration time associated. After the mapping expiration, the node queries in the RVS to get a updated ID to locator mapping of the peer node. In a scenario where a mobile node moves to other domain, the peer node queries the RVS and receives the mobile node’s updated locator, restoring the previous communication. The cache-based mechanism is particularly interesting in inter-domain mobility scenarios where the mobile node receives a data flow using stateless protocols, such as UDP. Normally the mobile node does not send any piggyback message to the peer node, which transmits the data flow, since it is unidirectional. Thus, the peer node is not aware about any mobility events of the mobile node. With the timeout mechanism, the peer node periodically queries the RVS for a updated mapping of the mobile node’s locator, maintaining a correct ID to locator association even when the mobile node moves. There is also another advantage in this mechanism when stateful protocols are employed, such as TCP. As TCP is bidirectional, both nodes exchange packets and can update their peer’s ID to locator mapping by inspecting the current mapping in the IDH since the communication is secured. Thus, both mobile nodes reduce the number of queries at the RVS and the signaling needed to maintain the end-to-end connectivity.

3.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 Iptables module and inserted in our architecture. Every single packet receives an IDH and is sent 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.

3.4

to return additional parameters, such as the default router and the local RVS.

Security

For the security requirement, we propose the use of cryptographic identifiers and secure mechanisms 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 identifiers, 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. Nodes send their certificates to peer nodes to verify the authenticity, and Diffie-Hellman parameters are exchanged to establish a symmetric session key, providing end-to-end authentication and confidentiality. The same security procedure is done when establishing connections with other nodes.

4 Implementation Design Figure 3 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. The external modules provide services for the nodes of the architecture, such as legacy name resolution, identifier 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

Figure 3. Architecture proposal. The internal modules provide services to support mobility, legacy applications and security. We discuss them through an example. First, legacy applications request a typical name resolution, that is intercepted by the DNSHandler module. This modules queries the standard DNS and returns the destination pair ID and IDGW. Legacy applications bind to the ID (or the 32-bit ID) instead of the locator and send these packets to the network (Fig. 4a). 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 searches for the correspondent security association for that 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. 4b). After the packet is encrypted, 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 (Fig. 4c).

Figure 4. Packets through the modules of the architecture. When the packets arrive at the peer node, 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. 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 registration of mobile nodes, flow redirection, security parameters negotiation and identifier resolution. The mobile node’s registration procedure occurs whenever a node bootstraps or arrives in a new domain. In this case, the mobile node sends a REGISTRY control message to the local RVS informing its new locator. The REGISTRY control message is propagated towards the Internet Core, informing all the intermediate Gateways in the same edge-tree about the node’s new locator or the locator of the Gateway responsible for that node. The flow redirection control is performed by the REDIRECT control message and is only used in the intra-domain mobility scenario. Whenever a mobile node moves, the node sends a REDIRECT message informing its new locator to its peer node. Also, there is a REDIRECT_CORE control message that is exchanged between Core Gateways to notify about mobile nodes 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 expiration time. The identifier to locator resolution uses four control messages: RVS_UPDATE, RVS_ACK, RVS_REQUEST and RVS_RESPONSE. A mobile node updates its locator in the RVS through the RVS_UPDATE message and the RVS acknowledges with a RVS_ACK message. Nodes sends a RVS_REQUEST control message to resolve the identifier into one or more locators, and receive a RVS_RESPONSE control message with the requested information.

Figure 5. Intra-domain mobility scenario. til it reaches the Core Gateway, informing all intermediate Gateways about the new ID to locator mapping. The registration procedure is important to notify the arrival of a new node in an edge-tree attached to the Core. The communication between nodes A and B is restored after the ID to locator mapping of one of the nodes expires (timeout mechanism). Then, it is made a new request to update the ID to locator mapping of the peer node, retrieving the correct locator. In fact, the timeout mechanism is enough to restore the communication due to the default routing towards the Core and also due to the registration mechanism that makes the reachability possible.

5 Scenarios This section presents some intra-domain, inter-domain and multi-homing scenarios. Figure 5 shows an intra-domain mobility scenario where two mobile nodes A and B are communicating. Node A moves within the same domain and receives a new locator from a DHCP server of the domain. In order to restore the previous communication with node B and remain globally reachable, node A sends a REDIRECT control message to node B informing its new locator and updates its locator in the RVS using the RVS_UPDATE control message. Figure 6 shows an inter-domain mobility scenario. First, mobile node A is communicating with peer node B, when node A moves to domain Y. After node A receives a new locator, it updates the new ID to locator mapping in the RVS in domain Y. The RVS sends a REGISTRY message to the domain gateway GW1 informing the arrival of node A and its ID to locator mapping. This message is propagated un-

Figure 6. Inter-domain mobility scenario. The simultaneous node mobility is a special case of the mobility scenarios. In this scenario, two mobile nodes are communicating when both nodes move to other locations. In the intra-domain scenario, after the mobile nodes receive their new locators, both nodes update their locators at the domain’s RVS and send a REDIRECT control message informing the peer nodes about their new locator. As the REDIRECT was sent to the old locator, it will not reach the destination. After the ID to locator mapping expires in one mobile node, a new ID to locator resolution is made, retriev-

ing the peer node’s current locator and restoring the communication. In the inter-domain scenario, there is no REDIRECT message and the communication is restored due to the timeout mechanism as explained above. Figure 7 shows a multi-homing scenario where node A is multi-homed and is downloading a file from node B. Node A is currently using the link 1 to reach B when link 1 fails. Then node A dynamically switches to link 2 without breaking the file transfer. The architecture transparently supports the multi-homing since legacy applications bind to the identifier instead of the locator, allowing the dynamic change of the network interface.

than wired. The second prototype evaluation considered the mobility scenarios depicted in Fig. 8. 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 (AP) 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 due to e.g., packet loss in wireless networks, as shown in the experimental results.

Figure 7. Multi-homing scenario.

6 Implementation and Evaluation 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 legacy application support involves 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 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]. The first prototype evaluation considered the overhead of a 224 MB file transfer time in wired and wireless scenarios using two Pentium4 3.0 GHz HT, 1 Gb RAM, NIC 100 Mb/s using Linux Debian.In the wired scenario, there is a reduction of 17,4% in the transmission rate (11,2 MB/s without the prototype, 9,54 MB/s using the prototype). This overhead is due to the user space implementation and IP+UDP encapsulation. In the wireless scenario,the overhead is lower compared to the wired scenario (9,3%) since the transmission rate in wireless scenarios (2,58 MB/s without the prototype, 2,36 MB/s using the prototype) are slower

Figure 8. Mobility scenarios tested with the prototype. The prototype was evaluated through two performance tests in the mobility scenarios described in Fig. 8: file transfer time and packet loss. We run 10 times each scenario to collect the results. Tab. 1 shows the file transfer time using the Secure Copy (SCP) tool to transfer a 224MB file between nodes. Scenario A shows an intra-domain mobility with both nodes within domain 1 and R moves within domain 1. Scenario B shows an inter-domain mobility with both nodes in domain 1 and R moves to domain 3. Scenario C shows an inter-domain mobility with both nodes in their home domains (domains 1 and 3) and then R moves to domain 1. By home domain we mean the domain where the node registered its FQDN. Scenario D shows an interdomain simultaneous node mobility. Table 1. File transfer time using SCP. Scen time (s) stdev AP (ms) stdev A 97.94 1.73 1,923 223 B 101.46 1.69 2,313 293 C 102.42 1.94 2,118 277 D 144.72 13.9 2,251 331

Scenario A has better performance due to the REDIRECT control message and to the local scope of the mobility. Thus, the ongoing communication is restored faster than other mobility scenarios. Scenarios B and C shows the delay introduced due to the global scope of the mobility. Intermediate Gateways are informed about the mobility event and propagates the new registration of the arriving node. Scenario D 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. All scenarios using the TCP are influenced by the delay introduced by the sliding window and slow start of the TCP control algorithms. During the mobility event, the packet loss reduces the sliding window, decreasing the file transfer rate between the nodes and the slow start algorithms delays the increase of the transfer rate, resulting in a higher transfer time. The second test measured the performance through the packet loss of a UDP transmission. Tab. 2 shows the results obtained considering the mobility scenarios depicted in Fig. 8. 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 1. Scenario II shows the inter-domain mobility with R moving to domain 2. Scenario III shows both nodes in domain 1, and R moves to its home domain 3. Scenario IV shows S in its home domain 1 and R in home domain 3, and R moves to domain 4. Scenario V shows S in its home domain 1 and R in its home domain 3, and R moves to domain 1. Scenario VI shows S in its home domain 1 and R in domain 4, and R moves to its home domain 3. Scenario VII shows the inter-domain simultaneous node mobility, where S is in domain 1 and R in domain 3 and both nodes move to different domains. Scen I II III IV V VI VII

Table 2. UDP packet loss. pkt loss(%) stdev(%) AP (ms) 6.01 1.01 2,568 15.46 1.60 2,434 16.81 2.85 2,344 18.46 1.72 2,622 7.23 1.48 2,223 16.93 4.90 2,423 25.78 6.57 2,378

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 configured 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 mobility. The scenario VII is the worst case because the peer cache of both nodes must be cleaned before the convergence of the communication.

7 Considerations 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. 9: 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 supported by the DNS server.

stdev 306 365 162 190 315 281 251

The data collected from the mobility scenarios using the JTG traffic generator shows that packet loss in the intradomain mobility is the lowest in Tab. 2 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 mobile node moves to the same domain of

Figure 9. Incremental deployment scenario. 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 infrastructure may be reused without modifications.

8 Conclusion In this paper we presented a next generation internetworking architecture to provide new services, such as mobility and multi-homing, through the insertion of an identification layer. By solving the IP semantic overload, the mobility and multi-homing 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. To validate the proposed architecture, we implemented a prototype and performed a set of tests considering some intra-domain, 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 17,4% in the file transfer time. 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 identifier-based overlay network, they are able to use all the proposed benefits of the architecture without any modifications. As future work, we will compare with other proposals, such as Mobile IP (MIP) and Host Identity Protocol (HIP). We are also working on domain mobility, where each domain has an identifier and will be able to move and carry all nodes within the domain to other location, similar to a PAN or a VAN. Another topic is the domain composition, where domains may compose betwen them to exchange services and resourses through well-defined policies between the parties.

References [1] R. Jain. “Internet 3.0: Ten Problems with Current Internet Architecture 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 International 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. 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 PublicKey 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://bamboodht.org/ [18] PlanetLab, http://www.planet-lab.org/ [19] F. Bellard. Qemu - Open Source Processor Emulador, http://fabrice.bellard.free.fr/qemu/.