One document matched: draft-xu-rangi-01.txt
Differences from draft-xu-rangi-00.txt
Network Working Group X. Xu
Internet Draft Huawei
Intended status: Informational
Expires: January 2010 July 13, 2009
Routing Architecture for the Next Generation Internet (RANGI)
draft-xu-rangi-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 January 13, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Xu Expires January 13, 2010 [Page 1]
Internet-Draft Routing Architecture July, 2009
for the Next Generation Internet (RANGI)
Abstract
IRTF Routing Research Group (RRG) is exploring a new routing and
addressing architecture to address the issues with the current
Internet, e.g., mobility, multi-homing, traffic engineering, and
especially the routing scalability. This document describes a new
identifier (ID)/locator split based routing and addressing
architecture, called Routing Architecture for the Next Generation
Internet (RANGI), in an attempt to deal with the above problems.
Table of Contents
1. Introduction.................................................3
2. Architecture Description.....................................3
2.1. Host Identifiers........................................3
2.2. Host Locators...........................................5
2.3. Packet Formats..........................................6
2.4. ID/Locator Mapping Resolution...........................7
2.5. Routing and Forwarding System...........................8
2.5.1. Host Behavior......................................8
2.5.2. LDBR Behavior......................................8
2.5.3. Non-LDBR Behavior..................................9
2.5.4. Forwarding Procedures..............................9
2.6. Multi-homing and Traffic-Engineering...................11
2.7. Mobility...............................................13
3. Summary.....................................................13
4. Security Considerations.....................................14
5. IANA Considerations.........................................14
6. Acknowledgments.............................................14
7. References..................................................14
Xu Expires January 13, 2010 [Page 2]
Internet-Draft Routing Architecture July, 2009
for the Next Generation Internet (RANGI)
1. Introduction
The Default Free Zone (DFZ) routing table size has been growing at an
increasing and potentially alarming rate for several years, which has
detrimental impact on the routing system scalability and the routing
convergence performance. This so-called routing scalability issue has
drawn significant attention from both industry and academia. After
much discussion following the IAB Routing and Addressing workshop
[RAWS] in Amsterdam, a common conclusion was reached that the
explosive growth in the DFZ routing table is mainly caused by the
wide adoption of multi-homing, traffic engineering and provider-
independent address. However, the underlying reason for this issue is
the overloading of IP address semantics of both identifiers and
locators. This overloading makes it impossible to renumber IP
addresses in a topologically aggregatable way.
At present, the IRTF Routing Research Group (RRG) is chartered to
explore a new routing and addressing architecture which could support
the multi-homing, traffic-engineering, mobility and simplified
renumbering features in a more scalable way.
This document describes an ID/locator split approach, called Routing
Architecture for the Next Generation Internet (RANGI), which aims to
deal with the above issues. Similar with Host Identity Protocol (HIP)
[RFC4423], RANGI also introduces a host identifier layer between the
IP network layer and the transport layer. As a result, the transport-
layer associations (i.e., TCP connections and UDP associations) are
no longer bound to IP addresses, but to the host identifiers. The
major difference from the HIP is that the host identifier in RANGI is
hierarchical and cryptographic host identifiers which have
organizational structure. As a result, the ID/locator mapping system
for such identifiers has reasonable business model and trust
boundaries. In addition, RANGI uses special IPv6 addresses with IPv4
address embedded in the last four octets as locators. With this
special locator, site-controlled traffic-engineering can be easily
supported and the renumbering works during ISP change are also
simplified greatly. Besides, the deployment cost of the new
architecture is reduced greatly and the new architecture could be
deployed in a more incremental way.
2. Architecture Description
2.1. Host Identifiers
Similar to the HIP, RANGI is also a kind of ID/locator split
architecture. It introduces a 128-bit hierarchical host identifier.
Xu Expires January 13, 2010 [Page 3]
Internet-Draft Routing Architecture July, 2009
for the Next Generation Internet (RANGI)
As depicted in Figure 1, this identifier is composed of two parts,
the leftmost n-bit part is the Administrative Domain (AD) ID which
has embedded organizational affiliation and global uniqueness, and
the remaining part is the local host ID which is a hash over the AD
ID and the public key of the ID owner. In order to distinguish
identifiers from locators (IPv6 addresses) in the transition
mechanisms [RANGI PROXY], identifiers use a specific prefix, which is
to be allocated from the IPv6 address space by IANA. Hence several
leftmost bits in the AD ID field should be reserved for this purpose.
|<------- n bits --------->|<-- 128-n bits-->|
+--------------------------+-----------------+
| Administrative Domain ID | Local Host ID |
+--------------------------+-----------------+
| \
| \
| \
| \
| \
+-----------+-------------+-------------+
| Country ID| Authority ID| Region ID | <------Example
+-----------+-------------+-------------+
Figure 1. Host Identifier Structure
The purposes of the hierarchical host ID in RANGI are 1)to ease the
management of the global identifier namespace resource; 2)to hold the
economic and trust model in the ID/locator mapping system; 3)to ease
the transition from the current Internet to the RANGI.
In RANGI, the global uniqueness of host IDs should be guaranteed
through some registration mechanism. Since the AD IDs are globally
unique and owned by the host ID registration and administrative
authorities from different countries, the second part of the host ID
(i.e., the local host ID) just needs to be unique within the
corresponding AD scope.
The resolution infrastructure for flat label has no "pay-for-your-
own" model, as names are stored at essentially random nodes (See
Layered Naming Architecture (LNA) [LNA]). In contrast, the resolution
infrastructure for the hierarchical host IDs in RANGI has reasonable
business model and clear trust boundaries since they are stored in
the corresponding nodes according to the organizational structures of
the host IDs. To some extent, the business model of the ID/locator
mapping system is similar with that for the Domain Name Service (DNS)
Xu Expires January 13, 2010 [Page 4]
Internet-Draft Routing Architecture July, 2009
for the Next Generation Internet (RANGI)
In the transition mechanisms for RANGI described in [RANGI-PROXY],
identifiers are treated as IPv6 addresses by legacy hosts, and
routers will forward the IPv6 packets with destination addresses
being identifiers. Since the identifiers are hierarchical and
aggregatable, the identifier based routing will not cause any routing
scalability issue. For more information, please refer to [RANGI-
PROXY].
The approach of generating hierarchical host identifiers in RANGI is
much similar to the Cryptographically Generated Addresses (CGA)
[RFC3972]. The major difference is that the prefix of the RANGI host
identifier is AD ID, rather than ordinary IPv6 address prefix. In the
CGA, the process of generating a new CGA takes three input values: a
64-bit subnet prefix, the public key of the address owner as a DER-
encoded ASN.1 structure of the type SubjectPublicKeyInfo and the
security parameter Sec, which is an unsigned three-bit integer. In
RANGI, the process of generating a new host identifier also takes
three input values: the n-bit AD ID (the suitable value of "n" has
not been determined), the public key of the host ID owner and the
security parameter Sec.
2.2. Host Locators
Host locators in RANGI are just IPv6 addresses. Since the IPv4/IPv6
coexistence and transition will last for a long period of time, in
order to reduce the deployment cost of the new routing and addressing
architecture, RANGI uses specific IPv6 addresses with IPv4 address
embedded in the last 4 octets as locators. As shown in Figure 2, the
leftmost 96-bit part of the locator is Locator Domain Identifier (LD
ID), and it is used to globally identify each autonomous site network
which adopts independent IPv4 address space. Actually, the LD IDs are
provider-assigned (PA) /96 IPv6 prefixes which are topologically
aggregatable. The rightmost 32-bit part is the host's IPv4 address
which is locally unique in the corresponding LD scope.
Xu Expires January 13, 2010 [Page 5]
Internet-Draft Routing Architecture July, 2009
for the Next Generation Internet (RANGI)
|<------- 96 bits -------->|<---- 32 bits--->|
+--------------------------+-----------------+
| LD ID | IPv4 |
+--------------------------+-----------------+
Figure 2. Host Locator Structure
Similar with the Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP) [RFC5214], this specific locator can be used to
automatically tunnel IPv6 packets over the destination IPv4 site
networks since the IPv4 address part of the destination locator is
used as the destination address of the tunnel header.
2.3. Packet Formats
RANGI-aware hosts reuse IPv6 protocol stack and packet format to
maximum extent. The host identifier simply appears as a Next Header
in the IPv6 header, as depicted in Figure 3, whereas the locator is
filled as the IPv6 address in the IPv6 header, as shown in Figure 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Protocol Type | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Host ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Host ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Host Identifier Header Format
Xu Expires January 13, 2010 [Page 6]
Internet-Draft Routing Architecture July, 2009
for the Next Generation Internet (RANGI)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Source LD ID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Destination LD ID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Host Locator Header Format
The details regarding how to use IPsec to carry the data traffic will
be described in the latter version of this draft or in a separate
draft.
2.4. ID/Locator Mapping Resolution
ID/locator split implies a need for storing and distributing the
mappings from identifiers to locators.
Within RANGI, the mappings from Fully Qualified Domain Names (FQDN)
to host identifiers are stored in the DNS system, while the mappings
from host identifiers to locators are stored in a distributed
id/locator mapping system (e.g., a hierarchical Distributed Hash
Table (DHT) system, or a reverse DNS system).
When using the hierarchical DHT system as the ID/locator mapping
system, the AD ID of the host ID is regarded as a key in the top-
level DHT ring to locate the corresponding bottom-level DHT ring,
whereas the local host ID part is used as a key in the corresponding
bottom-level DHT ring to determine the corresponding peer which
Xu Expires January 13, 2010 [Page 7]
Internet-Draft Routing Architecture July, 2009
for the Next Generation Internet (RANGI)
stores the desired ID/locator mappings. In practice, the top-level
DHT ring can split further into multiple levels according to the
hierarchical structure of the AD ID. To some extent, such a mapping
system is a combination of the DNS and the DHT, and the top-level is
more like the DNS since the routing is based on the former part of
the host identifier (i.e., hierarchical AD ID), whereas the bottom-
level is a DHT because the routing is based on the latter part of the
host identifier (i.e., the flat local host ID).
The resolution infrastructure for flat names has no "pay-for-your-
own"model, as the flat names are stored at essentially random nodes.
In contrast, the resolution infrastructure for the hierarchical host
identifiers, as used in RANGI, has reasonable business and trust
model, since the hierarchical host identifiers have clear
organization affiliation and the identifier resources can be managed
with clear administrative boundaries.
2.5. Routing and Forwarding System
Within the RANGI, LDs are connected via Locator Domain Border Routers
(LDBRs). A LDBR has at least one locally unique IPv4 address in each
LD to which it is connected. The adjacent LDBRs exchange LD ID or LD
prefix (Specific LD IDs can be aggregated into one LD prefix)
reachability information with an inter-LD routing protocol. In fact,
the Border Gateway Protocol (BGP) for IPv6 address family can be used
directly as the inter-LD routing protocol.
2.5.1. Host Behavior
Generally, a source host will obtain the locator of the destination
host from the ID/locator mapping system before initializing a
communication. If the LD of the source host is identical with that of
the destination host, the source host will send the packets directly
to the destination host over an IPv4 tunnel. Otherwise, the source
host will forward the packets towards the local LDBR over IPv4
tunnels.
Hosts can get the IPv4 addresses of their local LDBRs in several ways,
e.g., a new Dynamic Host Configuration Protocol (DHCP) option, or a
well-known LD-scope anycast address specific for LDBRs.
2.5.2. LDBR Behavior
LDBRs establish BGP sessions among them so as to exchange LD
reachability information (i.e., IPv6 routing information with the
mask length less than /96). LDBR can forward IPv6 packets according
Xu Expires January 13, 2010 [Page 8]
Internet-Draft Routing Architecture July, 2009
for the Next Generation Internet (RANGI)
to the LD ID of the destination locator (IPv6 address) over IPv4
tunnels.
2.5.3. Non-LDBR Behavior
The non-LDBRs just need to support IPv4 forwarding capability. So
there is no need to upgrade them.
2.5.4. Forwarding Procedures
RANGI introduces a two-level routing mechanism which is composed of
LD ID based routing and IPv4 address based routing. The former is
used for inter-LD routing while the latter is used for intra-LD
routing.
A simple RANGI routing procedure is illustrated in Figure 5. Source
host A looks up the current locator of the destination host B through
the ID/Locator mapping system. After obtaining that information, host
A will tunnel the packets with destination address being host B to
one of its local LDBRs. The LDBR shall find the next-hop LDBR based
on the IPv6 globally routable locator, and forward the packets to it.
For the intermediate transit networks, if the Non-LDBR routers which
the packets have to traverse are legacy IPv4 routers, the ingress
LDBR (for that locator domain) forwards the packet to the egress LDBR
of the same locator domain over IPv4 tunnels.
Xu Expires January 13, 2010 [Page 9]
Internet-Draft Routing Architecture July, 2009
for the Next Generation Internet (RANGI)
+-------------+ +-------------+ +-------------+ +-------------+
| Payload | | Payload | | Payload | | Payload |
+-------------+ +-------------+ +-------------+ +-------------+
|HI(A)->HI(B) | |HI(A)->HI(B) | |HI(A)->HI(B) | |HI(A)->HI(B) |
+-------------+ +-------------+ +-------------+ +-------------+
|IPv6->IPv6 | |IPv6->IPv6 | |IPv6->IPv6 | |IPv6->IPv6 |
| (A) (B) | | (A) (B) | | (A) (B) | | (A) (B) |
+-------------+ +-------------+ +-------------+ +-------------+
|IPv4->IPv4 | | IPv4->IPv4 | |IPv4->IPv4 |
| (A) (BR1) | |(BR2) (BR3) | | (BR4) (B) |
+-------------+ +-------------+ +-------------+
|<- A to BR1 ->|<-BR1 to BR2 ->|<-BR2 to BR3 ->| |<-BR4 to B ->|
+--------- ------ ---------|
+---+ \ / \ / +---+
| A | \ / \ / /| B |
+---+\\ \ / \ / // +---+
| \\ | | | | / |
| \\ +---+ +---+ +---+ +---+// |
| \|BR1+----+BR2+------+BR3+---+BR4+/ |
| +---+- -+---+ +---+ +---+ |
| | | | | |
\ / \ / \ /
\ LD #1 / \ LD #2 / \ LD #3 /
\ / \ / \ /
------ ------ ------
Figure 5. Routing Procedure
For the intra-LD routing, RANGI uses the IPv6-over-IPv4 tunnels
between LDBRs (or between LDBRs and hosts). Hence, RANGI can achieve
a smooth IPv4/IPv6 transition. Once the internal routers within LDs
are upgraded to IPv6, the requirement of IPv6 over IPv4 tunnel
between the LDBRs or between LDBRs and hosts will be eliminated and
the packets will be delivered by the LDBRs and the internal IPv6
routers hop by hop without tunneling as shown in Figure 6.
Xu Expires January 13, 2010 [Page 10]
Internet-Draft Routing Architecture July, 2009
for the Next Generation Internet (RANGI)
+-------------------+ +-------------------+ +-------------------+
| Payload | | Payload | | Payload |
+-------------------| +-------------------| +-------------------|
| HI(A)->HI(B) | | HI(A)->HI(B) | | HI(A)->HI(B) |
+-------------------| +-------------------| +-------------------|
| IPv6(A)->IPv6(B) | | IPv6(A)->IPv6(B) | | IPv6(A)->IPv6(B) |
+-------------------| ++------------------| +-------------------|
|IPv4(A)->IPv4(BR1) |
+-------------------+
|<--- A to BR1 --->|<----- BR1 to BR4 --->|<--- BR4 to B --->|
+--------- ------ ---------|
+---+ \ / \ / +---+
| A | \ / \ / /| B |
+---+\\ \ / \ / // +---+
| \\ | | | | / |
| \\ +---+ +---+ +---+ +---+// |
| \|BR1+----+BR2+------+BR3+---+BR4+/ |
| +---+- -+---+ +---+ +---+ |
| | | | | |
\ LD #1 / \ LD #2 / \ LD #3 /
\ (IPv4) / \ (IPv6) / \ (IPv6) /
\ / \ / \ /
------ ------ ------
Figure 6. IPv4/IPv6 Transition
2.6. Multi-homing and Traffic-Engineering
In RANGI, Each multi-homed stub LD shall be assigned a LD ID by each
upstream ISP. In fact, these LD IDs are /96 IPv6 prefixes which are
topologically aggregatable in provider networks. Each Host within the
multi-homed site, in turn, has multiple locators by concatenating the
provider-assigned LD IDs with its locally unique IPv4 address. These
hosts register the mappings from their identifiers to locators with
the ID/Locator mapping system. As shown in Figure 7, host A which is
located in a multi-homed site, has two LD IDs, LD ID_1 and LD ID_2,
assigned separately from ISP1 and ISP2. Host A chooses either one as
the source LD ID of the outgoing packets. Upon receiving the packets,
the site exit LDBR, BR1, implements source-based policy routing. For
example, if the source LD is LD ID_1, the packets will be forwarded
into the ISP1's network, otherwise, they will be forwarded into
ISP2's network.
Xu Expires January 13, 2010 [Page 11]
Internet-Draft Routing Architecture July, 2009
for the Next Generation Internet (RANGI)
------
/ \
/ \
/ \
| |
+---+ |
+BR2| |
/+---+ |
/ | |
/ \ /
/------ / \ ISP#1 /
+---* \ / \ /
| A | \ / ------
+---+\\ \ /
| \\ | /
| \\ +---+ /
| \|BR1+/ ------
| +---+-- / \
| | -- / \
\ / -- / \
\ Site A / -- | |
\ / -- +---+ |
------ --+BR3| |
+---+ |
| |
\ /
\ ISP#2 /
\ /
------
Figure 7. Site Multi-homing and Traffic-engineering
The site-controlled traffic-engineering works as follows:
I. The source host sends out packets with the source LD ID being one
of its LD IDs (assuming LD ID 1 being used).
II. The packets are intercepted by the LDBR BR1, and according to the
traffic-engineering policy, the source LD IDs of the packets may
be re-written from LD ID_1 to LD ID_2. Then BR1 forwards the
packets into ISP2's network due to source-based policy routing.
III. Once the packets arrive at the destination host, that host will
use the source LD IDs in the received packets as the destination
Xu Expires January 13, 2010 [Page 12]
Internet-Draft Routing Architecture July, 2009
for the Next Generation Internet (RANGI)
LD IDs in the response packets. So the response packets will
also enter the site A through the ISP2's network.
IV. The source host could accept this change and use LD ID 2 as the
source LD ID in the subsequent packets.
Similar to the GSE [GSE], the site-controlled traffic-engineering by
rewriting the source LD ID will have effect on the path (upstream ISP)
selection for both the outgoing packets and the incoming packets. In
addition, the multi-homing and traffic-engineering usages in RANGI
will not cause any routing scalability issue.
2.7. Mobility
In RANGI, when a host physically moves from one attachment to another,
its host ID remains unchanged. The host needs to register the new
locator with the ID/locator mapping system. Meanwhile, it should
notify the corresponding entity of its new locator as soon as
possible.
3. Summary
RANGI achieves almost all of goals set by RRG as follows:
1. Routing Scalability: Scalability is achieved by separating the
identifiers from locators. Global routing is done based on
provider assigned locators.
2. Traffic Engineering: LDBRs can overwrite the LD ID part of the
source locator and implement source-based policy routing
according to the source LD ID.
3. Mobility and Multi-homing: Applications and transport layers are
bound to host IDs and so the sessions will not be interrupted due
to locator change in cases of mobility or multi-homing.
4. Simplified Renumbering: When changing providers, the local
locators (IPv4 part of the locators) do not change. The non-LDBR
within the LD don't need renumbering.
5. Decoupling Location and Identifier: Obvious.
6. Routing Quality: Since LDBRs only exchange LD reachability and
the topology within LD will not be disclosed outside, the routing
stability could be improved greatly.
Xu Expires January 13, 2010 [Page 13]
Internet-Draft Routing Architecture July, 2009
for the Next Generation Internet (RANGI)
7. Routing Security: RANGI reuses current routing system and does
not introduce any new security risk into the routing system.
8. Incremental Deployability: non-LDBR within LD can still be IPv4-
only. RANGI allows easy transition from IPv4 networks to IPv6
networks. In addition, the transition mechanisms for RANGI
defined in [RANGI-PROXY] allows RANGI hosts to communicate with
the legacy IPv4 or IPv6 hosts, and vice versa.
4. Security Considerations
TBD.
5. IANA Considerations
A specific prefix for host identifiers needs to be assigned from the
IPv6 address space.
6. Acknowledgments
The author would like to thank Raj Jain for his valuable comments and
reviews. Thanks should also be given to several experts who commented
on the earlier versions of this proposal including Dave Oran, Joel
Halpern, and Tony Li.
7. References
[RAWS] 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.
[GOALS] T. Li, "Design Goals for Scalable Internet Routing", draft-
irtf-rrg-design-goals-01, July 2007.
[RFC4423] R. Moskowitz and P. Nikander, "Host Identity Protocol (HIP)
Architecture", RFC 4423, May 2006.
[RFC3972] T. Aura, "Cryptographically Generated Addresses (CGA)",
RFC3972, Mar 2005.
[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.
[GSE] M. O'Dell, "GSE-An Alternative Addressing Architecture for
IPv6", Internet-Draft, Feb 1997.
Xu Expires January 13, 2010 [Page 14]
Internet-Draft Routing Architecture July, 2009
for the Next Generation Internet (RANGI)
[LNA] Hari Balakrishnan, Karthik Lakshminarayanan, Sylvia
Ratnasamy,Scott Shenker, Ion Stoica and Michael Walfish, "A
Layered Naming Architecture for the Internet", Proc. ACM
SIGCOMM, Portland, Oregon, USA, August 30 - September 3,
2004.
[RFC5214] F. Templin, T. Gleeson, "Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP)," RFC 5214, March, 2008.
[RANGI-PROXY] X. Xu, "Transition Mechanisms for Routing Architecture
for the Next Generation Internet (RANGI)", draft-xu-rangi-
proxy-01.txt, July 2009.
Authors' Addresses
Xiaohu Xu
Huawei Technologies,
No.3 Xinxi Rd., Shang-Di Information Industry Base,
Hai-Dian District, Beijing 100085, P.R. China
Phone: +86 10 82836073
Email: xuxh@huawei.com
Xu Expires January 13, 2010 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-24 10:30:10 |