Internet DRAFT - draft-xu-rrg-hra

draft-xu-rrg-hra



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]