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]