[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] A new draft about Hierarchical Routing Architecture
Hi all,
I have just finished a draft about Hierarchical Routing Architecture (HRA),
which is also a kind of id/loc split solution. The following is an abstract
of HRA.
Abstract: Hierarchical Routing Architecture (HRA) is a kind of id/locator
split solution. It introduces a hierarchical routing mechanism (a
combination of LD-based routing and prefix-based routing) to support routing
across multiple independent address spaces, besides, it also adopts a
hierarchical host identifier to ease the management of a global id/locator
mapping system. With HRA, the Internet routing scalability and stability are
improved evidently, and the scalability issue of flat HIT in HIP is also
solved, besides, the necessity of adopting IPv6 is also eliminated to some
extent as those locator domains can adopt overlapped IPv4 address spaces.
Sorry I missed the deadline of 00-version submission, so I have to attach
this draft in email. Any comments are welcomed.
Best regards,
Xiaohu Xu
Network Working Group X. Xu
Internet Draft D. Guo
Intended status: Experimental Huawei Technologies
Expires: May 16, 2008 November 16, 2007
Hierarchical Routing Architecture (HRA)
draft-xu-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 May 16, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 May 16, 2008 [Page 1]
Internet-Draft Hierarchical Routing Architecture (HRA) November 2007
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 academe. 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 May 16, 2008 [Page 2]
Internet-Draft Hierarchical Routing Architecture (HRA) November 2007
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 May 16, 2008 [Page 3]
Internet-Draft Hierarchical Routing Architecture (HRA) November 2007
+--------------+----------------------------------------------------+
| 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 May 16, 2008 [Page 4]
Internet-Draft Hierarchical Routing Architecture (HRA) November 2007
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 LDs may
deploy different networking technologies, in particular IPv4, IPv6,
global and private address spaces, or difference LDs 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 May 16, 2008 [Page 5]
Internet-Draft Hierarchical Routing Architecture (HRA) November 2007
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
destination host.
To easily guarantee the global uniqueness of HIT and improve lookup
efficiency, hierarchical HIT is suggested to be adopted within HRA.
With 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 hierarchical DHT 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 information of those
Xu, et al. Expires May 16, 2008 [Page 6]
Internet-Draft Hierarchical Routing Architecture (HRA) November 2007
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 May 16, 2008 [Page 7]
Internet-Draft Hierarchical Routing Architecture (HRA) November 2007
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 May 16, 2008 [Page 8]
Internet-Draft Hierarchical Routing Architecture (HRA) November 2007
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
NR2, 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 NR2, NR2 will lookup the LD routing table for
matching entry, the next-hop LDBR of the matching entry is NR5, NR2
will rewrite the packet with destination IP address being filled with
one locator of NR5, which is routable in LD3, and the source IP
Xu, et al. Expires May 16, 2008 [Page 9]
Internet-Draft Hierarchical Routing Architecture (HRA) November 2007
address being filled with one of its locators, which is also routable
in LD3. When the packet arrives at the NR5, NR5 will also lookup the
LD routing table for matching entry, the next-hop LDBR of the
matching entry is itself NR5, which means the packet has arrived at
the destination LD, NR5 will fill destination IP address with the
destination host locator and fill the source IP address with one of
its locators, which are 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 |
\ / +---+
\-------/
/-NR1-/ \-NR2-\
/-------\ /-------\
/ \ / \
X LD2 X------NR6-------X LD3 X
\ / \ /
\-------/ \-------/
| \-NR3-\ /-NR4-/ \-NR5-\
+---+ /-------\ /-------\
| 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 May 16, 2008 [Page 10]
Internet-Draft Hierarchical Routing Architecture (HRA) November 2007
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 May 16, 2008 [Page 11]
Internet-Draft Hierarchical Routing Architecture (HRA) November 2007
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 May 16, 2008 [Page 12]
Internet-Draft Hierarchical Routing Architecture (HRA) November 2007
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, provides 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 May 16, 2008 [Page 13]
Internet-Draft Hierarchical Routing Architecture (HRA) November 2007
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. Garces-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 May 16, 2008 [Page 14]
Internet-Draft Hierarchical Routing Architecture (HRA) November 2007
[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 May 16, 2008 [Page 15]
Internet-Draft Hierarchical Routing Architecture (HRA) November 2007
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 May 16, 2008 [Page 16]