Domain Identifiers in a Next Generation Internet Architecture - CiteSeerX

Domain Identifiers in a Next Generation Internet Architecture Rafael Pasquini, Luciano B. de Paula, F´abio L. Verdi, Maur´ıcio F. Magalh˜aes 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: {pasquini, luciano, verdi, mauricio}@dca.fee.unicamp.br Abstract—In this paper we make the domain entity a first class citizen. The concept of Domain Identifiers (DIDs) is introduced to effectively bring the domains to the next generation Internet scenario. The paper presents an architecture to address challenging next generation Internet requirements such as node and domain mobility, multi-homing, security, network composition and inter-domain routing. Although our architecture supports all the mentioned requirements, the focus of this paper is specifically on node and domain mobility in order to evaluate and compare the advantages of having DIDs for facilitating the mobility. First, we present the generic Next Generation Internet architecture proposal and its envisioned scenario. Then, we show how to instantiate it to work together with the current Internet. We have developed a prototype to evaluate our proposal and we depict results related to node and domain mobility under this gradual deployment scenario using the Internet as the core.

I. I NTRODUCTION Some of the most noticed Internet problems are the IP address space exhaustion, security attacks and the overload of the Border Gateway Protocol (BGP) tables impelled by multihoming and the usage of Provider Independent (PI) addresses to avoid nodes renumbering. Some of these problems were amended by punctual solutions such as Classless Inter-Domain Routing (CIDR), Network Address Translation (NAT), Mobile IP (MIP) and IPSec. However, these punctual solutions have some drawbacks such as the advertisement of more specific IP prefixes that causes a strong impact on BGP tables, especially on multi-homing scenarios, and NAT that breaks the seminal end-to-end communication principle of the Internet. More recently, the research community has focused on what a new Internet architecture should provide and in this context several proposals like Locator/ID Separation Protocol (LISP) [1], Node ID Architecture [2], Host Identity Protocol (HIP) [3], Routing on Flat Labels (ROFL) [4] and TurfNet [5] have appeared as next generation Internet architecture candidates aimed at providing new alternatives for the future Internet. Although domain mobility has not received much support in the last years and even in the above mentioned architectures, it has recently gained attention in some research projects such as Ambient Networks [6] and inside the IETF with the NEMO [7] (Network Mobility) WG. NEMO is focused specifically on mobility of IP networks and has recently received incentive for investigating issues related to Aviation, Automotive and

Personal Mobile Router cases. The IETF RRG has produced a draft with several requirements for a future architecture [8]. In such document, domain mobility, multi-homing, routing and new business relationships appear as strong requirements for the future Internet. In the path towards a next generation Internet architecture that deals with the above mentioned limitations and in line with current research tendencies, in this paper we introduce the concept of Domain Identifiers (DIDs) to effectively bring the domains to the next generation Internet, making the domain entity a first class citizen. We understand that by giving an identifier to every domain, novel opportunities are open for dealing with some very known problems such as domain mobility and multi-homing. Instead of keeping using the IP address as in NEMO, we go a step further towards the separation between locator and identifier by creating an identifier layer in which every entity (nodes and domains) has a unique, flat and cryptographic identification. The objective of this paper is to describe the functionalities that are needed to support domain identifiers and evaluate the impact and advantages of using DIDs in mobile scenarios. Examples of the natural benefits of having a DID in the architecture include 1) the aggregation of node identifiers into DIDs; 2) reduction of the signaling overhead; 3) the possibility of moving domains and 4) built-in support for multi-homing. We describe the necessary boxes and the control messages defined to implement the DIDs and to support domain mobility. The environment is constituted by autonomous and heterogeneous realms, flat identifiers for nodes and domains and private addressing inside the domains. The remainder of this paper is organized as follows: Section II describes the introduction of the DIDs, the architecture and the envisioned scenario. Section III describes the integration with the current Internet. Section IV details the support for node and domain mobility. Section V shows the results of node and domain mobility obtained with the developed prototype indicating that our proposal can easily interact with the current Internet. Also in Section V the quantitative results regarding handover time and packet loss during mobility events are shown. Section VI concludes the paper and discusses the next steps of our work.

II. P ROPOSED ARCHITECTURE Our proposal is to associate a DID to every single domain and deploy a mesh and flat network in which domains are seen as single nodes by the inter-domain routing mechanism, even if a domain has more than one border router. This means that the inter-domain routing is no longer more done using IP but the flat domain identity layer (DIDs). The needed components of the generic architecture are: DID Router, Registry and Name Service (NS). 1) DID Router (DR): It is responsible for routing functionalities such as the discovery of DIDs in inter-domain routing, advertisement of reachability in the intra-domain routing, forwarding packets using domain identifiers and performing packet translation between adjacent domains with different layer 3 technologies; 2) Registry: Each node attached to a domain has an entry in the local Registry to store its identifier (Node Identifier NID) and the respective layer 3 locator; 3) Name Service (NS): It is responsible for solving the node FQDN in a tuple . Below, the steps necessary to perform the node registration, node lookup and data exchange are described. Such steps are based on our previous work [9], [10]. 1) Node registration process: The node registration process is related to how nodes are registered in the Name Service and also how nodes are locally (in each domain) registered in the Registry. a) The node registration in the Name Service is done using its FQDN and its tuple. It is assumed that the FQDN of every node does not change. b) The process of registering a node in the domain’s Registry occurs when a node starts (turns on) in a given domain or when a node moves from a domain to another. After obtaining the local domain configuration, the node sends a Registry Update message (detailed in Sec. IV-A) to include its NID in the Registry associated to its tuple. 2) Node lookup process: The lookup process is performed in two phases. The first one solves the target FQDN into the tuple . This is done by the Name Service. The second step consists in resolving the NID into the Locator. This last resolution is done by the Registry inside each domain. 3) Data exchange: Data exchange basically encompasses the routing mechanism that is used to send packets from the sender node to the receiver node. The routing is done taking into account the DID until the packet reaches the destination domain and finally it uses the NID as lookup key in the Registry to deliver the traffic inside the domain. III. D EPLOYMENT OF THE A RCHITECTURE CONSIDERING THE I NTERNET Although our proposal is to have a mesh and flat topology without IP routing, initially in this paper we keep the Internet as the core network (like a transit domain) and the border routers of each domain attached to the core need only to use a mapping service to translate DIDs into IP addresses. Every node inside the domains must implement the new stack (by

means of a proxy or using a clean slate approach) to communicate using the identity layer and utilize the functionalities of the architecture. This is not different when compared to Node ID, HIP and others. Figure 1 describes the instantiation scenario of the architecture using the Internet as the core network. As can be observed, to implement this scenario it is necessary to introduce a Locator Service in the Internet and adopt the proposal to build the branches. This Locator Service is responsible for keeping track of DIDs and their associated Internet IP address to allow the traffic to cross the Internet. The Locator Service can be implemented using a DHT such as Chord [11].

Fig. 1.

Instantiation of the proposed architecture.

In this initial instantiation, static routes were adopted inside the branches. Such routes are generated from the registration process in which all domains register their DIDs in the Locator Service. Naturally, the data exchange is directly affected by this routing mechanism. These processes are described below. 1) Domain Registration Process: To become reachable, a domain must keep its information (about its location) updated in the Locator Service using a Locator Service Update message. This message has the following format: . The message must be periodically generated (soft-state) by DRs and forwarded towards the core (see Fig. 2 for an example). Each DR in the path stores the information received in these messages to build a static routing table to all domains below it in the branch. At the same time, each DR changes the information inside the message filling it with its own information (NID and locator) before forwarding the message upwards. When a core DR (DR-C in Fig. 2) receives this propagation, it inserts the DID in the Locator Service associated to its locator. 2) Data exchange: Basically, the data exchange encompasses three scenarios. The first one considers that both sender and receiver are in the same domain. The second scenario considers that the sender and receiver are in the same branch but located in different domains. The last scenario considers that the sender is located in one branch and the receiver is located in another one (communication across the core). a) The communication between nodes located in the same domain occurs by using the locator of each node that is discovered in the local Registry. So, the routing is done through the local layer 3 technology.

b) The communication between nodes located in different domains in the same branch occurs by routing the packets using the DID. After verifying that the target node is not located in the same domain, the source node sends the packets to the local DR which in turn routes the packets considering the destination DID field of the packet. Such DID-based routing is simply done by verifying the routing table that is constructed through the registration process done for each domain. If the destination DID is located below a given DR in the tree, the DR sends the packets downwards the destination domain, otherwise the DR sends the packets upwards using the static route towards the core until finding the DR whose DID is registered or reaching the core DR. c) In case that the target node is located in another branch (across the core), the packets reach the core DR using the static routing as explained above. Then, the destination DID is resolved into the locator of the core DR representing that DID. This resolution is done by the Locator Service in the core. The packets are then sent to that core DR and the DIDbased routing continues downwards in the destination branch until finding the destination domain.

mechanisms that are necessary to support the management of ongoing sessions as well as the management of new sessions in both scenarios. A. Node mobility support The architecture supports intra-domain as well as interdomain mobility of nodes. The insertion of a new identity layer, represented in this architecture by the NID, provides the initial requirement to perform node mobility without the interruption of ongoing communication sessions by preserving upper layers of the protocol stack untouchable. Therefore, after mobility events, mobile nodes must manage their new location to continue reachable not only by the communicating nodes but also by other nodes that will start new sessions with them. The architecture defines the usage of four signaling messages for the management of ongoing sessions. Fig. 3 represents the whole node mobility process for a mobile node that has ongoing communication sessions inside the domain in which it moved and also with nodes located in other domains. The four messages are as follows:

Fig. 3. Fig. 2.

Node mobility sequence diagram.

Exemplification of DID-A registration process.

The adoption of the architecture being proposed here can be done in phases. First, networks behind NAT boxes are good candidates to adhere to the approach as a manner of restoring the seminal end-to-end principle of the Internet. At the same time, nodes and domains interested in mobility support are also good candidates. Another benefit that would influence the network administrators is the avoidance of nodes renumbering offered by the new identity layer. Also, ASes present in the current Internet could gradually implement the DR functions in their equipments. This gradual adherence will help to stabilize the BGP tables overload as the Internet size (number of prefixes) will decrease. It is also important to emphasize that the node identifiers are generated from a pair of public/private keys and the gradual adherence to the proposal will help to solve several security attacks. IV. M OBILITY SUPPORT This section is divided into two parts. The first one discusses the aspects related to node mobility. Then, the second part presents the details related to domain mobility. We show the

1) Registry Update: This message is used in a registration process by which each node inside a domain updates its locator (e.g. IP) in the Registry entity. The update message includes the NID as the lookup key and the corresponding tuple . This process is repeated periodically with a configurable time-out (soft-state); 2) DID Update: This inter-domain message is sent by mobile nodes to the Registry entity located in their home domain1 to update their current DID. This message is important for the double-jump case in which both nodes change their DIDs; 3) Redirect: This message is sent to all the communicating nodes inside the same domain in which the node moved and its objective is to update the mobile node layer 3 address; 4) Relocate: This inter-domain message is used to update the DID of mobile nodes. It is sent from the mobile node to all communicating nodes located in other domains. These four messages gather all the functionalities that are necessary to support micro and macro mobility. The Relocate 1 The term “home domain” is used in this work to represent the domain in which a node is registered in the Name Service.

message is responsible for avoiding the traffic triangulation and, when compared to the MIPv6, the Relocate message implements MIPv6 second mode of operation that uses route optimization for sending packets without using the Home Agent [12]. The management of new communication sessions has relation to the dynamic offered by the global Name Service. As mentioned in Section II, nodes in this architecture are reachable by the tuple obtained from a query in the Name Service using the node’s FQDN. In this initial instantiation, we suggest the usage of the current DNS as the Name Service. However, DNS is not indicated for mobility management due to cache mechanisms that generates unmanageable convergence times. In this case, the solution is the usage of the DID Update message described before. Such solution imposes a triangulation scenario for the initial packets of new sessions. As a consequence, the DRs of the home domain will forward the first packets of new sessions to the current domain of the mobile node. When the mobile node receives the first forwarded packet it will send a Relocate message to the communicating node in order to update its DID avoiding the packets triangulation. B. Domain mobility support In the DID Architecture proposal, the entity responsible for keeping the mobile domains reachable is the routing system. Therefore, in this instantiation scenario considering the Internet, the branch structures attached to the core network and the static routes generated from the registration process are the key mechanisms that make domains reachable. Considering the organization of domains in a scenario like this, it is possible to have two types of domain mobility: 1) Domain mobility in a branch and 2) Domain mobility to a different branch. A domain mobility inside the same branch does not cause any change in the core level, i.e., the information in the core’s Locator Service will continue the same since the core DR that registered this domain is the same. Just the packets will need to travel deeper or shallower in the branch according to the new static route that will be generated in the branch. On the other hand, if a domain moves from one branch to another, the core DR of the branch where the domain is now attached will be responsible for updating the Locator Service with the new domain localization. This new entry in the Locator Service will have the locator of the core DR of the current branch. As a consequence, this process will update the DID in the Locator Service and any new query looking for that DID will result in the new locator of the core DR of the current branch. The domain registration process can be seen as the NEMO route optimization, an extension to NEMO basic support defined in the RFC 4889 [7] to avoid traffic triangulation as in the node case. In NEMO, binding update messages are sent by the mobile router to the correspondent entity which in turn establishes a bi-directional tunnel with the mobile router. In our case, the Locator Service Update message reaches the core DR of the current branch which in turn updates the new

location of the mobile domain. Unlike NEMO, no end-to-end messages between entities (domains) are necessary. V. N ODE AND DOMAIN MOBILITY EVALUATION The main objective of this section is to compare the mobility of nodes and domains using static routes and a Locator Service in the core (Internet) as described in Sec. IV. We present results related to handover time and packet loss. Since different topologies may affect the results, we preserved the same number of hops (domains and DRs) between the communicating nodes (NID 1 and NID 2) for both tests (node and domain mobility) as depicted in Figs. 4 and 5. Note that in the node mobility scenario (Fig. 4), NID 1 moves and needs to pass through three DRs not only before but also after the mobility event to communicate with NID 2. In the domain mobility scenario (Fig. 5), DID 1 is the mobile domain. It moves from the attachment point in DID 2 to the attachment point present in DID 3 while nodes NID 1 and NID 2 are communicating. In both moments, the nodes are also three DRs away from each other as in the node mobility scenario. In the node mobility scenario we used five IPv4 domains (DIDs 1, 2, 3, 4 and 5); in the domain mobility scenario we used four domains (DIDs 1, 2, 3 and 4) and in both cases an IPv4 core acting as Internet was utilized. All DRs and the communicating nodes (NIDs 1 and 2) were implemented using Intel Pentium 4 3.0 GHz with 1 GB of RAM and Gigabit Ethernet network cards. The only exception is the mobile node in Fig. 4 that is a 1.83 GHz Intel Core Duo processor, 1 GB of RAM and one 802.11g wireless interface. To perform domain mobility, one 802.11g wireless interface was installed in the DR of DID 1 (the mobile domain) in Fig. 5. There are also two 802.11g wireless access points. The Registry and the Locator Service were implemented as Rendezvous Servers (RVS) and the Name Service was instantiated using DNS. The RVS and DNS functionalities are running on QEMU virtual machines installed in the DRs. All nodes have Debian Sarge Linux and the kernel version is 2.6.23.1.

Fig. 4.

Node mobility evaluation scenario.

The average values for handover time and packet loss for all scenarios were extracted in fifteen rounds per scenario. The average handover time was calculated using TCPDump logs in which it was possible to verify the last packet received before the mobility event and the first packet received after

the mobility event. The packet loss was extracted from the log of the JTG traffic generator. We set the JTG to generate traffic at 20 Mbps/s during 60 seconds using packet’s PDU of 1300 bytes and the UDP protocol. Although tests with the TCP protocol were also done, in this paper the evaluation is focused on the handover time and packet loss numbers which are better accounted using UDP. Results with TCP are reported in [13].

4 seconds). Table I presents the average handover times. As expected, the domain mobility scenarios spend more time since they follow the time-outs that dictate when the new locator is renewed. The node mobility scenario presents a better result because of the on demand nature of the RELOCATE message. Looking at the standard deviation column it is also possible to verify that as the time-out increases the deviation also increases while the node mobility scenario is more stable. This occurs because the mobility event can occur at any moment of the soft-state temporization in domain mobility cases and it does not occur in the node mobility case. TABLE I AVERAGE H ANDOVER T IME FOR N ORMAL T RAFFIC S CENARIOS . Test Scenario

Fig. 5.

Domain mobility evaluation scenario.

The traffic direction changes the results and, as such, the terms Normal and Inverse were adopted to represent the direction. The Normal Traffic Direction indicates that the traffic source is the static node (NID 2) and the receiver node (NID 1) is the node that moves or is attached to the mobile domain. The Inverse Traffic Direction, as the name suggests, is the opposite of the first scenario, i.e., the traffic source (NID 1) is the node that moves or is attached to the mobile domain and the traffic destination is the static node (NID 2). We performed eight different tests, four in each direction. The average layer 2 association time is of ≈ 88 ms. All the numbers shown in the tables below have this time included in the overall time for each scenario. The results presented in Tabs. I and II are related to the handover and packet loss in scenarios with normal traffic direction. The node mobility scenario uses the RELOCATE message to resume the ongoing sessions. This message is generated after the mobility event (on demand) and sent to all communicating nodes. On the other hand, the domain mobility scenario depends on the inter-domain routing mechanism to converge. This instantiation scenario relies on the usage of a registration process (a soft-state mechanism) explained in Section IV-B. To understand the results it is necessary to clarify some characteristics of this instantiation. As soon as the mobile domain is reconfigured (after layer 2 configuration), it sends a Locator Update message to update its new locator in the Locator Service. However, such message is not enough to resume the ongoing sessions. It is also necessary that DRs attached to the core which have a mapping to the mobile domain (DID 1 in the tests) in the cache learn the new locator of the mobile domain (the locator of the core DR of the branch where it moved). This process is done by performing new queries in the Locator Service that follow the time-out of the registration process. To better illustrate such soft-state situation we decided to use three different time-outs (1, 2 and

Node Mobility - Relocate Domain Mobility - 1 second Domain Mobility - 2 seconds Domain Mobility - 4 seconds

Average Time (ms) 139,110 499,183 959,140 1746,508

Standard Deviation (ms) 15,693 260,367 510,780 1149,627

Table II presents the packet loss for the normal traffic direction scenarios which has a direct relationship with the handover time. The obtained results show the low number of packets that are lost even in the 4 seconds scenario of domain mobility. TABLE II AVERAGE PACKET L OSS FOR N ORMAL T RAFFIC S CENARIOS .

Test Scenario Node Mobility - Relocate Domain Mobility - 1 sec. Domain Mobility - 2 sec. Domain Mobility - 4 sec.

Average Sent Packets 113.127 112.994 113.135 113.131

Average Lost Packets 261 929 1.771 3.126

Lost Pkts. Standard Deviation 29 482 930 1.999

Tables III and IV show very interesting results related to the architectural behavior during traffic transmission in the inverse direction. As can be observed, all the results are similar and the handover time follows the layer 2 configuration time. This linearity occurs because in the inverse traffic direction the architecture does not depend on the soft-state time-outs in the domain mobility scenarios. The source of traffic is NID 1 and as soon as the mobile entity (NID 1 or DID 1) is reconfigured, NID 1 is able to deliver the traffic since NID 2 is still in the same local (DID 4). As in the previous tests, the packet loss is a function of the handover time. TABLE III AVERAGE H ANDOVER T IME FOR I NVERSE T RAFFIC S CENARIOS . Test Scenario Node Mobility - Relocate Domain Mobility - 1 second Domain Mobility - 2 seconds Domain Mobility - 4 seconds

Average Time (ms) 115,362 97,283 94,893 99,847

Standard Deviation (ms) 15,095 9,321 9,626 9,764

The results presented in the normal traffic direction tables

suggest that the node mobility scenario is more interesting than domain mobility because of the small handover time and packet loss. However, it is important to emphasize that the node mobility scenario needs to send signaling messages to resume all its open communication sessions with other nodes while in the domain mobility scenario it is only necessary to send a Locator Update message to refresh the location in the Locator Service. In the inverse traffic direction, both node and domain mobility events results are quite similar due to the fact that the destination DID has not changed and the mapping in the core network is up-to-date. This means that as soon as the moving domain re-configures, the data flow is sent without depending on any time-out for renewing the DID to locator mapping in the core router . TABLE IV AVERAGE PACKET L OSS FOR I NVERSE T RAFFIC S CENARIOS .

Test Scenario Node Mobility - Relocate Domain Mobility - 1 sec. Domain Mobility - 2 sec. Domain Mobility - 4 sec.

Average Sent Packets 112.793 113.100 113.028 113.104

Average Lost Packets 216 182 178 188

Lost Pkts. Standard Deviation 28 18 18 18

VI. C ONCLUSION AND F UTURE W ORK This paper presented a proposal of a Next Generation Internet Architecture that is based on the usage of Domain Identifiers (DIDs). Its main objective is to turn domains first class citizens and make them part of the Internet scenario. We discussed the mechanisms necessary to introduce DIDs and evaluated the advantages of such approach by comparing node and domain mobility scenarios. Also, we demonstrated that it is feasible to instantiate the proposal using the current Internet as it is today through the usage of a static routing mechanism inside branches and a Locator Service (a DHT) to keep track of the DIDs. The DID architecture has several benefits such as: the possibility of moving entire domains, the natural support for multi-homing, the restoration of the seminal end-to-end principle broken by NAT, the avoidance of nodes renumbering offered by the new identity layer and the stabilization of the BGP tables since it is not necessary to have valid IP addresses inside ASes. The adoption of the architecture also helps to prevent several security attacks by employing cryptographic identifiers. It also simplifies the network composition [13] since domains are entities identified by DIDs. We also presented the soft-state paradigm used in the domain mobility, the benefits that the RELOCATE message brings to the node mobility scenario and the relation that the traffic direction has with the soft-state. The signaling overhead of node mobility as opposed to the domain mobility scenario was also analyzed. We consider that if a dynamic Name Service is used, all the signaling overhead of node mobility can be reduced since the Name Service is capable of managing nodes location. Preliminary brainstorms

done in our group points that such a Name Service could be developed using a business model in which nodes are intended to contract services from specialized companies that are responsible for the management of nodes location. Another possibility is that under this business model it is possible for nodes interested in constant mobility to pay to receive a DID and, as a consequence, they would appear in the inter-domain routing mechanism. Although some quantitative results were shown (packet loss and handover time), the most important result of this paper is the introduction of the architecture that effectively allows domains to move. The adoption of DIDs is also a starting point for other open issues related to routing and flat addressing. In this sense, a next step of our work is the development of a flat inter-domain routing mechanism that is capable of scaling under the architecture proposal. We consider that it is possible to develop a scalable inter-domain routing mechanism using concepts of UIP [14] and compact routing, and classifying domains as Static and Ephemeral to control the signaling overhead during the neighborhood discovery. Acknowledgements We would like to thank Ericsson Brazil, CAPES, CNPq and FAPESP for supporting this work. We also would like to thank Annikki Welin for her technical contributions. R EFERENCES [1] D. Farinacci, V. Fuller, D. Oran, and D. Meyer, “Locator/ID Separation Protocol (LISP),” IETF Draft - draft-farinacci-lisp-05.txt, Nov., 14 2007. [2] E. S. Schuetz, R. Winter, L. Burness, P. Eardley, and B. Ahlgren, “Node Identity Internetworking Architecture,” IETF Draft - draft-schuetz-nidarch-00, September, 14 2007. [3] R. Moskowitz and P. Nikander, “Host Identity Protocol (HIP) Architecture,” IETF RFC-4423, May 2006. [4] M. Caesar, K. Lakshminarayanan, T. Condie, I. Stoica, J. Kannan, and S. Shenker, “ROFL: Routing on Flat Labels,” In Proceedings of the ACM SIGCOMM, Pisa, Italy, September 11-15, 2006, pp. 363 – 374. [5] S. Schmid, L. Eggert, M. Brunner, and J. Quittek, “TurfNet: An Architecture for Dinamically Composable Networks,” Workshop on Autonomic Communication (WAC), Berlin, Germany, October 18-19, 2004, vol. LNCS 3457, pp. 94 – 114. [6] Information available at: http://www.ambient-networks.org/, 2007. [7] C. Ng, F. Zhao, M. Watari, and P. Thubert, “Network Mobility Route Optimization Solution Space Analysis,” IETF RFC-4889, July 2007. [8] A. Doria, E. Davies, and F. Kastenholz, “A Set of Possible Requirements for a Future Routing Architecture,” IETF Draft - draft-irtf-routing-reqs10.txt, June 2008. [9] W. Wong, F. L. Verdi, and M. Magalh˜aes, “A next generation internet architecture for mobility and multi-homing support,” ACM CoNext Student Workshop. New York, NY, December 2007. [10] W. Wong, R. Villac¸a, L. B. Paula, R. Pasquini, F. L. Verdi, and M. Magalh˜aes, “An Architecture for Mobility Support in a Next Generation Internet,” The 22nd IEEE International Conference on Advanced Information, Networking and Applications (AINA 2008), March 2008. [11] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, “Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications,” ACM SIGCOMM 2001 - San Diego, CA, EUA, August, 2001. [12] D. Johnson, C. Perkins, and J. Arkko, “Mobility Support in IPv6,” IETF RFC-3775, June 2004. [13] L. B. Paula, R. Villac¸a, A. Welin, F. L. Verdi, and M. Magalh˜aes, “A Web Service-based Network Composition Architecture for the Next Generation Internet,” The 5th International Workshop on Next Generation Networking Middleware (NGNM 2008), September 2008. [14] B. Ford, “Scalable internet routing on topology-independent node identities,” MIT technical report conducted as part of the IRIS project (http://project-iris.net), October 2003.