One document matched: draft-liang-idr-aira-00.txt
Inter-Domain Routing Working Group Weifang. Liang
Internet Draft NDSC
Intended status: Informational Yue. Zhang
Expires: May 2011 Zhengzhou University
Dongnian. Cheng
NDSC
November 9, 2010
An AS-based Inter-domain Routing Architecture for a Scalable
Internet (AIRA)
draft-liang-idr-aira-00.txt
Abstract
This document describes a simple, incremental, autonomous system
(AS)-based inter-domain routing architecture to solve the scalability
problems of the Internet, by separation of Endpoint Identifiers (EIDs)
for identifying endpoints and Routing Identifiers (RIDs) for locating
endpoints in the Internet. The proposed architecture uses AS numbers
as RIDs so that global routing tables can grow only with of AS
numbers, thus avoiding the rapid growth driven by constantly
increasing IP prefixes.
This proposal was stimulated by the problem statement effort at the
Amsterdam IAB Routing and Addressing Workshop in October 2006.
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 May, 2011.
Liang Expires May,2011 [Page 1]
Internet-Draft AIRA November 2010
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction.................................................2
2. Conventions used in this document............................5
3. Terminology..................................................5
4. Network Topology.............................................8
5. Routing.....................................................10
5.1. Intra-AS Routing.......................................10
5.2. Inter-AS Routing.......................................11
5.3. Basic Description......................................11
6. Format Considerations.......................................14
6.1. Intra-AS Packet Format.................................14
6.2. Inter-AS Packet Format.................................15
7. Evaluations of the Benefits.................................15
7.1. Improved Scalability...................................15
7.2. Improved Stability.....................................16
7.3. Incremental Deployment.................................17
8. Analysis of the Routing Tables Growth.......................18
8.1. AS Growth..............................................18
8.2. Multi-homing and Traffic Engineering...................20
8.3. Fragmented Address.....................................21
9. Security Considerations.....................................22
10. IANA Considerations........................................22
11. Conclusions................................................22
12. References.................................................22
12.1. Normative References..................................22
12.2. Informative References................................24
13. Acknowledgments............................................24
1. Introduction
The current Internet is a decentralized collection of ASes from all
around the world. Every one of these ASes usually uses one or more
Liang Expires May,2011 [Page 2]
Internet-Draft AIRA November 2010
Interior Gateway Protocols (IGPs) such as Routing Information
Protocol (RIP), Open Shortest Path First (OSPF) or Intermediate
System (IS-IS) for exchange of routing information within an AS. On
the other hand, these ASes use inter-domain routing protocol to
exchange reachability information to establish routes among them and
to allow the transmission of packets accross different ASes. The
Border Gateway Protocol (BGP) is currently the de-facto standard of
inter-domain routing protocols in the Internet.
The initial design of BGP improves scalability by IP prefixes
aggregation. But with the development of the Internet, there are a
large number of unaggregated IP prefixes, resulting in the rapid
growth of global routing table at an alarming rate over recent years.
The rapid growth of global routing tables imposes a considerable
pressure on the scalability of the Internet. Studies show that the
main factors driving such a growth include multi-homing and traffic
engineering that advertised abundant unaggregated prefixes. In
addition, fragmented addresses are also account for the routing table
growth.
BGP advertises destination prefixes to create routes in the current
Internet. The routers use Routing Information Base (RIB) and
Forwarding Information Base (FIB) to store route information: The
former holds detailed information of routes to destination prefixes,
while the later performs packet forwarding. That is, for a given
destination prefix, the RIB stores all routes related to the
destination prefix, and the FIB maps the prefix to a local exit
address. Because it stores routes of all reachable prefixes to local
exit addresses in the Internet, the FIB will grows with the growth of
IP prefixes in the current Internet. The number of IP prefixes has
increased at an amazing rate over recent years. As a result, the FIB?
size has accordingly increased over recent years, and will exceed the
storage capability of routers [1].
In order to solve the scalability problems caused by multi-homing and
traffic engineering, several separation and mapping architectures [2-
8] have been developed, which separate the Endpoint Identifiers (EIDs,
which are used for identifying the endpoint) from the Routing
Identifiers (RIDs, which are used for locating the endpoint in the
Internet, also called RLOCs in some cases) and then place both into
two different name spaces respectively, and use a mapping system to
distribute EID-to-GRID mapping information through the Internet.
These separation and mapping architectures fall into two categories
[9]: Core-Edge Separation (CES) and Core-Edge Elimination (CEE). The
CES separates the transit ASes and stub ASes into two different
address spaces. The routing table maintains the reachability
information related to IP prefixes of transit ASes, removing stub AS
IP prefixes from the inter-domain routing architecture for reducing
Liang Expires May,2011 [Page 3]
Internet-Draft AIRA November 2010
the global routing table size. The CEE assigns multiple addresses to
a multi-homing stub AS for aggressively aggregating addresses. A
multi-homing stub AS receives one Provider Aggregated (PA) address
from per provider, and each of its provider will aggregate the
address with own PA address for reducing the unaggregated addresses.
Both of CES and CEE can alleviate the scalability pressure the
current inter-domain routing architecture is facing. However, they
essentially do not change the routing mechanisms and protocols of the
current Internet. The CES shrinks the address range to reduce the
size of a routing table, while the CEE aggregates the address space
to eliminate the stub AS addresses from the global routing area. If
using aggregated IP addresses to locate transit ASes, the global
routing table will still grow with prefixes due to multi-homing,
traffic engineering, and fragment addresses of transit ASes.
According to the data from the [10] from Mar. 2004 to Mar. 2008 and
the AS relationship from [11], the percent of multi-homing edge
transit ASes is about 71%-76%, while the percent of multi-homing stub
ASes is about 54%-57%. In addition, the average number of providers
of a multi-homing transit AS is 3, while it is 2 for a stub AS.
Therefore, if the RIDs use the IP addresses by aggregating prefixes
to scale the global routing system, the inter-domain routing
architecture still faces salability problems caused by multi-homing,
traffic engineering, and fragmented addresses of transit ASes.
The authors believe that IP prefixes are too fine routing
granularities to scale the routing system. Addressing the scalability
problems caused by using aggregated IP addresses in separation and
mapping architecture, this document proposes an AS-Based Inter-
routing architecture (AIRA)which uses AS numbers (domain identifiers
for ASes) as GRIDs. The proposed architecture focuses on the
following issues: (1) By adopting 4 bytes AS numbers as GRIDs without
introducing a new name space, our proposal can be not only compatible
with the current IPv4 addresses but also available for future growth
of the Internet [12], so that routers can forward packets without
updating. (2) By using GMS(s) to support multi-homing and traffic
engineering for stub ASes, our proposal makes the multi-homing and
traffic engineering of stub ASes has no impact on the sizes of global
routing tables, and which makes the reachability of GRIDs completely
maintained in global routing tables. As a result, the global routing
table of the proposed architecture grows only with AS numbers, other
than IP prefixes. On the other hand, the proposed architecture makes
it easy to perform traffic engineering and to support routing
policies for all ASes and hosts.
Related work on AS-based solutions is given in Geographically
Informed Inter-domain Routing (GIRO) [13], Metro-base addressing [14],
Liang Expires May,2011 [Page 4]
Internet-Draft AIRA November 2010
Geo-based addressing [15], Hybrid Link-state Path-vector (HLP) [16],
and Hierarchical Routing Architecture (HRA) [17]. Recently, some
schemes have been proposed to find how to design and assign GRID [18],
which is believed as a key of inter-domain routing based on ASes.
However, this document attempts to not compete or overlap with such
solutions and approaches.
After the introduction and related work given, the document is
proceeded as follows: Section 3 defines terms used in this document.
Section 4 describes network topology relevant to AIRA. Section 5
describes the routing mechanisms in the AIRA. Section 6 portrays the
format of packet being used in the AIRA. Section 7 evaluates the
benefits, and Section 8 analyzes the routing table growth, relevant
to AIRA in future individually.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
3. Terminology
This section defines terms relevant to AIRA and to be used in this
document. All of them is presented here for completeness, while some
of them are borrowed from other solutions [2-8].
AIRA Stub Autonomous System (AIRA-Stub-AS): a network, similar to a
customer network in the current Internet, that is a source or
destination of packets.
AIRA Transit Autonomous System (AIRA-Transit-AS): an AS whose
business is to provide forwarding services for AIRA-Stub-ASes. All
the AIRA-Transit-ASes form the core network similar to Default Free
Zone in the current Internet.
Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value
used in the source and destination address fields of an IP packet. A
host obtains a destination EID the same way it obtains a destination
address today, for example through a DNS lookup or SIP exchange. The
source EID is obtained via existing mechanisms used to set a host's
"local" IP address. An EID is allocated to a host from an EID-prefix
block associated with the AIRA-Stub-AS where the host is located. An
EID can be used by a host to refer to other hosts (i.e. it is global
unique). EIDs MUST NOT be used neither as LRIDs nor as GRIDs. Note
that EID blocks may be assigned in a hierarchical manner, independent
of the network topology, to facilitate scaling of the Local Mapping
Server (LMS) database. In addition, an EID block assigned to an AIRA-
Liang Expires May,2011 [Page 5]
Internet-Draft AIRA November 2010
Stub-AS may have an AIRA-Stub-AS local structure (subnetting), and
this structure is not visible to the global routing system.
End-system: an IPv4 or IPv6 device that originates packets and
supplies an EID value for the destination address and the source
address field of the IP packets with IPv4 or IPv6 address when
communicating globally (i.e. outside of its AIRA-Stub-AS as usually).
An end-system can be a host computer, a switch or router device, or
any network appliance.
Local Routing Identifier (LRID): a 32-bit (for IPv4) or 128-bit (for
IPv6) value which is assigned to an interior router and is ONLY used
in the "LRID of Destination" fields in the intra-AS packet format
(see figure 2) for routing within the AS. A LRID is the output of a
EID-to-LRID mapping lookup. An EID MAY be mapped to one or more LRIDs.
Note that LRID MUST be locally unique within an AS, it MUST be
invisible out of the AS and all of the LRID(s) that locates within
the same AIRA-AS.
Global Routing Identifier (GRID): a 32-bit (4-bytes) value which is
assigned to an AS (no matter what the AS is an AIRA-Stub-AS or an
AIRA-Transit-AS). A GRID CAN appear either in the "LRID of
Destination" field in an intra-AS packet (see figure 2) or in an "AS
number of Destination" field in the inter-AS packet (see figure 3).
However, the GRID ONLY be used for inter-AS routing in the core
network. It is the output of an EID-to-GRID mapping lookup. An EID
MAY be mapped to one or more GRIDs. Because AIRA uses AS numbers as
GRIDs and an inter-domain routing table ONLY contains AS numbers, the
global routing table thus ONLY grows with AS numbers, not IP prefixes.
On the other hand, the AIRA adopts 4-byte AS numbers as GRIDs without
defining a new name space, which is not only compatible with current
IPv4 addresses but also available for the future growth of the
Internet. Therefore, routers can forward packets without updating.
Note that GRID MUST be globally unique in the AIRA, that is, all of
the GRID(s) form the Global Forwarding Sysytem.
AIRA-Transit-AS Border Router (AIRA-Transit-ASBR): an border router,
connected to ASBRs, which has the capability of rewriting addresses
and exchange inter-AS reachability information by BGP. Every AIRA-
Transit-AS MUST deploy one or more AIRA-Transit-ASBRs in order to
connect with other ASes. An AIRA-Transit-ASBR at least has a LRID of
the AS that it accesses. The LRID is used to represent a location
within AS. Two AIRA-Transit-ASes can directly connect, and an AIRA-
Stub-AS can connect one or more upstreaming AIRA-Transit-ASes for
multi-homing and traffic engineering purposes.
EID-to-LRID Cache: a short-lived, on-demand table in an access router
(AR) of an AS that stores, tracks, and is responsible for timing-out
Liang Expires May,2011 [Page 6]
Internet-Draft AIRA November 2010
and otherwise validating EID-to-LRID mappings. This cache is distinct
from the full "EID-to-LRID Database" in a Local Mapping Server (LMS)
of the same AS. It is dynamic, local to the AR(s), and relatively
small while the database is distributed, relatively static, and much
more global in scope of the AS.
EID-to-LRID Database: a globally distributed database that contains
all known EID-to-LRID mappings. Each potential AR typically contains
a small portion of the database: the EID-to-LRID mappings for the EID
"behind" the router. These map an EID to a LRID of the AR's own and
locally-visible IP addresses. The same database mapping entries MUST
be configured on all ARs for a given AS.
EID-to-GRID Cache: a short-lived, on-demand table in an AIRA-Transit-
ASBR of an AIRA-Transit-AS that stores, tracks, and is responsible
for timing-out and otherwise validating EID-to-GRID mappings. This
cache is distinct from the full "EID-to-GRID Database" in a Local
Mapping Server (LMS) of the same AS. It is dynamic, local to the
AIRA-Transit-ASBR(s), and relatively small while the database is
distributed, relatively static, and much more global in scope.
EID-to-LRID Database: a global distributed database that contains all
known EID-to-GRID mappings. Each potential AIRA-Transit-ASBR
typically contains a small portion of the database: the EID-to-GRID
mappings for the EID "behind" the AIRA-Transit-ASBR. These map an EID
to the GRID, the AIRA-Transit-ASBR's own and globally-visible AS
Number. The same database mapping entries MUST be configured on all
AIRA-Transit-ASBRs for a given AIRA-Transit-AS.
Local Mapping Server (LMS): an entity which locates within either one
AIRA-Stub-AS or one AIRA-Transit-AS, and which stores the EID-to-LRID
mapping information to resolve the LRID for Intra-AS routing. Note
that, an AIRA-Transit-AS could have one or more LMS(s); all of the
AIRA-Transit-AS' LMS(s) form the Local Routing System, together with
all of the EID-to-LRID cache(s) that locates within the different
AIRA-Transit-AS' ASBR(s), and together with all of its interior
router(s). In addition, the Local Routing System ONLY locates within
the AIRA-Transit-AS (i.e. it is invisible to the outside of the AIRA-
Transit-AS). Similar to the AIRA-Transit-AS' LMS(s), AIRA-Stub-AS'
LMS(s) also constitutes its Local Routing System, however, together
with all of the EID-to-LRID cache(s) that locates within the
different AIRA-Stub-AS' AR(s).
Global Mapping Server (GMS): an entity which ONLY locates within the
AIRA-Transit-AS(s), and which stores the EID-to-GRID mapping
information to resolve the GRID for Inter-AS routing. Several GMSs
have been proposed such as LISP-DHT [19], DHT-Map [20], and they are
also suitable for AIRA. Note that, an AIRA-Transit-AS could have one
Liang Expires May,2011 [Page 7]
Internet-Draft AIRA November 2010
or more GMS(s). All of the AIRA-Transit-AS' GMSs form the Global
Routing System, together with all of the EID-to-GRID cache(s) that
locate in the different AIRA-Transit-AS' ASBR(s); at the same time,
the Global Routing System ONLY locates within the core network.
4. Network Topology
This section describes the network topology related to AIRA.
According to Section 3.1, the AIRA consists of provider networks and
customer networks as the situations in today's Internet. That is, the
combination of the provider networks and customer networks together
refers to the main part of the Internet. Such a network topology is
considered here: AIRA-Transit-ASes form the core network similar to
the Default Free Zone in the current Internet, which provides data
forwarding services for AIRA-Stub-ASes; while AIRA-Stub-ASes
constitute customer networks similar to the customer networks in the
current Internet, which MAY connect themselves to one or more
provider networks, and which ONLY be traffic sources or sinks of data
traffic (Figure 1 shows the network topology).
End system (hosts) are located in customer networks and are
identified by EIDs. An EID is assigned to an end host and does not
change during the lifetime of the end host. In addition, both the
source and the destination of a packet are represented by the EID of
the sending end host and the receiving end host, respectively. On the
one hand, when an end host which locates in one AIRA-Stub-AS sends an
original packet, the packet CAN be routed to its Customer Edge Router
(CER) by using mechanisms such as IGP (See details later in Section
4.1). On the other hand, the AIRA-Transit-AS which receives the
original packet, and to which the AIRA-Stub-AS immediately connects
through one of its ASBR(s), MAY use one of the ASBR's LRID(s) to
rewrite the EID of this packet (See details later in Figure 2) within
its local range (if the case is need). When the destination of the
rewroten packet does not belong to itself,the AIRA-Transit-AS MUST
rewrite the rewritten packet again (See details later in Figure 3) in
a hop-by-hop manner until the rewritten packet ultimately reaches the
destination of the original packet. Finally, the other AIRA-Stub-AS,
to which the end host's correspondent host belongs, SHOULD also route
any original packet to the end host's correspondent host by using
mechanisms such as IGP.
Liang Expires May,2011 [Page 8]
Internet-Draft AIRA November 2010
+--------------------------------------------------------------+
| *************** |
| ** ** ** ** ** ** |
| * AIRA-Transit-AS1* |
| ** ** ** ** ** ** |
| *************** |
| / \ |
| +------+ +------+ |
| |BSAR11| |BSAR12| |
| +------+ +------+ |
| | | |
| | | |
| +------+ +------+ |
| |BSAR21| |BSAR31| |
| +------+ +------+ |
| / \ |
| *************** *************** |
| ** ** ** ** ** ** ** ** ** ** ** ** |
| * AIRA-Transit-AS2* * AIRA-Transit-AS3* |
| ** ** ** ** ** ** ** ** ** ** ** ** |
| *************** *************** |
| / / \ |
| +------+ +------+ +------+ |
| |BSAR22| |BSAR32| |BSAR33| |
| +------+ +------+ +------+ |
| | | | | |
| | | | | |
| +---------+ +---------+ +---------+ +---------+ |
| |AS1-CER11| |AS1-CER21| |AS1-CER22| |AS1-CER31| |
| +---------+ +---------+ +---------+ +---------+ |
| / \ / \ |
| ************* ************* ************* |
| *AIRA-Stub-AS1* *AIRA-Stub-AS2* *AIRA-Stub-AS3* |
| ************* ************* ************* |
| / / \ \ |
| +--------+ +--------+ +--------+ +--------+ |
| |AS1-AR11| |AS2-AR21| |AS2-AR22| |AS3-AR31| |
| +--------+ +--------+ +--------+ +--------+ |
| | | | | |
| | | | | |
| +-----+ +-----+ +-----+ +-----+ |
| |Host1| |Host2| |Host3| |Host4| |
| +-----+ +-----+ +-----+ +-----+ |
+--------------------------------------------------------------+
Figure 1 The AIRA's Network Topology
Liang Expires May,2011 [Page 9]
Internet-Draft AIRA November 2010
5. Routing
This section describes the routing in the AIRA, which includes intra-
AS routing, inter-AS routing, and basic description.
5.1. Intra-AS Routing
Each AS in AIRA is an independent AS, and uses own interior routing
protocols. Each AS can independently select an interior routing
protocol.
The reachability information that an AS learns from the exterior
needs to be distributed within an AS so that the outside of the AS is
reachable from every router inside in the current Internet. As a
result, the FIB of DFZ routers maps all IP prefixes to local exit
addresses. With the growth of prefixes, the all DFZ routers face the
scalability pressure.
The FIB of AIRA maps the all AS numbers in core network to local exit
addresses. The inter-AS routing table maintains the reachability
information of all the ASes based on AS numbers, and the intra-AS
routing table only stores local routing information. In order to
forward a packet to a local exit address, the router needs map the AS
number to a local exit address. AIRA defines a local neighbor table
to store AS numbers and the exit addresses of neighboring ASes. The
form of local neighboring table is (AS number, LRID, Weight), where
Weight is for the traffic engineering purpose. For example, if two
ASes directly connect each other by a link, Weight=1. If two ASes
directly link by i links, the sum of all i Weights is 1 and
1<=Weight<=1.
Endpoints are donated with EIDs in AIRA. To reach an endpoint in the
Internet, the routers need RIDs. The LMS provides the LRIDs for a
source endpoint host. The LRIDs of the source and destination hosts
are filled into packets addressed towards destination EID so that it
can be carried through the stub ASes and forwarded to the destination.
The packet format is showed in Figure 2. The Source EID and
Destination EID are the endpoint identifiers of the source and
destination hosts respectively, and the LRID of Destination and AS
number of Destination are the LRID and 4-byte AS numbers of the
destination respectively.
The interior routers forward packets according to intra-domain
routing information until the packets reach their destinations.
Liang Expires May,2011 [Page 10]
Internet-Draft AIRA November 2010
5.2. Inter-AS Routing
The BGP advertise 4-byte AS numbers in AIRA. The FIB of ASBR maps all
AS numbers to local exit addresses through three tables. The ASBR
firstly maintains the Inter-AS table to store the reachbility
information of AS numbers for mapping the AS number to next AS number.
Secondly, the ASBR stores the local neighbor table for mapping the AS
numbers to local exit addresses. Thirdly, the ASBR stores the intra-
routing table for forwarding packets to the exit address.
When an ASBR located in a transit AS receives a packet without local
AS number, it looks up its inter-AS routing table to decide the next
hop AS, and then looks up the local neighbor table to decide the
local exit address. According to the exit address, the ASBR forwards
packet according to ths intra-routing routing table. The format of a
packet is showed in figure 3. The Source EID and Destination EID are
the endpoint identifiers of the source and destination hosts
respectively, and the LRID of ASBR and AS number of Destination are
the local exit addresses and 4-byte AS number of the destination
respectively.
In fact, when a packet reaches a transit AS, the ASBR needs to kook
up the inter-AS routing table for obtaining the next AS number, and
looks up the neighbor table for gaining the local exit address.
5.3. Basic Description
This portion provides an example of the unicast packet flow with the
following conditions (refers to Figure 1 above)
o Source host "host1" wants to communicate with the destination host
"host2", note that, "host1" is directly attached to the AIRA-Stub-
AS1' "AS1-AR11", while "host2" is immediately linked to the AIRA-
Stub-AS3' "AS3-AR32"
o Each AIRA-AS may be multi-homed, such as AIRA-Stub-AS2 is
connected both to AIRA-Transit-AS2 through the "AS2-CER21" and the
"BSAR22" and to AIRA-Transit-AS3 through the "AS2-CER22" and the
"BSAR32"
o Each BSAR may rewrite the packet that it receives from the other
AIRA-AS
o The details of looking up LMS and GMS are ignored, however, this
document assumes that every look-up is successful.
Liang Expires May,2011 [Page 11]
Internet-Draft AIRA November 2010
When the Source host "host1" wants to communicate with the
destination host "host2", the packet sequence between them like the
followings:
1. The intra-domain routing within the AIRA-Stub-AS1:
(1.1)The "host1" sends the original packet, that tries to open a TCP
connection to "host2," and then reaches "AS1-AR11". Note that, the
original packet is a normal IP packet's (i.e. its "Source Field" is
the EID of the "host1", and its "Destination Field" is the EID of the
"host2");
(1.2)AS1-AR11 makes a LMS (which locates in the AIRA-Stub-AS1) look-
up on "host2". Because of the "host2" dose not belong to the AIRA-
Stub-AS1, the look-up fails;
(1.3)Then, the AS1-AR11 looks up local neighbor table to decide the
local exit address. The "LRIDs of Destination Field" (which is "AS1-
CER11") are added to the packet addressed towards destination EID so
that it can be carried through the stub ASes and forwarded to the
destination and the "AS Number of Destination Field" keeps null
respectively (the packet format is shown in Figure 2);
2. The inter-domain routing between the AIRA-Stub-AS1 and AIRA-
Transit-AS2: "AS1-AR11" directly forwards the normal IP packet to
"BSAR22".
3. The intra-domain routing within the AIRA-Transit-AS2:
(3.1) When "BSAR22" receives a packet without the local AS number, it
looks up the inter-AS routing table (GMS) to decide the next hop AS,
which is only "AIRA-Transit-AS3' GRID";
(3.2) Then, "BSAR22" rewrites the "AS Number of Destination Field"
with the "AIRA-Transit-AS3' GRID";
(3.3) Finally, "BSAR22" looks up its local neighbor table to decide
the local exit address. The "LRIDs of Destination Field" (which is
"BSAR21") are added to the packet addressed towards destination LRID
so that it can be carried through the "AIRA-Transit-AS2" and
forwarded to the destination. The format of packet is given in figure
3;
4. The inter-domain routing between the AIRA-Transit-AS2 and AIRA-
Transit-AS1: "BSAR21" immediately forwards the rewritten packet to
"BSAR11".
Liang Expires May,2011 [Page 12]
Internet-Draft AIRA November 2010
5. The intra-domain routing within the AIRA-Transit-AS1:
(5.1) When "BSAR11" receives the rewritten packet from "BSAR21", it
looks up the inter-AS routing table to decide the next hop AS, which
is only "AIRA-Transit-AS3' GRID.";
(5.2) Then, "BSAR11" looks up the local neighbor table to decide the
local exit address. The "LRIDs of Destination Field" (which is
"BSAR12") are rewritten to the packet addressed towards destination
LRID so that it can be carried through the "AIRA-Transit-AS1" and
forwarded to the destination;
6. The inter-domain routing between the AIRA-Transit-AS1 and AIRA-
Transit-AS3: "BSAR12" first forwards the rewritten packet to
"BSAR31".
7. The intra-domain routing within the AIRA-Transit-AS3:
(7.1) When "BSAR31" receives the rewritten packet from "BSAR12", it
finds that the "AS Number of Destination Field" in the packet is
itself;
(7.2) Then, it looks up the local neighbor table to decide the local
exit address. The "LRIDs of Destination Field" (which is "BSAR33")
are rewritten again to the packet addressed towards destination LRID
so that it can be carried through the "AIRA-Transit-AS3" and then is
forwarded to the destination;
8. The inter-domain routing between the AIRA-Transit-AS3 and AIRA-
Stub-AS3: "BSAR33" directly forwards the rewritten packet to "AS3-
CER31".
9. The intra-domain routing within the AIRA-Stub-AS3:
(9.1) When "AS3-CER31" receives the rewritten packet from "BSAR33",
it finds that the "AS Number of Destination Field" in the packet is
itself;
(9.2) Then, it looks up local neighbor table to decide the local exit
address. The "LRIDs of Destination Field" (which is "AS3-AR32") are
rewritten again to the packet addressed towards destination LRID so
that it can be carried through the "AIRA-Stub-AS3" and forwarded to
the destination;
(9.3) And then, when "AS3-AR32" receives the rewritten packet, it
finds that the "Destination EID" (which is "Host2") locates just
within itself, so that it immediately forwards the rewritten packet
to "Host2". The packet deliver is fulfilled.
Liang Expires May,2011 [Page 13]
Internet-Draft AIRA November 2010
6. Format Considerations
This section portrays formats of packets being used in the AIRA,
which covers both the intra-AS packet format and the inter-AS packet
format.
6.1. Intra-AS Packet Format
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| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LRID of Domain |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number of Destination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Intra-AS Packet Formart
Liang Expires May,2011 [Page 14]
Internet-Draft AIRA November 2010
6.2. Inter-AS Packet Format
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| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LRID of Egress ASBR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number of Destination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Inter-AS Packet Formart
7. Evaluations of the Benefits
This Section evaluates the benefits relevant to AIRA, which involves
in improved scalability, stability and incremental deployment. AIRA
separates RIDs from EIDs and in turn customer networks from provider
ones. As a result, AIRA shares the all benefits of separation and
mapping architectures such as supporting site multi-homing and
traffic engineering, and supporting host multi-homing and mobility.
This section mainly analyzes the other benefits of routing based on
AS number.
7.1. Improved Scalability
AIRA has three kinds of routing protocols: the intra-AS routing
protocol for routing within stub AS, the intra-AS routing protocol
for routing within transit AS, and the inter-AS routing protocol for
inter-AS routing.
The routing table maintains the local reachability information
related to accessing endpoints within stub ASes. The number of
customer networks is about 3*10^4 in Mar. 2010 [10], and the number
of endpoints is about 10^9 [21] in the current Internet. So, the
Liang Expires May,2011 [Page 15]
Internet-Draft AIRA November 2010
average number of endpoints per customer network is about 3.3*10^4.
The number of routing table items is about 3.3*10^4. For the current
router, it is desirable. It is obvious that AIRA improves the
scalability of interior routers within stub ASes.
The routing table maintains the local routing information within
transit AS. The transit AS only stores the reachability information
related to routers within a local AS. The number of routers is small
within most transit ASes. The current number of ISP is about 5*10^3
[10], and the number of routers is about 5*10^5 [22]. The average
number of routers per ISP is about 10^2. It is also obvious that AIRA
improves the scalability of interior routers within transit ASes. For
a large ISP, the intra-AS routing table can contain between 50,000
and 150,000 routes. If the router stores both intra-AS and inter-AS
routing tables, it will have significant impact on the scalability.
The routers in AIRA only store the intra-domain routing table, which
can alleviate scalability pressure on routers in large ISP.
The inter-AS routing table maintains the routing information related
to AS numbers. As a result the number of routing table items is the
number of AS numbers of all transit ASes. If each transit AS has one
AS number, the number of inter-AS routing items is the number of
transit ASes in the Internet. But the multi-homing transit ASes need
more AS numbers for the traffic engineering purpose. The average
number of ISPs is 3. This result shows: (1) the estimated number of
AS numbers in AIAR is comparable to the number of IP prefixes in the
current Internet. From Mar. 2006 to Mar. 2010, the number of IP
prefixes increased from 200,000 to 320,000. (2) the number of AS
number is two orders of magnitude fewer than the size of current IP
prefixes, and is likely to remain more or less constant over time.
In the current Internet, the number of routing table entries is
about3.2*10^5, while the number of transit ASes is about 3*10^4. Even
assuming that every transit AS advertises 3 AS numbers, the routing
table size of AIRA is about 9.3% of the average size of a current
routing table.
7.2. Improved Stability
The ASes are dependent entries in the current Internet, and use BGP
to advertise reachability information of ASes. However, the route
failure in one AS will be flooded in the whole Internet, which
results in instability of inter-domain routing. In addition, there
are many routers and links between routers inside an AS. The topology
changes caused by instable links consume more resource for processing
the route updates related to interior routes. The studies on Tire-1
ISP show that a router with rich links processes hundreds of routing
updates within a minute, the majority of which are caused by the
Liang Expires May,2011 [Page 16]
Internet-Draft AIRA November 2010
interactivity between intra-routers and inter-routers [23]. Some
studies show BGP can churn because of wrong configurations inside an
AS [24], and can persistently loop because of topology changes inside
an AS [25]. The Internet routes today can be overwhelmed due to
frequent routing updates.
ASes is independent entities in AIRA, and BGP only advertises
reachability information of AS numbers without distributing exterior
reachability information within ASes. The routing dynamics occurring
inside ASes will have no impact on the inter-AS routing stability.
Furthermore, one AS is usually connected multiple other ASes by
multiple links for the fault-tolerance purpose. So, when one link
failures, AIRA can deal with the failure by local neighbor table,
instead of triggering routing updates.
7.3. Incremental Deployment
On the Internet, one can not simply set a flag day when all
participators will switch to a new design, no matter how great an
advantage the design offers. Those designs that want to be deployed
should follow an incremental pattern. And incremental deployment
scheme should be backward compatible for communicating with legacy
networks and has incentives so that different participators adopt the
scheme.
The EID and LRID both adopt IPv4 addresses which makes the AIRA is
backward compatible with the current intra-domain routing protocols.
AIRA uses 4-byte AS number for the backward compatibility with the
current inter-domain routing because current BGP can only advertise
IPv4 addresses.
The design of AIRA follows the backward compatibility, but AIRA needs
a mechanism for communicating with legacy networks. AIRA can provide
backward compatibility by ASBR. The IP prefixes of legacy networks
are still advertised throughout the Internet. When a source endpoint
in the new network wants to communicate with a destination endpoint
in legacy network, the source endpoint fills the Source EID and LRID
of ASBR by using its own EID and the exit address respectively. The
Destination EID and AS number of Destination are filled using the
IPv4 address of the destination endpoint. The routers of the Internet
forwards packets without changing the destination addresses until the
packets reach the legacy network. Then, the legacy network forwards
the packets to destination endpoint based on IPv4 address.
When a source endpoint in a legacy network wants to send packets to a
destination endpoint in a new network, the source endpoint fills the
Source and Destination address fields using its own IPv4 address and
the EID of destination endpoint respectively. After forwarding
Liang Expires May,2011 [Page 17]
Internet-Draft AIRA November 2010
packets to a legacy network, the ASBR of the new network replaces the
Destination EID with AS number of the Destination. The routers in the
legacy network normally forward packets. When the ASBRs of new
networks receive a packet from a legacy network, the ASBRs
differentiated processing packets according to the packet format. If
the packet is a normal IPv4 one, the ASBRes add the LRID of ASBR and
AS number of the destination endpoint. If the packet contains the AS
number of the Destination endpoint, the ASBRs replace the Destination
EID with the AS number of the Destination. After rewriting the
addresses, the ASBRs forward packets.
There are currently three kinds of participators: endpoint host, stub
AS and transit AS. AIRA provides incentives for early different
adoptions. AIRA allows host to deploy multi-homing and traffic
engineering. AIRA separates the endpoint identifier from routing
identifier so that the host can both access multiple stub ASes
without changing own identifier and control traffic by the mapping
system. Furthermore, the separation of identity identifier from
routing identifier makes host mobility easier.
The stub AS in AIRA can use Provider-independent addresses, which
eliminates the renumbering problem caused by changing providers, and
thus multi-homing easier. Furthermore, the stub AS can easily
control traffic by mapping system.
The routers inside a transit AS only maintain the local routing
information, which alleviate the scalability pressure due to
processing only the inter-AS routing information. The ASBRs maintain
the routing information related to AS numbers, which is far less than
the IP prefixes in the current Internet. All routers of a transit AS
store less routing information, and process less routing updates than
the routers in the current Internet.
8. Analysis of the Routing Tables Growth
This Section analysis the routing table growth of the AIRA, including
AS growth, multi-homing, traffic engineering, and fragmented
addresses. The rapid growth of inter-domain routing table size is
mainly resulted in the increasing number of ASes, multi-homing,
traffic engineering, and fragment addresses [18]. If the growth of AS
numbers exceeds the growth of IP prefixes, the AIRA will be not scale.
We will analysis the impact of the main factors that cause the rapid
growth of IP prefix on the routing table size of AIRA.
8.1. AS Growth
As more networks connected to the Internet, more AS numbers will be
assigned to identify these networks accordingly. If the number of AS
Liang Expires May,2011 [Page 18]
Internet-Draft AIRA November 2010
number grows, the inter-AS routing table will grows accordingly. With
the development of the Internet the growth of AS number will be
inevitable. We use the data from Route Views Project [11] between
2007 and 2009 to evaluate the growth of AS number and IP prefix in
the future. Table 1 below shows the increasing rate of AS numbers and
IP prefixes in the recent three years respectively.
Table1: Increasing rate of IP prefixes and transit ASes
+----+------+---------+----------+
|Year|Iterms|IP Prefix|Transit AS|
+----+------+---------+----------+
| | Jan. | 216,190 | 3,794 |
| |------|---------|----------|
|2007| Dec. | 244,886 | 4,282 |
| |------|---------|----------|
| | Rate | 13.3% | 12.9% |
+----+------+---------+----------+
| | Jan. | 247,204 | 4,271 |
| |------|--------------------+
|2008| Dec. | 284,795 | 4,685 |
| |------|--------------------+
| | Rate | 15.2% | 9.70% |
+----+------+---------+----------+
| | Jan. | 289,185 | 4,732 |
| |------|--------------------+
|2009| Dec. | 312,244 | 5,126 |
| |------|---------|----------|
| | Rate | 8.0% | 8.3% |
+----+------+---------+----------+
The results show the number of transit ASes is two orders of
magnitude fewer than the number of IP prefixes in current Internet.
The number of transit ASes are 1.75%, 1.65% and 1.64% of the number
of IP prefixes respectively. Even every multi-homing transit AS
advertises 3 AS numbers, the average size of AIRA's routing table is
less than the current BGP routing table size by 6%.
Assuming the increasing rate of transit ASes is denoted by lambda,
the number of transit ASes in Dec. 2009 is denoted by k, and the
number of transit ASes in year N is denoted by S_T , we have:
S_T = k*(lambda+1)^(N-2009)
Assuming the increasing rate of IP prefixes is denoted by mu, the
number of IP prefixes in Dec. 2009 is denoted by s, and the number of
IP prefixes in year N denoted by S_IP , we have:
Liang Expires May,2011 [Page 19]
Internet-Draft AIRA November 2010
S_IP = s*(mu+1)^(N-2009)
Let k be 5,126 and s 312,244 in Dec.2009, repectively. During three
years, the average value of lambda is 10.3% and the average value of
mu is 12.12%.
The results show that the number of transit ASes is two orders of
magnitude fewer than the number of IP prefixes in future years. The
number of transit AS is less than the number of IP prefix in current
Internet within the future 50 years.
8.2. Multi-homing and Traffic Engineering
Both transit and stub ASes can support multi-homing and traffic
engineering, which will result in the growth of inter-domain routing
table size in the current Internet. The multi-homing and traffic
engineering of stub ASes has no impact on the inter-AS routing table
size in AIRA. The stub ASes use mapping system for supporting multi-
homing and traffic engineering, avoiding the growth of routing table
size due to multi-homing and traffic engineering of stub ASes.
The multi-homing transit AS does not need additional AS numbers for
multi-homing, but it needs additional AS numbers for traffic
engineering. The inter-AS routing table contains the AS numbers. If
there are multiple routes to a common destination AS, the routing
table needs multiple entries to present the different routes for
traffic engineering.
We analyze the multi-homing of transit AS and stub AS according to
the data from Route Views Project between 2006 and 2008. Table 2
shows the result related to multi-homing percent of transit ASes and
stub ASes, and the average number of upstreaming ISPs of transit ASes
and stub ASes.
Liang Expires May,2011 [Page 20]
Internet-Draft AIRA November 2010
Table2: Percent and average number of ISPs
+----+-------------+-------------+----------+
|Year| Iterms | Transit ASes| Stub ASes|
+----+-------------+-------------+----------+
| | Percent | 74.84 | 56.45 |
|2006|-------------+-------------|----------|
| |Average ISPs | 3.07 | 2.26 |
+----+-------------+-------------+----------+
| | Percent | 75.14 | 55.14 |
|2007|-------------+-------------|----------|
| |Average ISPs | 3.18 | 2.28 |
+----+-------------+-------------+----------+
| | Percent | 76.27 | 54.41 |
|2008|-------------+-------------|----------|
| |Average ISPs | 3.30 | 2.32 |
+----+-------------+-------------+----------+
The results show that about 75% of transit ASes deploy multi-homing,
while 55% of stub ASes deploy multi-homing. For multi-homing ASes,
the number of transit ASes is greater than that of stub ASes.
Furthermore, the average number of ISPs of a transit AS is 3, while
that of ISPs of a stub AS is 2, which shows a transit AS connects
more ISPs than a stub AS.
If a transit AS wants to use multiple distinct paths for traffic
engineering, it must advertise multiple AS numbers, which will cause
the routing table growth. Set the percent of multi-homing transit
ASes be alpha, the average number of upstreaming ISPs be beta, and
the number of AS numbers advertised be S-AS in year N. We have: S-AS
=alpha*beta*k*(lambda+1)^(N-2009)+(1-alpha)*k*(lambda+1)^(N-2009).
If the average number of AS numbers advertised by multi-homing
transit ASes equals the average number of upstreaming ISPs, the
routing table size is one order of magnitude fewer than the number of
IP prefixes in the current Internet. The number of IP prefixes in the
Internet is 312,224 in Dec. 2009. The number of AS numbers in AIRA is
12,815 accounting for traffic engineering, which is 4.1% of the IP
prefixes in the Internet. If AIRA is deployed, the routing table size
will not exceed the routing table size of the current Internet until
2043.
8.3. Fragmented Address
Current ASes can not aggregate multiple fragment addresses, causing
the growth of routing table. Many factors can cause fragment
addresses. If an organization needs additional address space to
Liang Expires May,2011 [Page 21]
Internet-Draft AIRA November 2010
identify its endpoints, the new address space can not be aggregated
with the previous address space, thus resulting in fragment addresses.
When an organization merges with other organization, the two address
spaces of two organizations are commonly not continuous, also
resulting in fragment addresses. The fragment addresses are
advertised in the Internet.
However, the fragment addresses of an AS are aggregated into AS
number in AIRA. FIBs of inter-AS routers map the AS number to next
hops, instead of mapping IP prefixes to next hops. As a result, the
routing table needs an entry in order to forward the packets to an AS
even if the AS has multiple fragment addresses. The intra-routing
table decides how to forward packets within AS. The fragment
addresses do not cause the growth of routing table.
9. Security Considerations
This document does not introduce any security considerations.
10. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
11. Conclusions
A key to separation and mapping architecture is how to select routing
identifier. Aiming at the scalability problem caused by topology
aggregated IP prefixes, this paper proposes an AS-based routing
architecture for improving the scalability of separation and mapping
architecture. The proposed architecture adopts AS number as routing
identifier, and inter-AS routing only contains AS numbers. The
routing table grows with the growth of AS numbers advertised, and the
growth of IP prefixes has no impact on the routing table. The
benefits and scalability of proposed architecture show that the
architecture can effectively alleviate the scalability pressure the
current Internet is facing, and has good scalability in the future.
12. References
12.1. Normative References
[1] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", RFC 4984, September 2007.
Liang Expires May,2011 [Page 22]
Internet-Draft AIRA November 2010
[2] D.Farinacci, V.Fuller, D.Meyer, D.Lewis. Locator/ID Separation
Protocol(LISP)[EB/OL],draft-ietf-lisp-07.txt, 2010.
[3] D.Jen, M.Meisel, D Massey., L.Wang, B.Zhang, L.Zhang. APT: A
Practical Transit Mapping Service [EB/OL], draft-jen-apt-01.txt,
2007.
[4] R.Whittle. Ivip(Internet Vastly Improved Plumbing) Architecture.
Internet Draft, draft-whittle-ivip-arch-04, Mar.2010.
[5] Juan Jose Adan. Tunneled Inter-doamin Routing(TIDR). Internet
Draft, draft-adan-idr-tidr-01, Nov. 2006.
[6] R.Atkinson. ILNP Concept of Operations. Internet Draft, Draft-
rja-ilnp-intro-03.txt, Feb. 2010.
[7] R.Moskowitz, P.Nikander. Host Identify Protocol(HIP)
Architecture. RFC 4423, May 2006.
[8] X.Xu. Routing Architecture for the Next Generation Internet
(RANGI), Internet Draft, draft-xu-rangi-03, Feb. 2010.
[9] D.Jen, M.meisel, H.Yan, D.massey, L.wang. Towards a Future
Internet Architecture: Arguments for Separating Edges from
Transit Core. in 7 ACM Workshop on Hot Topics in Networks
(HotNets), Cal.gary, Alberta, Canada, Oct.2008.
[10] The RouteViews Project [EB/OL]. http://www.routeviews.org/.
[11] The CAIDA AS Relationships Dataset [EB/OL]. <2004.03-2008.03>.
http://www. caida.org/data/active/as-relationships/.
[12] Potaroo. The 32-bit AS number report, 2008.
http://www.potaroo.net/tools/asn32/index.html.
[13] R.Oliveira, M.Lad, B.Zhang, L.Zhang. Geographically Informed
Inter-Domain Routing[A]. In: IEEE International Conference on
Network Protocols 2007 (ICNP2007) [C], Beijing, China, 2007:
103-112.
[14] S.Deering. Metro-based Addressing: A Proposed Addressing Scheme
for the IPv6. Presentation, Xerox PARC, July, 1995.
[15] T.Hain. An IPv6 Provider-Independent Global Unicast Address
Format [EB/OL]. draft-hain-ipv6-pi-addr-10.txt, Aug.2006.
Liang Expires May,2011 [Page 23]
Internet-Draft AIRA November 2010
[16] L.Subramanian, M.Caesar, C.T.Ee, M.handley, M.Mao, S.Shenker,
I.Stoica. HLP: A Next Generation Inter-domain Routing Protocol
[A]. In ACM SIGCOMM[C], Philadelphia, Pennsylvania, USA, 2005:
13-24.
[17] X.Xu, D.Guo. Hierarchical Routing Architecture (HRA) [EB/OL],
draft-xu-rrg-hra-00.txt, Feb.2008.
[18] Preliminary Recommendation for a Routing Architecture. draft-
irtf-rrg-recommendation-02. 2009.03
12.2. Informative References
[19] L.Mathy, L.Iannone. LISP-DHT: Towards a DHT to map Identifiers
onto Locators, In ACM ReArch, Madrid, Spain, 2008.
[20] H.Luo, Y.Qin, H.Zhang. A DHT-based Identifier-to-Locator
Mapping Approach for a Scalable Internet. IEEE Transaction on
Parallel and Distribution Systems. Vol.20, No.10.2009.
[21] Internet System Consortium. The ISC Domain Survey.
http://isc.org/solutions/survey, 2009.
[22] Lumeta. Internet Map Project.
http://www.lumeta.com/internetmapping/.
[23] R.Teixeira, A.Shaikh,T.Griffin, J.Rexford. Dynamics of hot-
potato routing in IP networks. In Proc. of ACM SIGMETRICS`04,
2004.
[24] T. G .Griffin, G. Wilfong. On the correctness of IBGP
Configuration. In Proc. ACM SIGCOMM, 2002.
[25] R.DuBE, A comparison of scaling techniques for BGP. ACM
Computer Communications Review 29 ,3(July 1999):44-46.
13. Acknowledgments
Funding for the RFC Editor function is currently provided by the
Internet Society.
Liang Expires May,2011 [Page 24]
Internet-Draft AIRA November 2010
Authors' Addresses
Weifang Liang
National Digital Switching System Engineering and Technological R&D
Center of China
No. 5, Jianxue Street, Zhengzhou, HeNan 450002, P. R. China
Phone: +8637181632830
Email: lwf@ndsc.com.cn
Yue Zhang
Zhengzhou University, School of Information & Engineering
No.100, Science Avenue, ZhengZhou, HeNan 450052, P. R. China
Phone: +8637167767757
Email: ieyzhang@zzu.edu.cn
Dongnian Cheng
National Digital Switching System Engineering and Technological R&D
Center of China
No. 5, Jianxue Street, Zhengzhou, HeNan 450002, P. R. China
Phone: +8637181632743
Email: cdn@ndsc.com.cn
Liang Expires May,2011 [Page 25]
| PAFTECH AB 2003-2026 | 2026-04-24 09:08:08 |