Network Working Group R. Gu Internet-Draft J. Dong Intended status: Standards Track Huawei Technologies Expires: January 2, 2012 Z. Liu China Telecom July 1, 2011 Using BGP for Virtual Private LAN Service (VPLS) Signaling draft-gu-l2vpn-vpls-bgp-signaling-00 Abstract This document specifies a new BGP based signaling mechanism for providing Virtual Private LAN Service (VPLS) in large scale and multi-service networks. This new mechanism combines the advantage of both the existing BGP based [RFC4761] and LDP based [RFC4762] VPLS mechanism. Requirements Language 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]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 2, 2012. Copyright Notice Copyright (c) 2011 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 Gu, et al. Expires January 2, 2012 [Page 1] Internet-Draft BGP Signaling for VPLS July 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of Existing VPLS signaling . . . . . . . . . . . . . 3 2.1. Features of Existing BGP based VPLS . . . . . . . . . . . 3 2.2. Features of Existing LDP based VPLS . . . . . . . . . . . 4 3. BGP Encodings . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. VPLS PW NLRI . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. New BGP Attributes for VPLS . . . . . . . . . . . . . . . 6 3.2.1. Label Attribute . . . . . . . . . . . . . . . . . . . 6 3.2.2. Status Attribute . . . . . . . . . . . . . . . . . . . 6 3.2.3. Interface Parameter Attribute . . . . . . . . . . . . 7 3.2.4. Grouping Attribute . . . . . . . . . . . . . . . . . . 7 3.2.5. MAC List Attribute . . . . . . . . . . . . . . . . . . 8 4. Proposed BGP VPLS Solution . . . . . . . . . . . . . . . . . . 8 4.1. Auto-Discovery . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. PW Set Up and Tear Down Signaling . . . . . . . . . . 9 4.2.2. PW Status Signaling . . . . . . . . . . . . . . . . . 10 4.2.3. MAC Address Withdrawal . . . . . . . . . . . . . . . . 11 4.3. Operations for Better Scalability . . . . . . . . . . . . 11 4.3.1. Distribution of VPLS Signaling Message . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Gu, et al. Expires January 2, 2012 [Page 2] Internet-Draft BGP Signaling for VPLS July 2011 1. Introduction Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service, is a Layer 2 Service that emulates LAN service across a Wide Area Network (WAN) [RFC4664]. The primary motivation behind Virtual Private LAN Services (VPLS) is to provide connectivity between geographically dispersed customer sites across the service provider network, as if they were connected using a LAN. In the trend of network convergence, service providers may need to deploy both VPLS and other services, i.e. L3VPN [RFC4364] in the same network, and they may need to deploy VPLS in larger scale networks. In response to such requirements, a scalable and architecture converged VPLS mechanism is needed. Currently there are two kinds of signaling approaches for VPLS: BGP based [RFC4761] and LDP based [RFC4762], both of them have some disadvantages in meeting the requirements. This document describes a new BGP based signaling mechanism for providing Virtual Private LAN Service (VPLS) and relevant BGP encodings and procedures. This new solution combines the advantage of both the existing BGP based and LDP based VPLS mechanisms. 2. Overview of Existing VPLS signaling Though there are two existing mechanisms to deploy VPLS, both of them have some disadvantages in meeting the requirement of deploying VPLS in large scale and multiservice networks. 2.1. Features of Existing BGP based VPLS [RFC4761] describes the BGP based auto-discovery and signaling mechanism for VPLS. The mechanism combines VPLS membership auto- discovery and signaling into a single BGP Update advertisement. Each PE advertises Update message that contains the same label blocks to all the other PEs, and each receiving PE infers the label intended by adding its (unique) VE ID to the label base. Route Target carried in the Update message is used to identify VPLS instance. The advantage of existing BGP VPLS is both the membership auto- discovery and signaling use the same protocol, which makes the VPLS control plane simpler and converged with services like L3VPN. Besides, the use of Route Reflection (RR) could avoid the full mesh of VPLS signaling sessions. However, there are some issues of this approach which may affect the Gu, et al. Expires January 2, 2012 [Page 3] Internet-Draft BGP Signaling for VPLS July 2011 deployment of this mechanism in larger networks : a. The use of label block is based on idea of "allocate in advance" and "over-provisioning", thus the utilization of label resources is not quite efficient compared with on-demand label allocation in LDP VPLS [RFC4762]. b. Each PE within a given VPLS needs be assigned a unique VE ID, arranging this VE ID space introduces extra management burden for operators, especially in multi-AS scenarios. Besides, the value of local VE ID would impact label block allocation of remote PEs, which makes the management more complicated and also may impact efficiency of label resource utilization. 2.2. Features of Existing LDP based VPLS [RFC4762] describes the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP). In LDP signaling, the PW labels are allocated "on-demand" for remote PEs in each VPLS instance, thus the utilization of label resource is quite efficient. LDP itself does not provide mechanism for membership auto-discovery. Thus by default the identities of all the other pseudowire endpoints need to be manually configured on local PE for each VPLS instance, which is configuration intensive and error-prone since the LDP sessions are normally fully meshed. Although BGP-based auto-discovery in [RFC6074] can be jointly used with LDP signaling, it is still required to set up fully meshed targeted LDP sessions among PEs participating in the given VPLS, thus overhead of maintaining full-mesh LDP sessions may become an issue in large scale networks. Besides, membership discovery and signaling procedures are provided by BGP and LDP respectively, which means operators need to deploy BGP and targeted LDP simultaneously for providing VPLS services in their networks. This would increase the complexity in provisioning and trouble shooting. For service providers who have already deployed L3VPN service in their networks and want to deploy VPLS in the same network, they may prefer to deploy VPLS using the similar technology as L3VPN to simplify network operation and maintenance. LDP based VPLS can not meet this requirement. Gu, et al. Expires January 2, 2012 [Page 4] Internet-Draft BGP Signaling for VPLS July 2011 3. BGP Encodings This section describes BGP extensions for the proposed VPLS signaling mechanism. 3.1. VPLS PW NLRI A new BGP NLRI called "VPLS PW NLRI" is defined for VPLS PW signaling. AFI of L2VPN (25) is used, and a new SAFI is to be assigned. Format of the new NLRI is as below. +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | VPLS ID Type (1 octet) | +-----------------------------------+ | VPLS ID (Variable) | +-----------------------------------+ |Local PE Address Length (1 octet) | +-----------------------------------+ |Local PE Address (Variable) | +-----------------------------------+ |Remote PE Address Length (1 octet) | +-----------------------------------+ |Remote PE Address (Variable) | +-----------------------------------+ Figure 1: VPLS PW NLRI The RD field is encoded as described in [RFC4364]. The VPLS ID Type field and VPLS ID field are used to uniquely identify a specific VPLS instance. This document defines three VPLS ID Types: + 0 - Reserved; + 1 - Encoded as a 32-bit identifier; + 2 - Encoded as an 8-byte BGP Extended Community. The Local PE Address field and Remote PE Address field contains a local PE's IP address and remote PE's IP Address respectively. They are used to identify the two PEs between which a PW needs to be set up. Note that the PE address here is used solely to provide a unique identifier. If the PE Address field carries an IPv4 address, the value of the PE Address Length field is 32. If the PE Address field carries an IPv6 address, then the value of the PE Address Length Gu, et al. Expires January 2, 2012 [Page 5] Internet-Draft BGP Signaling for VPLS July 2011 field is 128. 3.2. New BGP Attributes for VPLS 3.2.1. Label Attribute Label Attribute is an optional transitive BGP attribute with the length of 4 octets. It contains an MPLS label encoded as 3 octets, where the high-order 20 bits contain the label value. Absence of MPLS Label is indicated by setting the MPLS Label field to zero. The Reserved field is reserved for future use. It MUST be set to zero on transmission and MUST be ignored on receipt. +-----------------------------------+ | Reserved (1 octet) | +-----------------------------------+ | MPLS Label (3 octets) | +-----------------------------------+ Figure 2: Label Attribute This MPLS label is used as pseudowire demultiplexor for the PW between the two PEs identified in the VPLS PW NLRI. In this way, the PW label is allocated explicitly for each PW, thus the label resource would be utilized efficiently. 3.2.2. Status Attribute Status Attribute defined in this document can be used by a PE device to indicate pseudowire status to its remote PEs. This attribute contains more information than the alternative simple MP_UNREACH_NLRI. It is an optional transitive BGP attribute. The format of this attribute is defined as follows: +-----------------------------------+ | Reserved (1 octet) | +-----------------------------------+ | Status Code (4 octets) | +-----------------------------------+ Figure 3: Status Attribute The Reserved field is reserved for future use. It MUST be set to zero on transmission and MUST be ignored on receipt. The Status Code field is a 4-octet bit field as specified in the PW Gu, et al. Expires January 2, 2012 [Page 6] Internet-Draft BGP Signaling for VPLS July 2011 IANA Allocations document [RFC4446]. Each bit in the status code field can be set individually to indicate more than a single failure at once. Each fault can be cleared by sending an Update message for the particular PW in which the respective bit is cleared. Usage of Status Attribute is described in Section 4.2.2. 3.2.3. Interface Parameter Attribute Interface Parameter Attribute defined in this document contains a set of interface-specific parameters. It is an optional transitive BGP attribute. The format of this attribute is defined as follows: +-----------------------------------+ | Reserved (1 octet) | +-----------------------------------+ | Sub-TLV Type (1 octet) | +-----------------------------------+ | Sub-TLV Length (1 octet) | +-----------------------------------+ | Sub-TLV Value (Variable) | +-----------------------------------+ | ... | +-----------------------------------+ | Sub-TLV Type (1 octet) | +-----------------------------------+ | Sub-TLV Length (1 octet) | +-----------------------------------+ | Sub-TLV Value (Variable) | +-----------------------------------+ Figure 4: Interface Parameter Attribute The Reserved field is reserved for future use. It MUST be set to zero on transmission and MUST be ignored on receipt. Each tuple contains particular interface- specific parameters. The allocation and usage of particular interface-specific parameter can refer to [RFC4446]. This document does not define any new interface-specific parameters. The definition of other interface- specific parameters is left for further study. 3.2.4. Grouping Attribute Grouping Attribute defined in this document is an optional transitive BGP attribute. The format of this attribute is defined as follows: Gu, et al. Expires January 2, 2012 [Page 7] Internet-Draft BGP Signaling for VPLS July 2011 +-----------------------------------+ | Reserved (1 octet) | +-----------------------------------+ | PW Grouping ID (4 octets) | +-----------------------------------+ Figure 5: Grouping Attribute The Reserved field is reserved for future use. It MUST be set to zero on transmission and MUST be ignored on receipt. The PW Grouping ID is an arbitrary 32-bit value that represents an arbitrary group of PWs. Detailed specification of use of the Grouping Attribute is outside the scope of this document. 3.2.5. MAC List Attribute MAC List Attribute is an optional transitive BGP attribute. The format of this attribute is defined as follows: +-----------------------------------+ | Reserved (1 octet) | +-----------------------------------+ | MAC address #1 (6 octets) | +-----------------------------------+ | MAC address #2 (6 octets) | +-----------------------------------+ ~ ... ~ +-----------------------------------+ | MAC address #n (6 octets) | +-----------------------------------+ Figure 6: MAC List Attribute The Reserved field is reserved for future use. It MUST be set to zero on transmission and MUST be ignored on receipt. The MAC Addresses listed in this attribute are the MAC addresses being removed. 4. Proposed BGP VPLS Solution This section describes a solution which uses BGP to set up VPLS services. Unlike the mechanism in [RFC4761], the procedures of "membership auto-discovery" and "signaling" are divided into two separate steps. Gu, et al. Expires January 2, 2012 [Page 8] Internet-Draft BGP Signaling for VPLS July 2011 4.1. Auto-Discovery The auto-discovery procedures defined in Section 3.2.2 of [RFC6074] is used for VPLS membership auto-discovery. Thus the BGP advertisement for a particular VSI at a given PE will contain: o an NLRI of AFI = L2VPN, SAFI = VPLS, encoded as RD:PE_addr o a BGP next hop equal to the loopback address of the PE o an Extended Community Attribute containing the VPLS ID o an Extended Community Attribute containing one or more RTs. For more details about BGP VPLS auto-discovery please refer to [RFC6074]. 4.2. Signaling Once discovery is finished, each pair of PEs in a VPLS must be able to establish pseudowires to each other, this process is known as signaling. Signaling is also used to exchange certain characteristics of the pseudowires that a PE sets up to remote PEs. This document defines a new BGP NLRI, called VPLS PW NLRI, for signaling and maintenance of pseudowires that constitute a VPLS instance. This document also specifies a set of new BGP attributes for VPLS signaling and maintenance, e.g. Label attribute, Status attribute, Interface Parameter attribute, Grouping attribute, and MAC List attribute. 4.2.1. PW Set Up and Tear Down Signaling After the auto-discovery phase finished, PE X knows other PEs of the same VPLS by matching the RTs carried in the received auto-discovery routes with the import RTs configured for local VSIs, and identifying the VPLS-ID carried in the auto-discovery route. Once PE X discovers that a remote PE (Y) is in the same VPLS, it SHOULD advertise a BGP update message with VPLS PW NLRI to set up the PW between PE X and PE Y. The BGP Update message is constructed as follows: - The RD in this NLRI is set to the RD of the given VPLS's VSI. - The VPLS ID Type field may be set to a particular value according to the local configuration. The VPLS ID field is encoded according to the local configuration. Moreover, value of VPLS ID field carried in the BGP VPLS Signaling route MUST be the same as those carried in the Gu, et al. Expires January 2, 2012 [Page 9] Internet-Draft BGP Signaling for VPLS July 2011 corresponding BGP VPLS auto-discovery route. - The Local PE Address field MUST be set with the same IP address as the one carried in PE Address field of the BGP VPLS Auto-Discovery route advertised before. The Remote PE Address MUST be set with IP Address as the one carried in the PE Address field of the received BGP VPLS auto-discovery route. The BGP Update message SHOULD also carries following attributes: - The same set of Route Target Extended Communities as those carried in the corresponding BGP VPLS auto-discovery route. - The BGP Update message MUST carry a Label Attribute. The label carried in Label Attribute will be used as the pseudowire demultiplexor. - The BGP Update message MUST carry a Layer 2 Info Extended Community [RFC4761]. The value of each field is determined by local configuration. - The BGP Update message MAY carry an Interface Parameter Attribute. The value of each field is specified by local configuration. Likewise, the remote PE Y SHOULD also initiate the signaling for the PW between PE X and PE Y. If one PE is configured no longer a member of specific VPLS, it SHOULD withdraw the auto-discovery NLRI for the VPLS. Moreover, it SHOULD also withdraw the VPLS PW NLRIs it has advertised for this VPLS. On receipt of the withdrawals, the remote PEs SHOULD tear down the PWs with this PE by sending withdrawals of corresponding NLRIs using MP_UNREACH_NLRI attribute. 4.2.2. PW Status Signaling The Status Attribute is used to indicate status information to remote PEs. The definition and usage of particular Status Code can refer to [RFC4446]. This document does not define any new Status Code. Definition of new Status Codes is left for further study. When a PE advertises BGP VPLS Signaling routes to its peers in response to the received BGP VPLS Auto-Discovery route, a PW Status Attribute MUST be carried in the BGP Update message. When status of particular PW changes, a new BGP Update message corresponding to this PW SHOULD be sent to inform the remote PE of this change. Gu, et al. Expires January 2, 2012 [Page 10] Internet-Draft BGP Signaling for VPLS July 2011 4.2.3. MAC Address Withdrawal It MAY be desirable to remove or unlearn MAC addresses that have been dynamically learned for faster convergence. This is accomplished by sending a BGP Update message with MAC List Attribute which containing the list of MAC addresses to be removed. The VPLS ID, Local PE Address and Remote PE Address fields carried in VPLS PW NLRI can be used to identify the VPLS instance and the associated pseudowire. The processing of received in a BGP Update message with a MAC List Attribute is: For each MAC address listed in the Attribute: - Remove the association between the MAC address and the AC or PW. For a MAC List Attribute with empty list: - Remove all the MAC addresses associated with the VPLS instance except the MAC addresses learned over the PW identified by the NLRI field of the message. When the MAC Address Withdrawal attribute contains a large number of MAC addresses, it may be preferable to send a message with an empty list. 4.3. Operations for Better Scalability As discussed in [RFC4761], there are at least three aspects of scaling the VPLS control plane when using BGP: 1. alleviating the full mesh connectivity requirement among VPLS BGP speakers; 2. limiting BGP VPLS message passing to just the interested speakers rather than all BGP speakers; and 3. simplifying the addition and deletion of BGP speakers, whether for VPLS or other applications. The use of BGP route reflectors [RFC4456] can solve problems 1 and 3 above well. With regard to problem 2, [RFC4761] addresses this question by the use of RT-Constrain [RFC4684]. Besides this, the use of Outbound Route Filtering (ORF) ([RFC5291]) can also help in alleviating the control plane overhead. The following section describes the mechanism used in this document to solve problem 2. Gu, et al. Expires January 2, 2012 [Page 11] Internet-Draft BGP Signaling for VPLS July 2011 4.3.1. Distribution of VPLS Signaling Message Using the signaling mechanism in this document, the BGP signaling message contains information of only one PW connectivity, thus this information only need be propagated to the remote end point of this PW. This section describes the mechanism for controlling distribution of VPLS signaling messages. After the auto-discovery phase specified in section 4.1, VPLS remote endpoint information has been propagated throughout the network. Each BGP (VPLS) speaker, including PEs, RRs and ASBRs, can use the received PW endpoint information to form a "VPLS Route Distribution Information Base". Entries in the "VPLS Route Information Base" may have the format as below: The VPLS ID and Advertising PE field identify a VPLS PW endpoint of the corresponding auto-discovery route. The Receiving Neighbor identifies the BGP neighbor from which this VPLS auto-discovery route is received. Consequently, specific VPLS Signaling routes MAY only be sent to the corresponding advertising Neighbor. This is achieved by identifying the Remote PE Address in the VPLS PW NLRI of the message, and only advertises this message to the Receiving Neighbors of the corresponding entry in the "VPLS Route Distribution Information Base". Using this advertisement rule, the BGP VPLS signaling routes will only be sent to relevant speakers, rather than be flooded to all BGP speakers in the network. 5. IANA Considerations IANA is requested to make the following allocations from registries under its control. This document defines a new NLRI, VPLS PW NLRI for BGP VPLS signaling. A new SAFI value needs be assigned. SAFI Name Value --------------------------- VPLS PW NLRI TBA This document specifies a series of new BGP attributes, new BGP Attribute Types need be assigned for these BGP attributes: Gu, et al. Expires January 2, 2012 [Page 12] Internet-Draft BGP Signaling for VPLS July 2011 Attribute Name Type ---------------------------------------- Label attribute TBA Status attribute TBA Interface Parameter attribute TBA Grouping attribute TBA MAC List attribute TBA 6. Contributors The following individuals contributed to this document: Mach Chen mach.chen@huawei.com Qing Zeng zengqing@huawei.com 7. Security Considerations This document does not change the security properties of BGP based VPLS. 8. Acknowledgements The authors would like to thank ... for their valuable suggestions and comments to this document. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, Gu, et al. Expires January 2, 2012 [Page 13] Internet-Draft BGP Signaling for VPLS July 2011 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011. 9.2. Informative References [I-D.kompella-l2vpn-l2vpn] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling", draft-kompella-l2vpn-l2vpn-06 (work in progress), June 2011. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006. [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006. [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, August 2008. Gu, et al. Expires January 2, 2012 [Page 14] Internet-Draft BGP Signaling for VPLS July 2011 Authors' Addresses Rui Gu Huawei Technologies Huawei Building, No.3 Xinxi Rd Beijing 100085 China Email: gurui@huawei.com Jie Dong Huawei Technologies Huawei Building, No.3 Xinxi Rd Beijing 100085 China Email: jie.dong@huawei.com Zhihua Liu China Telecom 109 Zhongshan Ave. Guangzhou 510630 China Email: zhliu@gsta.com Gu, et al. Expires January 2, 2012 [Page 15]