RANGI: Evolving Internet Routing Architecture from Present to the Next

RANGI: Evolving Internet Routing Architecture from Present to the Next Generation Subharthi Paul, Jianli Pan, Raj Jain Washington University in Saint Louis Saint Louis, MO 63130 USA {pauls,jp10,jain}@cse.wustl.edu ABSTRACT We propose a clean slate design for the next generation Internet architecture that allows natural sharing of resources among multiple organizations. Our architecture consists of a 3-tier object model. The bottom tier consists of the network infrastructure owned by multiple Internet service providers. The second tier consists of hosts that may be owned by different organizations. The third tier consists of users and data objects. This results in a three tiered virtualization model as compared to the traditional single-tier infrastructure virtualization. In today’s Internet the infrastructure, the hosts, and users belong to different organizations (as in cloud computing) but are not correctly represented in the architecture resulting in several issues. We, therefore, propose an incremental architecture strategy that helps solve the problems of scalability, mobility, multihoming and traffic engineering in the current Internet, and allows evolving towards realizing the clean slate architectural goals. Keywords Next Generation Internet, Architecture, Multi-tier Virtualization, Data centric, Host centric, User centric, Routing, Multi-homing, Mobility, Scalability, Traffic Engineering 1. Introduction The operating environment of the Internet has changed substantially since its original design. The original assumptions of trust-all environment around stationary, low capability end hosts is no longer valid. Also the simplicity and elegance of the end-to-end argument has long since been marred by introduction of middle-boxes in the data path to provide value added services, distribute end-system responsibilities or enforce coarse grained policies. These middle-boxes, though seen by most “purists” as illegal encroachments to original design principles, are inevitable in the context of today’s networking environment. However, being illegal citizen, these middle-boxes are highly limited in their effectiveness of the services that they provide. Nonetheless, the end-to-end argument though restrictive to innovations is still essential for the scalability, correctness and efficiency of network operations. We realize that the future Internet design has to make

Xiaohu Xu Huawei Technologies Beijing, China [email protected] provisions for the existence of these middle-boxes as part of the architecture while maintaining the principles of the end-to-end argument [18] at the same time. Another aspect of the original Internet design is that it is primarily host centric. The end-hosts are represented by IP addresses and the network infrastructure works towards routing packets correctly to specified hosts. We, however, argue that the original design can be said to be more “location centric” rather than “host-centric” since the network actually does not identify the host but identifies and routes packets to the network “point of presence” denoted by the IP address. As is well known now, the IP address is semantically overloaded with the role of a “locator” as well as an “identifier”. This dual role of IP address was reasonable when the hosts were immobile. The network of today needs to be host centric, wherein the host is identified as an independent entity in the network framework separate from its point-of-presence. Also, there have been proposals of a data-centric network [26]. The philosophy behind the data centric network proposal is that it does not really matter “where” the data comes from as long as it maintains its integrity and correctness properties. Thus, a data-centric network realizes data as an integral part of the architecture. We propose that the network architecture should also incorporate a “user-centric” view where users can be explicitly identified and addressed within the network framework. The host, user and data centric views of the network architecture form the basis of our three-tier object model and the multi-tier virtualization framework that shall be discussed in more detail in Section 2, where we address the specific case of conflated identities. While designing for the future and addressing long-term concerns, we propose to move towards it incrementally by solving the present problems. RANGI – a Routing Architecture for the Next Generation Internet, is an effort in this direction to solve the immediate problems of scalability, multi-homing and mobility. The problem of scalability in the global routing infrastructure is a direct off-shoot of more and more stub-sites willing to participate in the global routing system by obtaining ProviderIndependent (PI) addresses and, thus, causing deaggregation of the routing space. While PI addresses are

highly desired by stub-sites, they are extremely costly in terms of the global routing state. Using PI addresses, stubsites can easily multi-home with two or more providers and, hence, be less dependant on single providers and also do traffic engineering for congestion control, cost etc. Such flexibility as gained by multi-homing is not possible, in the present networking context, if the stub-site receives its address from the aggregated address space of a provider. Mobility is a separate problem and, as already discussed, is more due to conflated identities (confusing locator with host id). Solutions to mobility, such as Mobile IP [2], though exist, have not seen wide-scale deployment due to obvious weaknesses arising from enforcing indirection mechanisms in the data path. We shall discuss more about these when we discuss RANGI in Section 3 and Section 4. Thus, this paper proposes a combination of futuristic ideas that allow for a highly flexible network architecture for the next generation Internet followed by an incremental approach towards achieving those goals. As such, in this work, we present: Clean slate design: The architectural design proposed in this paper is clean slate (in the spirit of the NSF GENI/FIND [10,12] programs), meaning that the design is not restricted by the considerations of the existing legacy systems and the magnitude of the effort required to change or modify it. Such design paradigms allow for looking at long term solutions to problems rather than being restricted by a myopic view of immediate solutions. As part of this approach, we propose the ideas of realms, user-, data-, and host- centric models, the tiered object model and the multitiered virtualization of the future Internet design. Incremental Implementation: The design though being clean slate, the implementation has to be incremental to preserve the current investment and incrementally build upon it to reach the future. This is the harder part of the problem and we discuss our approach towards it through the discussion on RANGI (Sections 3, 4), which defines a routing architecture for the next generation Internet. RANGI addresses the concerns and problems being discussed at the Routing Research Group (RRG) of the Internet Research Task Force (IRTF). The rest of the paper is organized as follows. In Section 2, we discuss our clean slate design for the next generation Internet architecture – the design requirements, design choices and an integrative model, followed by a theoretical discussion of RANGI which forms our incremental implementation plan in Section 3. In Section 4, we discuss the operational details of RANGI followed by a study of how RANGI compares to other solutions attempting to solve similar problems in Section 5. Finally, we conclude the paper with a summary of the key contributions of the present work. 2. Clean Slate Design of a Next Generation Internet Architecture: Key Concepts

Our view of the future Internet is that of diversification. The Internet, if it would have been designed today, would not only have to support all the present requirements but would have to leave enough flexibility to accommodate inconceivable future innovations. Also, the design should be such that present assumptions should not ossify future requirements. Our insight on the weakness of the original Internet design points towards conflated identities as the fundamental reason that has led us to the present impasse. In this section we discuss some of the ideas that form the basis of our multi-tier virtualization model for the next generation Internet. 2.1 Definitions of Realms [23]:“Realms” represent an administrative domain. The current Internet already has the idea of independent administrative domains in its routing infrastructure, generally called “Autonomous Systems (AS)”. For the sake of consistency we call autonomous systems as “Infrastructure Realms” in our architecture. These infrastructure realms are the only independent administrative domains represented in the present design and are bound by a physical spatial perimeter. Infrastructure realms are allowed to enforce their own policies within the realm and undergo policy negotiations with adjacent neighboring realms. Unfortunately, organizations are represented in the same way. Organizational policies are enforced at infrastructure realm boundaries. This is a huge anomaly in itself. Organizations are generally logical administrative domains and it is not correct to model them with a physical perimeter. As shown in Figure 1.a, Organization A and Organization B are spread across different Infrastructure Realms. In a more generalized scenario the two infrastructure realms across which an organization is spread across may not physically peer with each other at all. However, as shown in Figure 1.b, Organization A and Organization B can be logically represented as contiguous logical realms and though they may not be physically connected, they may still peer with each other at some peering point.

Figure 1.a Realms

Figure 1.b Realm Peering We generalize the concept of realms to incorporate logical administrative domains that truly represent administrative boundaries. Also, organizational policies necessarily need to be enforced at these organizational boundaries rather than physical infrastructure boundaries. The “Three-Tier Object Model” [Discussed in Section 2.3] shall refine this

generic idea of realms to define realms in terms of real network objects rather than their aggregations represented as organizations.

that defines the intrinsic relationship between the entities and a framework for management and control of each individual entity.

2.2 Location-, Host-, User-, Data – Centric Model: The original Internet design suffers from the problem of conflated identities, that is, the IP address is semantically overloaded to represent both the locator and the identifier. The necessity for locator/identifier split was first proposed by [15] and since then has been extensively studied [16, 17,20, 21 etc]. Locator/Identifier split solutions establish a separation of host identity from its current point-ofpresence on the routing infrastructure. Increasing the levels of granularity in any architectural design increases flexibility and control albeit at the cost of added overheads. We believe that the conflated design of the Internet in its original form was by design, to reduce complexity at the cost of reduced flexibility and control. The design which was perfectly valid within the precincts of the networking environment at the time of the original design poses to be a serious limitation in the present scenario. The location-, host-, user-, data- centric model advocates the de-conflation of identities of network entities for enhanced control, management and flexibility in the architecture. As such, such de-conflations do exist in separate individual networking solutions such peer-to-peer systems, overlay networks etc., but they are not part of the basic architecture and, hence, limited in their effectiveness. Also, such deconflation of identities enable policy enforcements at higher granularity levels and, hence, contribute towards better security and organizational policy enforcements.

2.3 The Three Tier Object Model: The three-tier object model sketches a simple relationship model of the generic network entities identified in Section 2.2 and overlays it with a control framework of administrative control or realms as identified in Section 2.1.

The location and host- centric models, as already discussed, treats the point-of-presence in the routing infrastructure as separate from the identity of the host. Such a separation shall have tremendous impact on efficient mobility, multihoming and traffic engineering solutions. Also, independent locators shall benefit the scalability of the routing infrastructure by achieving higher degrees of route aggregations. A detailed discussion on these issues shall be discussed when we discuss RANGI in Section 3. Apart from these, such a separation helps realize the future designs of host based virtualization as discussed in Section 2.4. The idea of a data centric model is based on the ideas presented in [26]. The rationale behind data centric model is that it does not really matter where the data comes from as long as it is identical, valid, correct and secure. The data centric model realizes data as an independent entity in the architecture. We believe users are an important entity in any communication and deserve to be represented in the architecture. This leads to a user-centric architecture. The data and user centric architectures remove the conflated identities of users and data from the location of their hosts and, thus, allow for higher degree of flexibility. Based on the ideas of realms and generic network entities of location, host, data and users, we go on to propose a three-tiered object model in the next section [Section 2.3]

As shown in Figure 2, users and data are the actual endpoints of a data communication process. However users and data themselves are dependant on electronic hosts to communicate with each other. These hosts, in turn depend on the underlying routing infrastructure to be able to communicate with each other. These intrinsic dependences give a tiered-structure to the object model.

Figure 2. Three-Tier Object model Another aspect of the tiered object model is the overlaid control structure for the management and control of each independent network entity. Each object is part of a logical administrative domain called realm (defined in Section 2.1) and realm managers are objects that are responsible for the management and control of objects within their realm. The issues in the operational design of these realm managers is discussed briefly in Section 3 and Section 4 on RANGI. The realm managers are to some extent similar to middleboxes in the present architectures, but with two major differences. 1. Unlike middle-boxes in the present architecture, realm managers are a legitimate and intrinsic part of the architecture. 2. Realm managers generally involve in management and control activities and do not lie in the actual data communication path. They, thus, avoid introducing overheads and inefficiencies as a result of per-packet processing and path triangulation. The communications between the realm managers and the generic network entities (location, host, user, data) and those between two realm managers implement the control and management protocols for implementing value added services, for policy enforcements and to proxy end system responsibilities. The tiered object model, thus, establishes the intrinsic dependences between the generic network objects, overlays a control framework over them, and also establishes a nonconflated structure to be used as the basis for the next generation Internet design.

2.4 Multi-Tier Virtualization: The discussions in Sections 2.1, 2.2 and 2.3 build up towards our idea of multi-tier virtualization. It directly entails from our definition of realms in Section 2.1 that all entities/objects belonging to a particular realm are under the same logical administrative boundary. Thus, each realm forms a virtual network where the logically related objects of the realm are connected by virtual links, which may span multiple physical links. A host may belong to multiple realms and, thus, participate in multiple virtual networks of hosts with each network characterized by its own policies and services. Similarly, user or data realms may represent virtual “network” (community) of data and users spread over virtual network of hosts. Ownership isolation on shared resources of the network entities as identified in the three-tier object model lay the foundations for such futuristic paradigms as “cloud computing”. As shown in Figure 3, a virtual network of host may span multiple infrastructure realms and similarly a virtual network of data/user may span multiple host realms. Also, such multi-tier virtualization allows the entities of each tier to move over the tier below them, for example, hosts may move across infrastructures, a user may move over different hosts at different points of time and data may be replicated over multiple hosts and delivered from the best replicated copy from one host or from multiple hosts.

Figure 3. Three-Tier Realm Virtualization A rudimentary idea of virtual network of hosts or user/data seems very similar to the ideas of an overlay network of hosts, P2P networks, Cloud computing, or private networks. However there are some fundamental differences that we shall examine in the following arguments. 2.4.1 Control and Data Paths: The virtual networks, as defined within the scope of our paper do not try to extend a physical network virtually as in the case of Virtual Private Networks(VPN) [1], but are rather based on the concept of de-conflation of identities, as already discussed. Hence, the realm managers implement a control plane for the formation and maintenance of the virtual networks but do not interfere in the data path. This separation of control and data paths is central to our idea of virtual networks and differentiates it from VPN-like solutions. 2.4.2 Globally Addressable Virtual Networks: Each entity in the object model is named relative to their realms. Each realm has a globally unique identity. The virtual networks formed as a result of realm virtualization, thus, have a global identity and, hence, enable vertical inter-

realm negotiations (as shown in Figure 4) between the host realm and infrastructure realm and between user/data realms and the host realms. Such negotiations allow these globally addressable virtual networks to negotiate for enhanced services. Thus, the multi-tiered virtualization concept allows each tier to recursively compose richer and more diversified set of core services to the tier above it. We shall discuss more about it in the next sub-section (Section 2.4.3). These globally addressable virtual networks are, thus, very different from IP-in-IP overlay networks or private identifier based P2P networks in the sense that these private networks are neither addressable nor can they negotiate for enhanced services outside their own private domain.

Figure 4. Multi-Tier Virtualization and Virtual Networks 2.4.3 The end-to-end argument: Looking at the future through the eyes of the past Our realization of the “object reference model” and the “multi-tier virtualization concepts” in the present context and in the context of the design of the future Internet forces us to re-consider the end-to-end argument [18]. The object reference model (Section 2.1) conveys an implicit structure of various key entities that participate in a modern communication process. The virtual network architecture concept is an extension of this realization. We argue that while the end-to-end argument is still valid in the context of the three –tier- object reference model, the end-points can be generalized to hosts, data and users as opposed to the original ideas of hosts synonymous with addresses or locations. We present a recursive explanation to our renewed understanding of the end-to-end argument as valid in the future Internet design context. Considering the end-points to be hosts with their own host identifiers in the context of the virtual network of hosts, the middleboxes managing the virtual network and all the policy enforcement points of the path are reduced to what were routers in the previous design. Except for the fact that these middleboxes now get a legitimate position in the core architecture rather than being outsiders forcing their way in and the activities such as policy enforcements being part of the core network (albeit virtual network) similar to what routing was in the original design, the end to end argument still holds true allowing the host end points to ensure endto-end reliability, security etc. Also, the best effort delivery service to a particular network location identified by the IP in the current design can be generalized to mean

best effort delivery service by the “virtual network” to a particular host identified by the host ID. A more interesting picture comes through on considering the generic end-points to be data and users. As mentioned in our discussion on the object reference model (Section 2.1), data and users have an implicit dependence on hosts (henceforth referred to as “facilitating host”) in that they need hosts to communicate through the electronic communication medium. With end-points being data and users, the facilitating hosts are part of the core network, again like routers in the current design, and the services that the virtual network of data and users now expect from the core network is the summation of services provided by the infrastructure layer and the host layer including reliable and secure delivery till the facilitating host and all middlebox services and policy enforcements in the virtual network of data and hosts. The generic end-points of data and users can abide by the end-to-end principle by ensuring end-to-end reliable delivery, security etc, albeit now these end-to-end services have to be redefined in the context of these end-points . The beauty of the argument presented in this section lies in the magical power of the recursive definition. Almost with the beauty and elegance of a recursive mathematical equation, we are able to define a high performance core without actually breaking the end-to-end argument at any point. Figure 5, presents a formal description of the recursive formation of virtual networks at different tiers.

Let us consider a typical collaboration scenario which involves a group of scientists from different universities and national laboratories involved in a collaborative scientific effort. They do offline analysis using data generated by specific scientific laboratory equipments and stored in servers in distributed locations. The analysis of these voluminous amounts of data requires huge computational resources and, hence, the data needs to be processed at multiple super-computer locations in a distributed manner. So, scientists belonging to different user realms are collaborating with data belonging to multiple data realms. The data is stored on hosts which do not necessarily belong to the realm that owns the data. The supercomputers processing the data too may not belong to either the user realms or the data realms. In a way, this is an example of one of the most generic scenarios that should be easily realized by the proposed architecture. Following a top down approach, let us say that the experiment registers a user/data virtual network (lets call it the seed-network), as shown in Figure 6, into which all users belonging to different user realms need to join-in through inter-realm negotiations with the seed-network. So, such negotiations allow a host, affiliated to its own host realm to join a virtual network and is given an ID relative to the virtual network ID and the host operates as a part of the virtual network. As part of the negotiations, the host resources available to the virtual network, access controls, security controls and other policy issues may be resolved. This achieves the operational isolation that is an integral part of any virtualization technology. The next step is to setup the host realm that consists of hosts over which the users and data reside. It is to be noted here that these hosts may be supercomputers which have user accounts and data-centers where huge amount of data from multiple data-realms are stored. The user/data virtual network formation spawns the formation of the virtual network of hosts on which the users and data exist. The virtual network of host formation, thus, requires a similar seed-network that grows as it negotiates with multiple host realms involved in the experiment.

Figure 5. Formal Description of Recursive Virtual Network Formation 2.4.4 An Example Scenario: The ideas presented so far may seem to be abstract and, hence, we instantiate an example scenario to give them a more concrete basis. The scenario has been modeled around the requirements of future peta-scale science networks [9] and we aim to show how such futuristic networks may be served by our ideas of multi-tier virtualization.

The formation of the host realm is followed by its negotiation with the infrastructure realms. The hosts known by their host IDs in the host virtual network are served by one or more infrastructure realms. These infrastructure realms typically provide connectivity between the hosts participating in the host-virtual network. The negotiations between the host virtual network and the infrastructure realms serving them are used to direct the infrastructure realms to provide a rich set of services. As shown in Figure 7, the virtual network of hosts may negotiate for required services with the infrastructure realm servers. The infrastructure realm servers need to communicate such negotiations to the routers in the datapath to ensure compliance with the agreed upon service.

COPS [3] is a protocol designed to allow routers to communicate with the policy servers in the same locator domain. An enhancement of COPS is needed to allow infrastructure realm servers to be able to communicate with the routers in the data path. The biggest hurdle towards realizing the dreams of such a futuristic network is “conflated identities”. Negotiations and policy enforcements at much more granular levels is required than is offered by the present design. In, the next section, we describe RANGI - Routing Architecture for the

engineering, renumbering and incremental deployability. Some of these problems are correlated with each other. For example, there is a kind of circular dependency between routing scalability and site-multi-homing in the sense that the problem of routing scalability has emerged because stub sites (sites that do not provide transit services to other networks) want to multi-home to reduce their dependency on a single service providers and to be able to do traffic engineering based on parameters of network conditions and economic viability. To do so easily and more naturally, these sites try to obtain provider independent (PI) prefixes. Every PI prefix participates in the global routing system and, hence, adds a separate entry in global routing tables. Thus, this need to multi-home and traffic engineer at the stub-sites aggravates de-aggregation of the IP address space leading to the scalability problem. Mobility is a separate problem, which is a direct offshoot of the conflation of identities of a host and its location. Upper layer protocol sessions are bound to source and destination IP addresses. Host address changes as a result of physical mobility of the host cause these sessions to be invalidated.

Figure 6. Multi-tier Virtual Network Formation Next Generation Internet, which as an attempt to remove the strong coupling between a host and the infrastructure and at the same time solve the immediately relevant solution of mobility and multi-homing.

Also, site traffic engineering in the current Internet is often fulfilled by injecting more-specific IP address prefixes into the global routing table, which leads to the de-aggregation of the address prefixes and further aggravates the routing scalability issue. In summary, RANGI’s goals are to solve these problems together through a locator/id split type solution that allows incremental IPv4/IPv6 transition and one that moves forward towards the realization of the clean-slate long term design model discussed in Section 2. To realize these design goals, we need to combine the long-term design consideration with short-term implementation requirements.

Figure 7. Virtual Network of Hosts 3. RANGI: Routing Generation Internet

Architecture

for

the Next

In Section 2, we discussed our clean-slate design of a new architecture for the next generation Internet. However, the Internet is no experimental test bed and it is obvious that such far fetched ideas are not immediately implementable over the current Internet. RANGI is an attempt to define an incremental approach towards realizing the ideas generated in the last section by solving immediately relevant problems, but in the direction etched by our clean slate design. 3.1 RANGI Goals: The Internet community represented mostly by the IRTF and the IETF (Internet Engineering Task Force) are currently trying to address the problems of routing scalability, mobility, multi-homing, traffic

3.2 RANGI: An Incremental Approach to Clean-Slate Design: The design of RANGI is constrained by incremental deployment and backward compatibility constraints of the present Internet. Referring back to our “Three-Tier Object Model” in Section 2.3 and to Figure 2, we compare that to Figure 8, which explains the exact positioning of our incremental approach (RANGI) relative to our long-term clean-slate design goals. RANGI implements the host realm and infrastructure realm paradigm of the three-tier object reference model [Section 2.3]. Unlike, the current Internet design the ownership of hosts and the infrastructure access points may belong to separate organizations and must not be conflated. This separation of ownership is represented (in Figure 8) by the host and infrastructure realm managers. It should be noted that in special cases, such as in enterprise networks, the

host and the infrastructure access points may belong to the

Figure 8. Scope of RANGI in the Three-Tier Object Model same enterprise. However, this special case of common ownership has no bearing on the logical, structural and functional differences between the host realms and the infrastructure realms. 3.3 RANGI Conceptual Overview: RANGI may be broadly classified as a hybrid locator/identifier split and tunneling solution for solving the problems of routing scalability, stub-site multi-homing with traffic engineering, and host mobility. RANGI introduces a layer called the “RANGI Host ID layer” (RIL) between the Layer 3 and Layer 4 of the OSI protocol stack. This layer is responsible for ID management, ID-locator mapping, re-mapping functions etc. Though belonging to the genre of locator/id split solutions, RANGI differs significantly from other similar solutions, as shall become more evident as we get into more details in the rest of this paper. As for now, we put forth a broad overview of the design elements on which RANGI is based. 3.3.1. RANGI Definitions: Identifiers, Locators and Realm Managers: In the ID/Locator split paradigm, it is a general tendency to refer to an “identifier” as “host id” and “locator” as “host address”. However, the abstract concept of a “name” mandatorily requires it to be specified relative to a context. While the definition of a “locator” does carry an implicit context, the definition of “identifier” is incomplete without explicitly binding it to the context. “Identifier” in RANGI refers to the “host id” in the context of the host realm while “locators” in RANGI refer to the “infrastructure id” in the context of the infrastructure realm. These definitions can be recursively applied to form larger contexts. For example, a realm has an ID in the context of a larger realm consisting of multiple smaller realms. This recursive definition is the basis of the hierarchical ordering of realms. It should however be carefully noted that the context also dictates the design of the hierarchy (host realm hierarchy is different from a infrastructure realm hierarchy). Also, without loss of generality, for the sake of more direct reference to generally established terminology in order to avoid confusions, we shall henceforth use the term “locator domain” interchangeably to refer to the “infrastructure realm”. “Realm manager” in RANGI is a logical aggregation of functions required to manage the objects within a specific realm. In general these logical functions provide specific services to the objects within the realm and also enforce organizational policies on each object of the realm. We

shall discuss some of these functions in the context of the RANGI design. 3.3.2 RANGI ID Layer (RIL): All host based services connect using host IDs. Hence, for performing these services, RANGI introduces a new RANGI ID Layer (RIL) between the transport layer and the network layer of the current host protocol stack. Thus, the introduction of RIL serves two primary purposes: 1.

It implements the end-host responsibilities of the distributed host realm functions.

2.

It de-couples the concerns of a logical end-to-end connectivity over host realms from the concerns of physical end-to-end connectivity over locator domains.

The separation of logical connectivity/physical connectivity concerns has huge implications on the flexibility and functionality of the Internet. In the context of RANGI, logical connections over immutable host IDs are shielded from locator changes as a result of host mobility over multiple locator domains or due to specific types of multihoming solutions. Also, a logical link can accrue attributes of security, trust and reliability through inter-realm negotiations during connection-setup. 3.3.3 Infrastructure Realms or Locator Domains: The locator domain is primarily responsible for the distributed “routing function”. For this, the locator domains distribute reachability data amongst themselves and compute forwarding tables. The locator domain objects include locator domain border routers, locator domain core routers.. Similar to the host realm manager functionality, the locator domain realm functions are distributed across these objects. At the host-side, the network layer of the host protocol stack is responsible for the responsibilities specific to the locator domain. The concept of locator domains and the associated routing functions is synonymous to autonomous systems and the IPv4 based routing systems already existent in the current Internet. However, they need to be re-defined in the context of RANGI. Unlike the legacy IPv4 routing system, “locators” assigned to RANGI hosts in the context of locator domains no longer need to be contextually overloaded to serve as 1) session identifier for TCP sessions, 2) host identifiers for host based policy enforcements and 3) locators in the global routing tables, all at the same time. As a result, the locators in the context of locator domains attribute to more scalable, dynamic and efficient routing function. However, unlike the concept of the host realms,, deployments of new locator domains are faced with the problem of interoperability with legacy systems (mostly the IPv4 routing system). RANGI tries to mitigate these problems through an incremental deployment plan that involves adding RANGI locator domain capabilities to the locator domain objects incrementally.

3.3.4 RANGI Host ID: The term “host ID” has already been introduced and defined in Section [2.2] and [2.3].The discussion in this section is specific to the structure and scope the RANGI Host ID. RANGI host IDs (Figure 9)are 128 bit binary strings. The choice of its size is, by design, made to resemble IPv6 addresses for the purposes of injecting minimal changes to application layer and transport layer interfaces. Most implementations of transport layer protocols and most modern day applications are already IPv6 aware. The choice of 128 bit host IDs reduce the burden of re-defining many of the upper layer protocol interfaces. Other than its size, the RANGI host ID does not resemble IPv6 addresses in any way. RANGI host IDs need to be globally unique. As discussed in Section 2.1, the scope and purpose of host IDs is to enumerate logical organizational structure. Also, as shall be discussed later in this draft, one of the services of the host realm managers is to maintain dynamic host ID to locator mapping information. Distributing this mapping information and providing efficient lookup requires realm managers to form an efficient overlay network. The hierarchical ID structure should aid the formation of such efficient overlay networks. Apart, from these, the host ID establishes the identity of a host in the context of its host realm. This identity may be used for the purpose of authentication and authorization of the host. This adds the requirement on host IDs to be secure. The RANGI Host ID design has been made keeping in mind all the above requirements. The 128 bit binary string is overlayed with ‘n’ bit Administrative Domain ID (ADID) and ‘128-n’ bit local host ID. As of this writing, it remains to be decided whether ‘n’ shall be fixed to a constant number or whether RANGI shall use ideas from CIDR

Figure 9. RANGI ID prefixes and variable length masking and allow ‘n’ to vary across a range. The ADID aids the representation of the organizational ownership of the host realm and the local host ID part is a flat ‘n’ bit cryptographic hash of the administrative domain ID to fulfill the requirements of a secure ID. The ADID may be further be partitioned into a hierarchical geographical and organizational structure such that it helps in the formation of an efficient overlay. The global uniqueness of the RANGI ID should be guaranteed through some registration mechanism. Since the AD ID is globally unique and controlled by the ID registration and administrative authorities from different countries, the second part of the RANGI ID, the hash value just needs to be unique within the AD scope. The purpose of the hierarchical host ID in RANGI is to ease the

management of the global ID namespace and hold the economic and trust model in the ID/locator mapping system. Actually, the flat part is easy to process by machines but hard to remember for people, so it is used to perform the end-to-end security which may have critical speed or performance requirement; the hierarchical part, however, is easy to understand for human beings and easy to organize and manage by using a tree-like realm structure. In short, we gain several advantages through this concatenation structure of RANGI ID. 3.3.5 The RANGI “Locator”: RANGI has 128 bit locators. As seen in Figure 10, the first part of 96 bits LD ID can be used to globally uniquely identify each LD and it serves as a /96 IPv6 prefix. The LD ID has a hierarchical structure for topological aggregation and routing flexibility. The second part of 32 bits LL is an IPv4 address and each LD adopts independent local IPv4 address space. This IPv4-inIPv6 address feature makes the IPv4 address only has local meaning. The LL is not globally unique, however, LDID plus LL is globally unique and is, therefore, also called GL (Global Locator). This locator design helps ease the renumbering process. Moreover, the first part of LD ID is used to perform the global routing and the second part is used to accomplish local routing in a specific LD.

Figure 10. RANGI Locator 3.3.6 Provider Independent (PI) Locators and Provider Assigned (PA) locators: Synonymous to PI and PA addresses, RANGI too has the concept of PI and PA locators. The 96 bit LD ID of RANGI locators is used as a prefix in RANGI routing similar to the prefix based routing of IPv4 and IPv6. Providers may be assigned multiple /96 locator blocks to be reassigned in smaller chunks to subscribers. The PA locator concept of RANGI bears an uncanny resemblance to “supernetting” in CIDR based IPv4 addressing. One of the key features of RANGI is that it tries to eliminate the concept of PI locator assignments. RANGI tries to package all the benefits of PI locators using PA locators. Also, with an added layer of indirection of immutable host IDs, PI locator assignments may be considerably reduced in RANGI, thereby, considerably reducing the scalability problems of the current Internet routing. 3.4 RANGI Assumptions: The following are the assumptions of the operational environment of RANGI. 1.

Hosts: Each host has an IPv4 local address and a set of IPv6 global addresses. The term “local” means that the address is assigned to the host by the organization network manager. Each host also has a 128 bit global ID and IPv6 aware higher layer protocols. The hosts are capable of supporting IPv6 over IPv4 tunnels.

2.

Border Routers: Border routers have similar requirements as that of hosts and all border routers support IPv6. Additional border router specific requirements include being able to setup IPv6 based BGP sessions with other border routers. 3. Core Routers (non-border): The core routers may be IPv4 or IPv6. Generally in the first phase of RANGI deployment, core router need not change. However, as core routers upgrade to IPv6 over time, RANGI becomes more efficient operationally. Till then RANGI depends on IPv6 over IPv4 tunneling mechanisms to interoperate with core routers. 4. RANGI Operations Having presented an overview of the RANGI design principles and the operational environment assumptions,, we discuss the operational details of the RANGI functions in this section. 4.1 RANGI Operation Overview: Figure 11, shows an overview of RANGI operations. It is a 2 step process for end-to-end connection establishment. Step 1: Assuming the source host has learnt the host identifier of the destination host, the source host resolves the destination identifier to the destination locator through the “mapping and negotiation function”. Step 2: Having learnt the destination locator and having completed initial inter-realm negotiations between the source and destination realm managers, the “routing function” is responsible for routing the packets between the source and the destination. The “mapping and negotiation function” is in accordance with our idea of realms (Section 2.1) and unlike most other proposals [20, 21 etc.], do not employ DHT(on flat IDs) or DNS mechanisms. DNS like mechanisms though highly scalable hurt the dynamicity of the mapping information and DHT (on flat IDs) mechanisms violate organizational structure. However, hierarchical DHT mechanisms [27] may be used within hierarchical boundaries of the Host ID, such that they preserve organizational structure.

Figure 11. RANGI Operations – Overview As per RANGI assumptions (Section 3.4), the global routing is based on IPv6 route data exchanges between locater domain border routers (LDBR’s). Hence the routing function routes packets between LDBR’s based on this information. The core routers for a particular transit network may still be IPv4. IPv6 over IPv4 tunnels are

employed to solve this problem of interoperability. Hence in Figure 11, steps 2, 4, 6 may have to employ tunneling if the core routers of LD 1, LD 2, and LD 3 respectively, are not IPv6 enabled. Steps 3 and 5, however, do not need to employ any tunnels as they represent communication between two IPv6 enabled border routers. Some of the key issues and the proposed RANGI solution are summarized below. 1. 2. 3.

Scalability: Multi-homing on PA addresses Mobility: Remapping functions Site Multi-homing: Each host within the multi-homed site is given multiple locators from different PA address spaces to which the site is multi-homed. 4. Interoperability and Backward Compatibility: a. Host IDs: Using IDs formatted inside IPv6-like 128-bit numbers to prevent changes to transport layer API’s. b. Locators: IPv6 locators inside IPv4 tunnels to inter-operate with legacy v4 routers 5. IP Address Space Depletion Problem: Incremental adoption of IPv6. 6. Site Traffic Engineering: Locator domain border router re-writing source locator prefix in data packets In the rest of this paper, we shall discuss each of these operational issues in more details. 4.2 The Mapping and Negotiation Function: The “Mapping and Negotiation” function is a host realm service. The “mapping function” refers to the mapping of the host IDs to locators. The “negotiation function” implements the inter-realm negotiation framework (between the source host realm and the destination host realm) and host-realm negotiation framework (between the host and its realm manager). Though separate in their functionality, we refer to them together because they are paired together to implement the connection setup process between a source host ID and a destination host ID. Mapping host-IDs to locators is an integral part of any locator/identity split architecture. However unlike other schemes, RANGI does not use DHT or DNS mechanisms. Host identifiers should identify a host in its logical domain whereas locators identify its physical point-of-presence. Based on this principle, RANGI implements the idea of realms (Section 2.1) and realm managers are responsible for the management of all IDs within the realm. Also, the realm managers need to form an overlay network using the globally unique Administrative Domain ID (ADID) (Section 3.3.4) part of the host ID, to be able to connect to each other. The hierarchical nature of the ADID attributes to the efficiency and ease of maintaining this overlay and routing over it. The connection setup process involves exchanges of 2 types of packets: 1.

S-type – “end-to-end connection request/response packet” exchanged between the source host and the

destination host. These packets consist of host-host connection parameters. 2. N-type – “Negotiation request/response packet” exchanged between 1) host and host realm manager, and 2) source host realm manager- destination host realm manger. These are XML–like packets for parameter based negotiations facilitating security, authorization, authentication and other policy related negotiations. Figure 12, shows a sequence diagram of a connection setup process. The connection setup process consists of four three-way handshakes. The S-type handshaking sets up the end-to-end connection-oriented transport-layertype.connection parameters. The N-type handshaking sets up the negotiation between the source and destination realm managers and between the end-hosts and their respective realm managers.

As mentioned in Section 3.4, RANGI assumes that RANGI aware hosts shall support IPv6 routing. This assumption is reasonable even in the present scenario since most host networking stacks have support for IPv6 although the hosts are not able to use IPv6 since most core routers are still IPv6-unaware. Another RANGI assumption is that the border routers in each locator domain (Locator Domain Border Routers or LDBR’s) shall support IPv6 routing and shall be able to setup IPv6 BGP sessions with neighboring LDBR’s to form a global IPv6 inter-LDBR distributed routing function. The core routers may remain to be legacy IPv4.

Figure 13. IPv6 Routing Overlay For locator domains where the core routers are legacy IPv4, the intra-LD routing is IPv4 address based and the packets sent out by the end-host are tunneled to LDBR using the IPv4 part of the locator coming from the lower 32 bits of the RANGI locator (LL part).

Figure 12. RANGI MN Function- Sequence Diagram The connection process is optimized by using “piggybacked” messages wherever possible. Also, it should be noted that Figure 12 shows the full feature connection setup process. At the end of this process, the end-hosts share common end-to-end connection parameters and part of inter-realm negotiation parameters that are applicable to them. A much more lightweight connection setup consists of just one S-type connection setup and one N-type inter-realm negotiation message. The inter-realm negotiation is still necessary for each realm manager to have minimal access control over its entities. 4.3 The Routing Function: The routing function of RANGI is a locator domain service and is implemented as an overlay of enhanced IPv6 capable routers over the routing space. As shown in Figure 13 and as already mentioned in the RANGI assumptions, the border routers and, hence, the inter-domain routing function needs to be IPv6 capable. RANGI proposes an incremental and interoperable strategy to overcome the constraints of limited IPv6 deployment over the current Internet.

A simple RANGI routing procedure is illustrated in Figure 14. Before a host sends out a packet, it looks up the current locator of the remote host through the ID/locator mapping system. After it gets the RANGI locator of the remote host, it tunnels the packets to the local LDBR using the IPv4 address (LL part). The LDBR shall find the next hop LDBR based on the IPv6 global routable locator, and forward the packets to it. For the intermediate transit networks, if the core routers are legacy IPv4 and if the packets need to traverse over them, the ingress LDBR tunnels the packets to the egress LDBR over IPv6 in IPv4 tunnels.

Figure 14. RANGI –IPV6 over IPv4 Tunneling 4.4 RANGI Site Multi-Homing and Routing Scalability: A PI locator site connected to more than one transit provider network and having each transit provider advertise

the PI prefix reachability from itself to the global routing function is the most natural form of multi-homing, and one that is commonly seen in today’s Internet using IPv4 PI addresses. However, as the number of stub-sites (locator domains that do not provide transit services to the global routing function) wanting to implement multi-homing using PI locators increases, the routing function is faced with a scalability problem. Each PI locator adds an entry to the global routing table and the Routing Information Base (RIB) exchange messages RANGI proposes a site multi-homing solution using PA locators. Each stub locator domain wanting to multi-home and connected to multiple provider locator domains shall be given a locator with a prefix from the aggregatable prefix space of the providers. The site, in turn, numbers each host with multiple locators by concatenating the provider assigned locator prefixes with the local 32 bit locator. The hosts register these multiple locators with their respective host realms. The lookup query of the global mapping function returns all the ID-locator bindings for a host in a multi-homed locator domain. The benefits of implementing a site multi-homing solution include resilience to link failures through redundancy and ability to perform source site traffic engineering. The PA locator based multi-homing solution in RANGI is implemented as follows (see Figure 15): 1. The source host sends out a packet using the one of its assigned locators as the source locator. 2. The packet is intercepted by the border router and depending on the outgoing link selection at the border router, the source locator of the packet is re-written. 3. The LDBR re-writes only the 92 bit prefix of the source locator field to match the PA prefix assigned to it by the provider site over which the packet is sent. The 32 bit local locator part remains the same. 4. The source host learns about the source locator rewriting by the LDBR after one round trip. For efficient implementation, the source host may change its local id-locator mapping and send the next packet with the new source locator, thus relieving the LDBR from the burden of re-writing every packet. 5. The upper layer protocols in RANGI remain oblivious to locator changes since they are bound to more permanent host IDs.

Figure 15. RANGI- Site Multi-homing Thus, RANGI helps solve the routing scalability problem by making traditional PI locator based locator domain services such as multi-homing available to PA locator based sites, reducing the number of PI locator assignments. 4.5 RANGI Traffic Engineering: In RANGI, as shown in Figure 16, the source site can traffic engineer all outgoing traffic in a manner similar to multi-homing (Section 4.4). As such traffic engineering is one of the motivations behind stub sites wanting to deploy a multi-homing solution.

Figure 16. RANGI- Site Traffic Engineering In case of PI-locator based site multi-homing, if one of the links to the site becomes unavailable, the global routing system can automatically redirect all traffic through the live link, as is done in the present PI IPv4 address based multihoming solutions. Multiple PA locator based site multihoming entails more complicated numbering and management, with each host receiving multiple locators from multiple PA locator domains to which the site is multi-homed. Also, the responsibility to “heal” in case of failed links is distributed between end hosts, the global routing function, and the LDBR (discussed in Section 4.6). However, such distribution of responsibility is advantageous when it comes to source site traffic engineering. PA locator based multi-homing has certain advantages in that the site can deterministically engineer inbound traffic by appropriately engineering its outbound traffic. 4.6 RANGI Multi-homing and Traffic Engineering Operational Issues: Implementing multi-homing and traffic engineering as discussed in Sections 4.4 and 4.5 incurs certain operational issues worth discussing. The two aspects of multi-homing that make it such an attractive proposition are: 1. 2.

Redundancy - to enable alternate means of reachability in case of operational failures in one path, and Traffic engineering - directing traffic to different providers based on parameters of cost, congestion etc.

Supporting redundancy requires operational data on locator liveness. Such data is available only to the entities that implement the routing functions. Traffic Engineering too is within the prerogative of the network operations. So the problem can be summarized as follows:

1.

2. 3.

After connection setup between two hosts, data needs to flow through the data path. The source host has to select a locator pair (source locator, destination locator). The locator pair it selects has to be 1) live and reachable, and 2) in accordance with the present traffic engineering decision of the source and destination locator sites. The host realm or the host is not in a position to take such operational decisions as pointed out in 1. The border routers at the source host locator domain has access to “liveness” information of the destination locator, but it neither has mapping information about all equivalent locators of a multi-homed destination locator domain, nor does it have traffic engineering information at the destination locator domain.

The RANGI solutions to these problems are as follows: 1.

2.

The source host finds a “live” destination locator by probing mechanisms. During the connection setup function (Section 4.2), the destination realm manager also needs to probe the destination host locators to find a “live” locator. This “live” locator information may be passed to the source host to aid in its probing function. The source locator is randomly chosen. The locator domain border router may re-write the source locator in the data packet for traffic engineering reasons. Similarly, even if the chosen destination locator is live, the locator domain of the destination host may rewrite the destination host locator. Similar rewriting may be done for avoiding unavailable paths. So during the course of a communication session, the source or destination locators may be re-numbered. It may be left at that, expecting the locator domain router to “rewrite” each data packet with the preferred ingress locator. However a more optimized solution shall be discussed in the next section.

4.7 Mobility vs. Multi-Homing: Both, mobility and multihoming require locators to change dynamically. In RANGI, locator change due to multi-homing is due to locator domain border router re-writing while locator change due to mobility is due to the host movement to a new locator domain. The effect though being same, mobility and multi-homing belong to two completely different paradigms and hence should be treated differently. In mobility, the host is aware of the change and can update its realm managers mapping database. A re-mapping function needs to be defined to learn this new mapping during the course of a communication session. The remapping function may employ a push or pull mechanism depending on whether or not the host realm manager maintains the communication state of each host. In multi-homing, the host is not immediately aware of the locator changes and also it is within the purview of the locator domain. As discussed earlier, “rewriting”

mechanisms are used by the LDBRs and it may be left at that with each data packet being re-written. However, an intelligent host ID layer at the host that fills in the locator fields in the packets, of both the source and the destination locator shall realize this after 1 round-trip. The host-ID layer in the host may update its local binding and also inform its own realm manager about the changes in its locator domain. Informing its realm manager alleviates the problem of “locator pair selection” to some extent. However, it must be noted that even if the host ID layer in the host does none of this, the communication process is still unhurt except for additional overheads of per-packet re-writing at the border routers. This brings us to the end of the discussion on RANGI operations. Due to constraints of space, we had to cut short our treatment of the various theoretical and operational aspects, hopefully without hurting the overall understanding of the main concepts. 5. RANGI-Comparison with Other Related Proposals We did a broad survey on the current available solutions related to our proposal. Based on the survey, we categorize the current solutions into two types according to their different major concerns or their key design goals [24]. The first category is core-edge separation. Their key goal is to solve the routing scalability problem. Currently all these related solutions are under review by the IRTF RRG. The key idea is to change the current situation lying in the BGP mechanism and keep the de-aggregated IP prefixes out of the global routing system. Based on our research, there are two different ways to fulfill this core-edge separation. One method is “IP-in-IP tunneling” mechanism wherein at the edge of the network the packets with PI addresses are encapsulated using a PA (Provider Assigned) address (PA addresses are assigned by ISP and are topologically aggregated). Thus, only strictly topologically aggregated addresses appear in the global routing system resulting in global routing scalability. Current solutions using this mechanism include LISP-ALT [5], LISP-NERD [7], APT [6], IVIP [22], TRRP[25], CRIO [28]. The second method employs “PI-PA indirection” which means the packets are not tunneled at the edge of the network but the internal addresses are replaced or re-written by the PA address in the edge. An example solution using this mechanism is SIX/ONE [29]. Another category of the related solutions to the problems space is called “ID/locator split”. ID/locator split tries to decouple the overloaded semantics in current IP address. By incorporating the ID in the end-hosts’ network stack, the upper-layer applications or protocols will only bind to the ID and the locator information will be transparent to the upper layer information. Currently there are several different ID/locator split solutions which have different design goals. Some focus on the mobility and security, the others focus on multihoming or multicasting issues. For example, main design goals of HIP (Host Identifier

Protocol) [20,21] are mobility and security; Shim6 [8] tries to address the multihoming in IPv6 environment. I3 [13] is designed to solve the mobility and multicast issues while

Hi3 [19] also provide security feature by combining HIP and I3.

Table 1. RANGI-Comparative survey of Related Work In Table 1, we list the key goals of various proposals and the special mechanisms they used to achieve the goals. Note that RANGI not only helps solve the problems in an unified manner it also provides a solution for organizational policy controls which none of the previous solutions have addressed. Many of the component mechanisms of RANGI have been proposed earlier to solve isolated problems. With RANGI, we not only unify many of these mechanisms but also provide a transition path to the next generation clean slate design. 6. SUMMARY We have presented a clean-slate multi-tier architecture for the long term evolution of the Internet. This multi-tier architecture allows independent organizational (administrative) ownership of infrastructure, hosts, users, and data objects. It allows each organization (which we call realm) to enforce its policies and to provide services to its members. It also leads us to the concept of multi-tier virtualization whereby a virtual realm is formed over a group of lower layer realms. Currently, a significant amount of research is being done on network virtualization which allows multiple virtual network infrastructures to be created over a set of physical network infrastructures. Our new multi-tier architecture indicates that the virtualization should not be limited to infrastructure tier alone. It applies to hosts, users, and data as well. Cloud computing is an example of application where we need to create virtual host realms over a set of physical hosts. Thus, we have created a new concept of multi-tier virtualization. Another innovative concept of this paper is that we not only present a clean-slate solution but also consider how it

can be applied to today's Internet resulting in a transition path that we call Routing Architecture for the Next Generation Internet or RANGI. RANGI uses only a twotier view - the infrastructure and the host tiers - of the multi-tier proposal. Using this view we propose a unified solution to mobility, multi-homing, scalability, traffic engineering, and secure-ID problems. These are real problems that the routing research group in the Internet research task force is aggressively debating. Providing a clean-slate architecture of which current Internet can be viewed as a subset and use it to solve the problems of today’s Internet is clearly unique. REFERENCES [1] B. Gleeson, et al, “IIP Based Virtual Private Networks,” RFC 2764, February, 2000. [2] C. Perkins, Ed., “IP Mobility Support for IPv4,” RFC 3220, January 2002 [3] D. Durham (Ed.), J. Boyle, R. Cohen, S. Herzog, R. Rajan, and A. Sastry, “The COPS (Common Open Policy Service) Protocol,” RFC 2748, January 2000. [4] D. Farinacci, V. Fuller, D. Oran, and D. Meyer, “Internet Draft: Locator/ID Separation Protocol (LISP),” draft-farinacci-LISP-03.txt, August 13, 2007. [5] D. Farinacci, V. Fuller, D. Meyer, “Internet Draft: LISP Alternative Topology (LISP+ALT),” draft-fuller-lisp-alt02.txt, April, 2008. [6] D. Jen, M. Meissel, D. Massey, et al., “Internet draft: APT: A Practical Transit Mapping Service,” draft-jen-apt01.txt, November, 2007.

[7] E. Lear, “Internet Draft: NERD: A Not-so-novel EID to RLOC Database,” draft-lear-lisp-nerd-04.txt, April, 2008. [8] E. Nordmark, M. Bagnulo, “Internet Draft: Shim6: level 3 multihoming Shim protocol for IPv6,” draft-ietf-shim6proto-09.txt, October 2007. [9] Energy Sciences Network (ESNet), http://www.es.net/ [10] NSF NeTS Future Internet Design Initiative, http://www.nets-find.net/

[24] T. Li, “Internet Draft: Design Goals for Scalable Internet Routing,” draft-irtf-rrg-design-goals-01.txt, July, 2007. [25] Internet Research Task Force Routing Research Group Wiki page, 2008. [26] Van Jacobson, “Content Centric Networking,” Presentation at DARPA Assurable Global Networking, January 30, 2007

[12] Global Environment for Network Innovations, http://www.geni.net/

[27] Xiaohu Xu, Dayong Guo, Raj Jain, Jianli Pan, Subharthi Paul, “RANGI: Routing Architecture for Next Generation Internet,” Presentation to Routing Research Group (RRG), Internet Research Task Force, meeting, Minneapolis, MN, November 21, 2008,

[13] Ion Stoica, Daniel Adkins, et al, “Internet Indirection Infrastructure,” ACM SIGCOMM 2002, Pittsburgh, PA, USA, 2002.

[28] X. Zhang, P. Francis, J. Wang, K. Yoshida, “Scaling IP Routing with the Core Router-Integrated Overlay,” ICNP 2006, Santa Barbara, CA, November 2006.

[14] J. Arkko, C. Vogt, W. Haddad, RFC 4866, Enhanced Route Optimization for Mobile IPv6, May 2007.

[29] C. Vogt, “Six/One: A Solution for Routing and Addressing in IPv6,” draft-vogt-rrg-six-one-01.txt, November, 2007.

[11] F. Templin, T. Gleeson, “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP),” RFC 5214, March, 2008.

[15] Jerome H. Saltzer, “On the Naming and Binding of Network Destinations,” RFC 1498, August 1993. [16] Jianli Pan, Subharthi Paul, Raj Jain, and Mic Bowman, “MILSA: A Mobility and Multihoming Supporting Identifier-Locator Split Architecture for Naming in the Next Generation Internet,” Globecom 2008, Nov 2008 [17] Jianli Pan, Subharthi Paul, Raj Jain, Mic Bowman, Xiaohu Xu, and Shanzhi Chen, “Enhanced MILSA Architecture for Naming, Addressing, Routing and Security Issues in the Next Generation Internet,” ICC 2009, Dresden, Germany, June, 2009. [18] Jerome H. Saltzer, David P. Reed, David D. Clark, “End-to-End arguments in System Design,” ACM Transactions on Computer Systems, pages 277-288, 1984. [19] P. Nikander, et al, “Host Identity Indirection Infrastructure (Hi3),” in the Second Swedish National Computer Networking Workshop 2004 (SNCNW2004), Karlstad, Sweden, November 2004. [20] R. Moskowitz, P. Nikander, "Host Identity Protocol (HIP) Architecture," RFC 4423, May 2006. [21] R. Moskowitz, P. Nikander, P. Jokela, T. Henderson, "Internet Draft: Host Identity Protocol," June 15, 2006, draft-ietf-hip-base-06.txt. [22] R. Whittle, “Internet Draft: Ivip (Internet Vastly Improved Plumbing) Architecture,” draft-whittle-ivip-arch00.txt, July 2007. [23] Subharthi Paul, Raj Jain, Jianli Pan, and Mic Bowman, “A Vision of the Next Generation Internet: A Policy Oriented View,” British Computer Society conference on Visions of Computer Science, September 2008.