Network Working Group X. Xu Internet Draft D. Guo Intended status: Experimental Huawei Technologies Expires: August 18, 2008 February 18, 2008 Hierarchical Routing Architecture (HRA) draft-xu-rrg-hra-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document describes a new routing and addressing architecture, which is based on identifier/locator split idea. This architecture introduces a hierarchical routing mechanism to support routing across multiple independent address spaces, besides, it also adopts a hierarchical host identifier to ease the management of a global identifier/locator mapping system. Xu, et al. Expires August 18, 2008 [Page 1] Internet-Draft Hierarchical Routing Architecture (HRA) February 2008 Table of Contents 1. Introduction.................................................2 2. Terminology..................................................3 3. Overview.....................................................4 4. Architecture.................................................5 4.1. Inter-LD Routing Protocol...............................5 4.2. ID/Locator Mapping System...............................6 4.3. Packet Format...........................................7 4.4. Packet Forwarding Behavior..............................8 4.4.1. Host Behavior......................................8 4.4.2. LDBR Behavior......................................8 4.4.3. Non-LDBR Router Behavior...........................8 4.4.4. Packet Forwarding Process..........................9 4.5. Mobility and Multihoming...............................10 4.5.1. Host Mobility and Multihoming.....................10 4.5.2. Site Multihoming..................................11 4.5.3. Network Mobility..................................11 5. Comparison with Related Works...............................12 6. Benefits of HRA.............................................13 7. Security Considerations.....................................13 8. IANA Considerations.........................................13 9. References..................................................13 9.1. Normative References...................................13 9.2. Informative References.................................14 Author's Addresses.............................................15 Intellectual Property Statement................................15 Full Copyright Statement.......................................16 Acknowledgment.................................................16 1. Introduction Some recent study has shown that the Internet routing table size is growing at a rate which almost exceeds the development speed of hardware technology. This issue has drawn much attention from both industry and academia. After much discussion following the IAB Routing and Addressing workshop [IAB-RAWS-Report] in Amsterdam, a common conclusion is reached that the explosive growth in Internet routing table is mainly caused by widely adoption of multi-homing, traffic engineering and provider-independent address, whereas the underlying reason is the overlapping semantics of IP address which is used as both locator and identifier. At present, the identifier/locator split idea has been widely recognized as an architectural solution to this so-called routing scalability issue. Xu, et al. Expires August 18, 2008 [Page 2] Internet-Draft Hierarchical Routing Architecture (HRA) February 2008 This document describes a new routing and addressing architecture, called as Hierarchical Routing Architecture (HRA). HRA is a kind of id/locator split solution. It introduces a hierarchical routing mechanism to support routing across multiple independent address spaces, besides, it also adopts a hierarchical host identifier to ease the management of a global identifier/locator mapping system. Within HRA, the Internet routing scalability and stability are improved evidently. 2. Terminology Terms common to other documents are defined in Table 1. +--------------+----------------------------------------------------+ | Term | Explanation | +--------------+----------------------------------------------------+ | asymmetric | An asymmetric cryptographic key pair consisting of | | key pair | public and private keys. For example, | | | Rivest-Shamir-Adelman (RSA) and Digital Signature | | | Algorithm (DSA) key pairs are such key pairs. | | | | | public key | The public key of an asymmetric cryptographic key | | | pair. Used as a publicly known identifier for | | | cryptographic identity authentication. | | | | | private key | The private or secret key of an asymmetric | | | cryptographic key pair. Assumed to be known only | | | to the party identified by the corresponding | | | public key. Used by the identified party to | | | authenticate its identity to other parties. | | | | | Host | An abstract concept assigned to a 'computing | | Identity | platform'. | | | | | Host | A public key used as a name for a Host Identity. | | Identifier | | | | | | Host | A 128-bit datum created by taking a cyptographic | | Identity Tag | hash over a Host Identifier. | | | +--------------+---------------------------------------------------+ Table 1 Terms special to this document are defined in Table 2. Xu, et al. Expires August 18, 2008 [Page 3] Internet-Draft Hierarchical Routing Architecture (HRA) February 2008 +--------------+----------------------------------------------------+ | Term | Explanation | +--------------+----------------------------------------------------+ | Locator | A network adopting independent address space and | | Domain | routing protocols. | | | | | Locator | The globally unique identifier of each LD. | | Domain ID | | | | | | Locator | The border router with which LD are connected. | | Domain Border| | | Router | | | | | | Hierarchical | A combination of administrative domain ID and a | | Host | hash value of Host Identifier. | | Identity Tag | | | | | +--------------+----------------------------------------------------+ Table 2 Abbreviations used in this document are defined in Table 3. +--------------+----------------------------------------------------+ | Abbreviation | Explanation | +--------------+----------------------------------------------------+ | LD | Locator Domain | | | | | LD ID | Locator Domain Identifier | | | | | LDBR | Locator Domain Border Router | | | | | HI | Host Identifier | | | | | HIT | Host Identity Tag | | | | +--------------+----------------------------------------------------+ Table 3 3. Overview Similar to the Host Identity Protocol [RFC4423], each host within HRA will have a globally unique Host Identifier (HI) and a corresponding Host Identifier Tag (HIT). HI is cryptographic in its nature, and it is the public key of an asymmetric key-pair. HIT can either be a 128- bit datum created by taking a cryptographic hash over a HI, which is Xu, et al. Expires August 18, 2008 [Page 4] Internet-Draft Hierarchical Routing Architecture (HRA) February 2008 a flat label without any semantics, or it can be a combination of an administrative domain ID and a hash value of a HI, which is a hierarchical label with some organizational semantics. The purpose of the hierarchical HIT within HRA is to ease the management of a global mapping system and improve the lookup efficiency. In the following sections of this document, the HIT will stand for both flat HIT and hierarchical HIT if no special statement is mentioned. HRA does not require globally unique IP address (also called as locator), multiple independent address spaces (also called as locator domains) could coexist within HRA. Each locator domain (LD) may deploy independent address space, that is to say, different LD may deploy different networking technologies, in particular IPv4, IPv6, global and private address spaces, or different LD can deploy overlapped address spaces. Each LD has a globally unique ID, which can be a flat label or a hierarchical label. In nature, a combination of LD ID and locator is a new globally unique locator. LDs are connected via Locator Domain Border router (LDBR). LDBR has at least one locator in each LD to which it is connected, and these locators have only LD-scope meanings and uniqueness. And like hosts, each LDBR also has a globally unique HI and HIT. HRA introduces a hierarchical routing architecture which is composed of LD-based routing and prefix-based routing. The former is used for packet forwarding across LD while the latter is used for packet forwarding within LD. The adjacent LDBRs, which are connected to a common LD, will exchange LD reachability information with Inter-LD routing protocol. The mapping of HIT, locator and LD ID will be stored in a distributed mapping system, such as DNS or DHT system. 4. Architecture 4.1. Inter-LD Routing Protocol Within HRA, an inter-LD routing protocol should be deployed between adjacent LDBRs for LD reachability information exchange. BGP can be extended with a new address family to fill this need. Besides, we can also design a new link-state protocol or distance-vector protocol as inter-LD routing protocol from scratch. In the respect of inter-LD routing protocol, HRA looks like the HLP [HLP],a next-generation inter-domain routing protocol which introduces an AS-level routing protocol. Xu, et al. Expires August 18, 2008 [Page 5] Internet-Draft Hierarchical Routing Architecture (HRA) February 2008 The LD ID can be a flat label or a hierarchical label. The benefit of hierarchical LD ID is that it can be aggregated provided some distance-vector protocol is deployed as inter-LD routing protocol. The detail of the inter-LD routing protocol will be addressed in the next version. 4.2. ID/Locator Mapping System In general, if source host wants to initialize a communication with destination host, it should firstly obtain the HIT, LD ID and locator of destination host from a distributed mapping system. There are many options for this purpose. The first option is the mapping of host name, HIT, LD ID and locator is stored in a DNS system. The host just needs one step query to get the needed information. The second option is the mapping of hash value of host name, HIT, LD ID and locator is stored in a DHT system, and the host will request the mapping information from the DHT system with the hash value of host name as key. The third option is the mapping of host name and HIT is stored in DNS, while the mapping of HIT, LD ID and Locator is stored in DHT, so the host will need two-step query to get the HIT, LD ID and locator of the destination host. To ease the management of id/locator mapping system and improve the lookup efficiency, hierarchical HIT is suggested to be adopted within HRA. With the hierarchical HIT, the mapping lookup efficiency can be improved by using the hierarchical DHT system [H-DHT]. Further, the home agent mechanism in Mobile IP [RFC4721] can also be introduced to support routing among super-peers provided that the administrative domain ID of the hierarchical HIT has the same format with LD ID and can be taken as LD ID. For example, once source host obtains the HIT of destination host, it will copy the administrative domain ID of HIT to the destination LD ID field of the data packet and send the packet out without locator option, when the data packet arrives at the LDBR of that specified destination LD, 1) the LDBR will act as a super- peer in the hierarchical DHT system and forward the received data packet to the closer peer in the lower-level DHT ring, 2)or the received data packet just triggers that LDBR to query LD ID and locator for the above HIT in the lower-level DHT ring, once the LDBR obtains the reply, it will cache the mapping of the HIT, LD ID and locator and the following received data packets can be forwarded according to the mapping entry in cache,3)LDBR stores mapping Xu, et al. Expires August 18, 2008 [Page 6] Internet-Draft Hierarchical Routing Architecture (HRA) February 2008 information of those HITs with administrative domain ID being the same as the LDBR's LD ID. The other option is that after the source host obtains the HIT of the destination host, it will takes the administrative domain ID as the destination LD ID of the query packet and send it out, the query packet is for the purpose of obtaining the corresponding LD ID and locator of the HIT. After the query packet arrives at the at the LDBR of that destination LD, the LDBR will act as a super-peer in hierarchical DHT and forward the received query packet to the closer peer in the lower-level DHT ring. Until the source host obtains the LD ID and locator of the destination host, it will encapsulate and send data packet to the destination host. In a word, there are many combinations as result of tradeoff between scalability and efficiency. The detail of the hierarchical HIT and corresponding mapping system will be described in a separate draft. 4.3. Packet Format Generally, the LD ID and HIT of source host and destination host should be contained in the packet, whereas the locator of source host and destination host is optional. The purpose of carrying the destination host locator in the packet is to keep the LDBR of the destination LD from performing mapping lookup, that is to say, once the packet arrived at the LDBR of destination LD, the LDBR just need to replace destination IP address with destination host locator. During the transmission, HIT and LD ID fields usually remain unchanged, whereas the destination IP address and source IP address in the IP header will be continuously rewritten by each-hop LDBR along the path to destination. |--- IP header --||---------- Global ID/Locator header -----| ++-----+-----+---++-------+-------+------+------+------+---++-------+ ||dstIP|srcIP|...||dstLDID|srcLDID|dstHIT|srcHIT|option|...||payload| ++-----+-----+---++-------+-------+------+------+------+---++-------+ / \ / \ / \ +------+------+ |dstLoc|srcLoc| +------+------+ Figure 1 The concrete packet format will not be fixed in this initial draft due to the fact that the format greatly lies on the special scenarios. Xu, et al. Expires August 18, 2008 [Page 7] Internet-Draft Hierarchical Routing Architecture (HRA) February 2008 The above figure is just a demonstration. In IPv6 packet, the global ID/Locator header could be carried as an extended field, while in IPv4 packet, the global ID/Locator header could be carried as a new- type payload. 4.4. Packet Forwarding Behavior 4.4.1. Host Behavior Generally, source host will firstly obtain the locator and LD ID information of destination host from a distributed mapping system before initializing a communication with destination host. If the LD ID of the destination host is the same as its own, source host will encapsulate the packet with destination IP address being filled with destination host locator and send it out, otherwise, source host encapsulate the packet with destination IP address in the IP header being filled with one of its LDBR locator and send it out. The host can get its local LDBR in one of the following options: 1) LDBR information is contained in Router Advertisement; 2) LDBR information is carried in DHCP extended option; 3) Host obtains the LDBR info from its default gateway via a new protocol; 4) All LDBRs provide a unified well-known anycast address for host to access. The details about how to obtain local LDBR info will be addressed in the next version. 4.4.2. LDBR Behavior Except for exchanging LD reachability information with each other, LDBR can receive those packets with destination being one of its locators, and forward those packets on basis of the destination LD ID and locator within those packets. Besides, LDBR can also do some source LD validation, similar to the source IP address validation mechanism in current Internet. 4.4.3. Non-LDBR Router Behavior There is no additional requirement on the forwarding plane of the Non-LDBR routers. These routers just forward the received packets according to the destination IP address, and optionally do source IP address validation. There is almost no requirement on the control plane of the Non-LDBR routers except that these routers may be needed to flood the LDBR information within LD. Xu, et al. Expires August 18, 2008 [Page 8] Internet-Draft Hierarchical Routing Architecture (HRA) February 2008 4.4.4. Packet Forwarding Process The following is a brief introduction of packet forwarding process within HRA. Firstly, Source host obtains the locator and LD ID of destination host from a distributed mapping system. If the LD ID of the destination host is the same as its own, source host will encapsulate the packet with destination IP address being filled with destination host locator and send it out, otherwise, source host encapsulate the packet with destination IP address in the IP header being filled with one of its LDBR locator and send it out. In both of the above cases, the locator and LD ID of the source and destination host are also carried in those IP packets. Those packets will be forwarded by the internal routers within source host's LD step by step according to the destination IP address in those packets. When the packets arrive at the LDBR, the LDBR will decapsulate the received packets and look up the matching route in the LD routing table, according to the destination LD ID in the packets. Within HRA, if the LD ID is flat, we use exact-matching lookup algorithm, else if that is hierarchical, we use longest-matching lookup algorithm. Once a matching routing entry is found, the LDBR will forward the packets according to the next-hop LDBR of that route entry. If the next-hop LDBR is itself, which means the packets have arrived at the destination LD, the LDBR will subsequently look up the matching route entry in the corresponding prefix routing table of the destination LD. Once a matching routing entry is found, the LDBR will forward the packets to the destination host directly with destination IP address being replaced with destination host locator. If the next-hop LDBR is not itself, but another LDBR, it will forward the packets to that next-hop LDBR with destination IP address being replaced with the next-hop LDBR locator. As this locator is routable within the common LD to which these two adjacent LDBRs are attached, the internal routers within that LD will forward the IP packets according to the destination IP address in the packets, until the packets arrives at the next-hop LDBR. The following LDBRs and internal routers within LD will forward the packets in the same way. Let's illustrate this procedure further with the following figure. In figure 2, host A will get the HIT, LD ID and locator of host D before sending packets to host D, as the LD ID of host D is not the same with its own, host A will send the packet out with destination IP address being filled with the locator of one of it's LDBRs, such as BR2, and source IP address being filled with its own locator, the LD ID and locator fields will also be filled in respectively. When the packet arrives at the BR2, BR2 will lookup the LD routing table for matching entry, the next-hop LDBR of the matching entry is BR5, BR2 will rewrite the packet with destination IP address being filled with one locator of BR5, which is routable in LD3, and the source IP Xu, et al. Expires August 18, 2008 [Page 9] Internet-Draft Hierarchical Routing Architecture (HRA) February 2008 address being filled with one of its locators, which is also routable in LD3. When the packet arrives at the BR5, BR5 will also lookup the LD routing table for matching entry, the next-hop LDBR of the matching entry is itself BR5, which means the packet has arrived at the destination LD, BR5 will fill destination IP address with the destination host locator and fill the source IP address with one of its locators, which is routable in LD5 respectively and send it out, finally, the packet will be forwarded step-by-step to host D by the internal routers according to the destination IP address. /-------\ / \ +---+ x LD1 x---| A | \ / +---+ \-------/ /-BR1-/ \-BR2-\ /-------\ /-------\ / \ / \ X LD2 X------BR6-------X LD3 X \ / \ / \-------/ \-------/ | \-BR3-\ /-BR4-/ \-BR5-\ +---+ /-------\ /-------\ | B | / \ / \ +---+ X LD4 X X LD5 X \ / \ / \-------/ \-------/ | | +---+ +---+ | C | | D | +---+ +---+ Figure 2 To some extent, HRA lifts routing granularity of current Internet one level, in an abstract, LD within HRA looks like IP subnet, LDBR within HRA looks like IP router and locator within HRA looks like MAC address. 4.5. Mobility and Multihoming 4.5.1. Host Mobility and Multihoming Host mobility and multi-homing change will trigger registration update in the mapping system. Xu, et al. Expires August 18, 2008 [Page 10] Internet-Draft Hierarchical Routing Architecture (HRA) February 2008 When a mobile host changes its attachment to a new location, it should register to the mapping system with the new location information. Hierarchical mobility management mechanism in [RFC4140] can be used in HRA to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent. 4.5.2. Site Multihoming Hosts within a multi-homed site usually have more than one locator, and these locators can either be obtained from different LDs or the same LD. The mapping of HIT, LD ID and locator will show the multi- homing status of the host. If there is more than one locator associated with one HIT, the host owning that HIT is ought to be multi-homed. 4.5.3. Network Mobility To support network mobility, we still need to introduce NEMO like mechanism into the HRA. Since there can be multiple independent LDs coexisting and the locator has only LD-scope meanings within HRA, so we need to do some extension to the current NEMO mechanism. The home agent within HRA will maintain the mapping between globally unique home address and the globally unique foreign address. The globally unique address means the combination of the LD ID and the locator. The mobile router should update its location information, including current foreign LD in which the mobile router is currently located, and the corresponding foreign locator that the mobile router has obtained from the foreign LD, to its home agent, as soon as its attachment changed. The home agent can act either as LDBR or as host within HRA, in the former case, the home agent should just receive LD routing information and forward the packets with destination of mobile network to the proper LDBR, in the latter case, the home agent just forwards the packet with destination of mobile network to one of its local LDBR which may not be the proper LDBR. Like the current NEMO mechanism, packets are forwarded from the home agent to the mobile router, in a tunnel with destination of the mobile router. Within HRA, network mobility is transport to those hosts within mobile network. Xu, et al. Expires August 18, 2008 [Page 11] Internet-Draft Hierarchical Routing Architecture (HRA) February 2008 5. Comparison with Related Works In the respect of multiple locator domains coexistence, HRA looks similar to Node ID Internetworking Architecture (NIIA) [nid-arch].The main differences from NIIA are: 1) Within the NIIA, there should be a stable core LD, and all the other LDs should be connected to the core LD directly or indirectly. Most of the traffic will go across the core LD. While within HRA, there is no limitation on the topology, that is to say, those LDs within HRA can be connected in mesh. 2) Within the NIIA, as the network topology is tree-based, there seems no need to run a LD-based routing protocol. Besides, the NR use host-based routing mechanism which means a potential scalability issues if LD contains a lot of hosts. While in HRA, LDBRs exchange LD reachability information and support LD-based routing mechanism. 3) Within the NIIA, the existence and characteristics of connectivity between two locator domains, especially the edge locator domains, may change dynamically on relatively short timescales, due to routing changes, mobility or multi-homing events. LD mobility triggers host within the mobility LD to update the registration, especially when the CER is changed, that's to say, the LD mobility is not fully transparent to the host. Within HRA, the connectivity between locator domains is relatively stable and the mobility of partial network in LD still depends on the NEMO [RFC3963] like mechanism, and network mobility is transparent to those hosts within mobile network. In respect of two-level routing architecture, HRA looks more like ENCAPS [RFC1955]. The main differences between HRA and ENCAPS are: 1) ENCAPS doesn't introduce an independent host identifier namespace to hide the heterogeneity of different address spaces and so it can not support co-existence of multiple independent address spaces. 2) ENCAPS adopts reserved IPv4 address for autonomous domains (AD) address and the AD address is directly used as tunnel destination address, which should be routable for internal routers within AD, whereas HRA uses next-hop LDBR locator as IP destination address in IP header, and the IP address in IP header will be rewritten by each LDBR along the path to destination, which looks more like the usage of MAC address between routers. 3) ENCAPS assumes that the current IP-Addresses can remain globally unique for a long time, and since the address space in each AD is not independent, ENCAPS is helpless in dealing with the depletion of IPv4 Xu, et al. Expires August 18, 2008 [Page 12] Internet-Draft Hierarchical Routing Architecture (HRA) February 2008 address space. On the contrary, the combination of LD ID and locator (if each locator domain adopts the same network address technology, such as IPv4) within HRA will form a new global locator namespace, which eliminates the necessity of adopting IPv6 for providing huge addresses. 6. Benefits of HRA Firstly, within HRA, only LD-based routing information will be exchanged between LDs and prefix-based routing information is just maintained within each LD. In this way, routing table size in each DFZ router will be reduced greatly. That is to say, the routing scalability issue will be solved with HRA. Secondly, prefix-based route change or route churn in one LD will not be flooded to another LD, which greatly improves the routing stability. Thirdly, provided that each locator domain adopts independent IPv4 address space, a combination of LD ID and locator will become a new globally unique locator in nature, which eliminates the necessity of adopting IPv6 for providing huge addresses. Lastly, with adoption of hierarchical HIT, the lookup efficiency for id/loc mapping is improved further and maintain and management of the global HIT namespace becomes more practical. 7. Security Considerations HRA is a kind of locator/identifier split solution with cryptographic identifiers, similar to the HIP [RFC4423]. Therefore, the end-to-end security properties are similar to those already expressed for the HIP [RFC4423]. 8. IANA Considerations If BGP is used for LD-based routing protocol, a new family address type needs to be defined for LD routing information. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Xu, et al. Expires August 18, 2008 [Page 13] Internet-Draft Hierarchical Routing Architecture (HRA) February 2008 9.2. Informative References [IAB-RAWS-Report]D. Meyer, L. Zhang, and K. Fall. "report from the iab workshop on routing and addressing". Internet draft, draft-iab-raws-report-01.txt, work in progress, February 2007. [irtf-rrg-design-goals] T. Li, "Design Goals for Scalable Internet Routing", draft-irtf-rrg-design-goals-01, July 2007. [RFC4721] C. Perkin, Ed.,"IP Mobility Support for Ipv4", RFC4721, Jan 2007. [RFC4423] R. Moskowitz, and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [RFC4140] H. Soliman, C. Castelluccia, K. El Malki, L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC4140, August 2005 [RFC3963] V. Devarapalli, R. Wakikawa, A. Petrescu and P. Thubert "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC3007] Wellington, B., "Secure Domain Name System (DNS)Dynamic Update", RFC 3007, November 2000. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC1995] R. Hinden, "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", RFC 1995, June 1996. [RFC1992] I. Castineyra, N. Chiappa and M. Steenstrup "The Nimrod Routing Architecture", RFC 1992, August 1996. [nid-arch] B. Ahlgren, J. Arkko, L. Eggert and J. Rajahalme,"A Node Identity Internetworking Architecture", 9th IEEE Global Internet Symposium, Barcelona, Spain, April 2006. [H-DHT] L. Garcs-Erice, E. Biersack, P. Felber, K. Ross, and G. Urvoy-Keller, "Hierarchical Peer-to-peer Systems" In Proc. Euro-Par 2003, Klagenfurt,Austria, 2003. Xu, et al. Expires August 18, 2008 [Page 14] Internet-Draft Hierarchical Routing Architecture (HRA) February 2008 [HLP] L. Subramanian, M. Caesar, C.T. Ee, M. Handley, M. Mao, S. Shenker and I. Stoica, "HLP: A Next Generation Inter- domain Routing Protocol", SIGCOMM'05, August 2005, Philadelphia, Pennsylvania, USA. [GSE] M. O'Dell, "GSE-An Alternative Addressing Architecture for IPv6", Internet-Draft, Feb 1997. [ROFL] M. Caesar, T. Condie, J. Kannan, K. Lakshminarayanan, I. Stoica and S. Shenker,"ROFL: Routing on Flat Labels", SIGCOMM'06, September 2006, Pisa, Italy. Author's Addresses Xiaohu Xu European Research Center Huawei Technologies Co.,Ltd. Reuterstr 122 D-53129 Bonn Germany Phone: +49 228 40392 2256 Email: xuxh@huawei.com Dayong Guo Huawei Technologies Co.,Ltd KuiKe Building, No.9 Xinxi Rd., Hai-Dian District Beijing, 100085 P.R. China Phone: +86 10 82836077 Email: guoseu@huawei.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information Xu, et al. Expires August 18, 2008 [Page 15] Internet-Draft Hierarchical Routing Architecture (HRA) February 2008 on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Full Copyright Statement Copyright (C) The Internet Society (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Xu, et al. Expires August 18, 2008 [Page 16]