CCAMP Working Group S. Belotti Internet-Draft P. Grandi Intended status: Informational Alcatel-Lucent Expires: April 21, 2011 D. Ceccarelli D. Caviglia Ericsson F. Zhang D. Li Huawei Technologies October 18, 2010 Information model for G.709 Optical Transport Networks (OTN) draft-bccg-ccamp-otn-g709-info-model-03 Abstract The recent revision of ITU-T recommendation G.709 [G.709-v3] has introduced new fixed and flexible ODU containers in Optical Transport Networks (OTNs), enabling optimized support for an increasingly abundant service mix. This document provides a model of information needed by the routing and signaling process in OTNs to support Generalized Multiprotocol Label Switching (GMPLS) control of all currently defined ODU containers. 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 April 21, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Belotti, et al. Expires April 21, 2011 [Page 1] Internet-Draft Information model for G.709 OTN October 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. OSPF-TE requirements overview . . . . . . . . . . . . . . . . 4 3. RSVP-TE requirements overview . . . . . . . . . . . . . . . . 5 4. G.709 Digital Layer Info Model for Routing and Signaling . . . 5 4.1. Tributary Slot type . . . . . . . . . . . . . . . . . . . 8 4.1.1. Tributary Slot type and Forwarding Adjacencies . . . . 8 4.2. Tributary Port Number . . . . . . . . . . . . . . . . . . 9 4.3. Signal type . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Bit rate and tolerance . . . . . . . . . . . . . . . . . . 11 4.5. Unreserved Resources . . . . . . . . . . . . . . . . . . . 11 4.6. Maximum LSP Bandwidth . . . . . . . . . . . . . . . . . . 11 4.7. Distinction between terminating and switching capability . . . . . . . . . . . . . . . . . . . . . . . . 12 4.8. Priority Support . . . . . . . . . . . . . . . . . . . . . 13 4.9. Multi-stage multiplexing . . . . . . . . . . . . . . . . . 13 4.10. Generalized Label . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Belotti, et al. Expires April 21, 2011 [Page 2] Internet-Draft Information model for G.709 OTN October 2010 1. Introduction GMPLS[RFC3945] extends MPLS to include Layer-2 Switching (L2SC), Time-Division Multiplexing (e.g., SONET/SDH, PDH, and OTN), Wavelength (OCh, Lambdas) Switching and Spatial Switching (e.g., incoming port or fiber to outgoing port or fiber). The establishment of LSPs that span only interfaces recognizing packet/cell boundaries is defined in [RFC3036, RFC3212, RFC3209]. [RFC3471] presents a functional description of the extensions to Multi-Protocol Label Switching (MPLS) signaling required to support GMPLS. ReSource reserVation Protocol-Traffic Engineering (RSVP-TE) -specific formats,mechanisms and technology specific details are defined in [RFC3473]. From a routing perspective, Open Shortest Path First-Traffic Engineering (OSPF-TE) generates Link State Advertisements (LSAs) carrying application-specific information and floods them to other nodes as defined in [RFC5250]. Three types of opaque LSA are defined, i.e. type 9 - link-local flooding scope, type 10 - area- local flooding scope, type 11 - AS flooding scope. Type 10 LSAs are composed of a standard LSA header and a payload including one top-level TLV and possible several nested sub-TLVs. [RFC3630] defines two top-level TLVs: Router Address TLV and Link TLV; and nine possible sub-TLVs for the Link TLV, used to carry link related TE information. The Link type sub-TLVs are enhanced by [RFC4203] in order to support GMPLS networks and related specific link information. In GMPLS networks each node generates TE LSAs to advertise its TE information and capabilities (link-specific or node- specific)through the network. The TE information carried in the LSAs are collected by the other nodes of the network and stored into their local Traffic Engineering Databases (TED). In a GMPLS enabled G.709 Optical Transport Networks (OTN), routing and signaling are fundamental in order to allow automatic calculation and establishment of routes for ODUk LSPs. The recent revision of ITU-T Recommendation G.709 [G709-V3] has introduced new fixed and flexible ODU containers that augment those specified in foundation OTN. As a result, it is necessary to provide OSPF-TE and RSVP-TE extensions to allow GMPLS control of all currently defined ODU containers. This document provides the information model needed by the routing and signaling processses in OTNs to allow GMPLS control of all currently defined ODU containers. OSPF-TE and RSVP-tE requirements are defined in [OTN-FWK], while Belotti, et al. Expires April 21, 2011 [Page 3] Internet-Draft Information model for G.709 OTN October 2010 protocol extensions are defined in [OTN-OSPF] and [OTN-RSVP]. 1.1. Terminology 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 [RFC2119]. 2. OSPF-TE requirements overview [OTN-FWK] provides a set of functional routing requirements summarized below : - Support for link multiplexing capability advertisement: The routing protocol has to be able to carry information regarding the capability of an OTU link to support different type of ODUs - Support for TS granularity advertisement: Each ODUj can be multiplexed into an OTUk using different TS granularities. For example, ODU1 can be multiplexed into ODU2 with either 2.5Gbps TS granularity or 1.25G TS granularity. The routing protocol should be capable of carrying the TS granularity supported by the ODU interface. - Support of any ODUk and ODUflex: The routing protocol must be capable of carrying the required link bandwidth information for performing accurate route computation for any of the fixed rate ODUs as well as ODUflex. - Support for differentiation between switching and terminating capacity - Support different priorities for resource reservation. How many priorities levels should be supported depends on operator policies. Therefore, the routing protocol should be capable of supporting either no priorities or up to 8 priority levels as defined in [RFC4202]. - Support link bundling either at the same line rate or different line rates (e.g. 40G and 10G). Bundling links at different rates makes the control plane more scalable and permits better networking flexibility. Belotti, et al. Expires April 21, 2011 [Page 4] Internet-Draft Information model for G.709 OTN October 2010 3. RSVP-TE requirements overview [OTN-FWK] also provides a set of functional signaling requirements summarized below : - Support for LSP setup of new ODUk/ODUflex containers with related mapping and multiplexing capabilities - Support for LSP setup using different Tributary Slot granularity - Support for Tributary Port Number allocation and negoziation - Support for constraint signaling 4. G.709 Digital Layer Info Model for Routing and Signaling The digital OTN layered structure is comprised of digital path layer networks (ODU) and digital section layer networks (OTU). An OTU section layer supports one ODU path layer as client and provides monitoring capability for the OCh. An ODU path layer may transport a heterogeneous assembly of ODU clients. Some types of ODUs (i.e., ODU1, ODU2, ODU3, ODU4) may assume either a client or server role within the context of a particular networking domain. ITU-T G.872 amendment 2 provides two tables defining mapping and multiplexing capabilities of OTNs, which are reproduced below. Belotti, et al. Expires April 21, 2011 [Page 5] Internet-Draft Information model for G.709 OTN October 2010 +--------------------+--------------------+ | ODU client | OTU server | +--------------------+--------------------+ | ODU 0 | - | +--------------------+--------------------+ | ODU 1 | OTU 1 | +--------------------+--------------------+ | ODU 2 | OTU 2 | +--------------------+--------------------+ | ODU 2e | - | +--------------------+--------------------+ | ODU 3 | OTU 3 | +--------------------+--------------------+ | ODU 4 | OTU 4 | +--------------------+--------------------+ | ODU flex | - | +--------------------+--------------------+ Figure 1: OTN mapping capability Belotti, et al. Expires April 21, 2011 [Page 6] Internet-Draft Information model for G.709 OTN October 2010 +=================================+=========================+ | ODU client | ODU server | +---------------------------------+-------------------------+ | 1,25 Gbps client | | +---------------------------------+ ODU 0 | | - | | +=================================+=========================+ | 2,5 Gbps client | | +---------------------------------+ ODU 1 | | ODU 0 | | +=================================+=========================+ | 10 Gbps client | | +---------------------------------+ ODU 2 | | ODU0,ODU1,ODUflex | | +=================================+=========================+ | 10,3125 Gbps client | | +---------------------------------+ ODU 2e | | - | | +=================================+=========================+ | 40 Gbps client | | +---------------------------------+ ODU 3 | | ODU0,ODU1,ODU2,ODU2e,ODUflex | | +=================================+=========================+ | 100 Gbps client | | +---------------------------------+ ODU 4 | |ODU0,ODU1,ODU2,ODU2e,ODU3,ODUflex| | +=================================+=========================+ Figure 2: OTN multiplexing capability How an ODUk connection service is transported within an operator network is governed by operator policy. For example, the ODUk connection service might be transported over an ODUk path over an OTUk section, with the path and section being at the same rate as that of the connection service (see Table 1). In this case, an entire lambda of capacity is consumed in transporting the ODUk connection service. On the other hand, the operator might exploit different multiplexing capabilities in the network to improve infrastructure efficiencies within any given networking domain. In this case, ODUk multiplexing may be performed prior to transport over various rate ODU servers (as per Table 2) over associated OTU sections. From the perspective of multiplexing relationships, a given ODUk may play different roles as it traverses various networking domains. Belotti, et al. Expires April 21, 2011 [Page 7] Internet-Draft Information model for G.709 OTN October 2010 As detailed in [OTN-FWK], client ODUk connection services can be transported over: o Case A) one or more wavelength sub-networks connected by optical links or o Case B) one or more ODU links (having sub-lambda and/or lambda bandwidth granularity) o Case C) a mix of ODU links and wavelength sub-networks. This document considers the TE information needed for ODU path computation and parameters needed to be signaled for LSP setup. The following sections list and analyze each type of data that needs to be advertised and signaled in order to support path computation and LSP setup. 4.1. Tributary Slot type ITU-T recommendations define two types of TS but each link can only support a single type at a given time. The rules to be followed when selecting the TS to be used are: - If both ends of a link can support both 2.5Gbps TS and 1.25Gbps TS, then the link will work with 1.25Gbps TS. - If one end can support the 1.25Gbps TS, and another end the 2.5Gbps TS, the link will work with 2.5Gbps TS. In case the bandwidth accounting is provided in number of TSs, the type of TS is needed to perform correct routing operations. Currently such information is not provided by the routing protocol and not taken into account during LSP signaling. The tributary slot type information is one of the parameters needed to correctly configure physical interfaces, therefore it has to be signaled via RSVP-TE. 4.1.1. Tributary Slot type and Forwarding Adjacencies TS granularity is a TE link type information and is defined as depicted in Section 4.1. The TS granularity information has to be advertised when setting up a Forwarding Adjacency (FA) by end points of the FA. With reference to Figure3 the FA between node A and D has to be advertised by both nodes A and D. The nodes A and D have to be aware of the TS granularity associated to the interfaces A1 and D1 in order to produce consistent advertisement. Belotti, et al. Expires April 21, 2011 [Page 8] Internet-Draft Information model for G.709 OTN October 2010 In line with what described in [HIER-BIS] RSVP-TE is in charge of providing all the information needed to allow automatic FA setup. As a consequence the TS granularity information will have to be signaled via RSVP-TE. forwarding adjacency ________________________________________ | | +--------+ +--------+ +--------+ +--------+ | | | | | | | | | Node |A1 B1| Node |B2 C1| Node |C2 D1| Node | | A +------+ B +------+ C +------+ D | | | otu3 | | otu3 | | otu3 | | +--------+ 1.25 +--------+ 1.25 +--------+ 2.5 +--------+ Figure 3: FA in mixed TS granularity 4.2. Tributary Port Number [RFC4328] supports only the deprecated auto-MSI mode which assumes that the Tributary Port Number is automatically assigned in the transmit direction and not checked in the receive direction. As described in [G709-V3] and [G798-V3], the OPUk overhead in an OTUk frame contains n (n = the total number of TSs of the ODUk) MSI (Multiplex Structure Identifier) bytes (in the form of multi-frame), each of which is used to indicate the association between tributary port number and tributary slot of the ODUk. The association between TPN and TS has to be configured by the control plane and checked by the data plane on each side of the link. (Please refer to [OTN-FWK] for further details). As a consequence, the RSVP-TE signaling needs to be extended to support the TPN assignment function. 4.3. Signal type From a routing perspetive, [RFC 4203] allows advertising foundation G.709 (single TS type) without the capability of providing precise information about bandwidth specific allocation. For example, in case of link bundling, dividing the unreserved bandwidth by the MAX LSP bandwidth it is not possible to know the exact number of LSPs at MAX LSP bandwidth size that can be set up. (see example fig. 3) The lack of spatial allocation heavily impacts the restoration Belotti, et al. Expires April 21, 2011 [Page 9] Internet-Draft Information model for G.709 OTN October 2010 process, because the lack of information of free resources highly increases the number of crank-backs affecting network convergence time. Moreover actual tools provided by OSPF-TE only allow advertising signal types with fixed bandwidth and implicit hierarchy (e.g. SDH/ SONET networks) or variable bandwidth with no hierarchy (e.g. packet switching networks) but do not provide the means for advertising networks with mixed approach (e.g. ODUflex CBR and ODUflex packet). For example, advertising ODU0 as MIN LSP bandwidth and ODU4 as MAX LSP bandwidth it is not possible to state whether the advertised link supports ODU4 and ODUflex or ODU4, ODU3, ODU2, ODU1, ODU0 and ODUflex. Such ambiguity is not present in SDH networks where the hierarchy is implicit and flexible containers like ODUFlex do not exist. The issue could be resolved by declaring 1 ISCD for each signal type actually supported by the link. Supposing for example to have an equivalent ODU2 unreserved bandwidth in a TE-link (with bundling capability) distributed on 4 ODU1, it would be advertised via the ISCD in this way: MAX LSP Bw: ODU1 MIN LSP Bw: ODU1 - Maximum Reservable Bandwidth (of the bundle) set to ODU2 - Unreserved Bandwidth (of the bundle) set to ODU2 Moreover with the current IETF solutions, ([RFC4202], [RFC4203]) as soon as no bandwidth is available for a certain signal type it is not advertised into the related ISCD, losing also the related capability until bandwidth is freed. In conclusion, the OSPF-TE extensions defined in [RFC4203] require a different ISCD per signal type in order to advertise each supported container. This motivates attempting to look for a more optimized solution, without proliferations of the number of ISCD advertised. With respect to link bundling, the utilization of the ISCD as it is, would not allow precise advertising of spatial bandwidth allocation information unless using only one component link per TE link. On the other hand, from a singaling point of view, [RFC4328] describes GMPLS signaling extensions to support the control for G.709 OTNs [G709-V1]. However,[RFC4328] needs to be updated because it does not provide the means to signal all the new signal types and related mapping and multiplexing functionalities. Belotti, et al. Expires April 21, 2011 [Page 10] Internet-Draft Information model for G.709 OTN October 2010 4.4. Bit rate and tolerance In the current traffic parameters signaling, bit rate and tolerance are implicitly defined by the signal type. ODUflex CBR and Packet can have variable bit rates and tolerances (please refer to [OTN-FWK] table 2); it is thus needed to upgrade the signaling traffic patameters so to specify requested bit rates and tolerance values during LSP setup. 4.5. Unreserved Resources Unreserved resources need to be advertised per priority and per signal type in order to allow the correct functioning of the restoration process. [RFC4203] only allows advertising unreserved resources per priority, this leads not to know how many LSPs of a specific signal type can be restored. As example it is possible to consider the scenario depicted in the following figure. +------+ component link 1 +------+ | +------------------+ | | | component link 2 | | | N1 +------------------+ N2 | | | component link 3 | | | +------------------+ | +------+ +---+--+ Figure 4: Concurrent path computation Suppose to have a TE link comprising 3 ODU3 component links with 32TSs available on the first one, 24TSs on the second, 24TSs on the third and supporting ODU2 and ODU3 signal types. The node would advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX LSP bandwidth equal to 32 TSs. In case of restoration the network could try to restore 2 ODU3 (64TSs) in such TE-link while only a single ODU3 can be set up and a crank-back would be originated. In more complex network scenarios the number of crank-backs can be much higher. 4.6. Maximum LSP Bandwidth Maximum LSP bandwidth is currently advertised in the common part of the ISCD and advertised per priority, while in OTN networks it is only required for ODUflex advertising. This leads to a significant waste of bits inside each LSA. Belotti, et al. Expires April 21, 2011 [Page 11] Internet-Draft Information model for G.709 OTN October 2010 4.7. Distinction between terminating and switching capability The capability advertised by an interface needs further distinction in order to separate termination and switching capabilities. Due to internal constraints and/or limitations, the type of signal being advertised by an interface could be just switched (i.e. forwarded to switching matrix without multiplexing/demultiplexing actions), just terminated (demuxed) or both of them. The following figures help explainig the switching and terminating capabilities. MATRIX LINE INTERFACE +-----------------+ +-----------------+ | +-------+ | ODU2 | | ----->| ODU-2 |----|----------|--------\ | | +-------+ | | +----+ | | | | \__/ | | | | \/ | | +-------+ | ODU3 | | ODU3 | ----->| ODU-3 |----|----------|------\ | | | +-------+ | | \ | | | | | \| | | | | +----+ | | | | \__/ | | | | \/ | | | | ---------> OTU-3 +-----------------+ +-----------------+ Figure 5: Switching and Terminating capabilities The figure in the example shows a line interface able to: - Multiplex an ODU2 coming from the switching matrix into and ODU3 and map it into an OTU3 - Map an ODU3 coming from the switching matrix into an OTU3 In this case the interface bandwidth advertised is ODU2 with switching capability and ODU3 with both switching and terminating capabilities. This piece of information needs to be advertised together with the related unreserved bandwidth and signal type. As a consequence signaling must have the possibility to setup an LSP allowing the local selection of resources consistent with the limitations considered during the path computation. Belotti, et al. Expires April 21, 2011 [Page 12] Internet-Draft Information model for G.709 OTN October 2010 4.8. Priority Support The IETF foresees that up to eight priorities must be supported and that all of them have to be advertised independently on the number of priorities supported by the implementation. Considering that the advertisement of all the different supported signal types will originate large LSAs, it is advised to advertise only the information related to the really supported priorities. 4.9. Multi-stage multiplexing With reference to the [OTN-FWK], introduction of multi-stage multiplexing implies the advertisement of cascaded adaptation capabilities together with the matrix access constraints. The structure defined by IETF for the advertisement of adaptation capabilities is ISCD/IACD as in [RFC4202] and [RFC5339]. Modifications to ISCD/IACD , if needed, are FFS. 4.10. Generalized Label The ODUk label format defined in [RFC4328] could be updated to support new signal types defined in [G709-V3] but would hardly be further enhanced to support possible new signal types. Furthermore such label format may have scalability issues due to the high number of labels needed when signaling large LSPs. For example, when an ODU3 is mapped into an ODU4 with 1.25G tributary slots, it would require the utilization of thirty-one labels (31*4*8=992 bits) to be allocated while an ODUflex into an ODU4 may need up to eighty labels (80*4*8=2560 bits). A new flexible and scalable ODUk label format needs to be defined. 5. Security Considerations TBD 6. IANA Considerations TBD 7. Acknowledgements The authors would like to thank Eve Varma and Sergio Lanzone for their precious collaboration and review. Belotti, et al. Expires April 21, 2011 [Page 13] Internet-Draft Information model for G.709 OTN October 2010 8. References 8.1. Normative References [HIER-BIS] K.Shiomoto, A.Farrel, "Procedure for Dynamically Signaled Hierarchical Label Switched Paths", work in progress draft-ietf-lsp-hierarchy-bis-08, February 2010. [OTN-OSPF] D.Ceccarelli,D.Caviglia,F.Zhang,D.Li,Y.Xu,P.Grandi,S.Belot ti, "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN Networks", work in progress draft-ceccarelli-ccamp-gmpls-ospf-g709-03, August 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006. [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, July 2008. [RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 5339, September 2008. 8.2. Informative References [G.709-v1] ITU-T, "Interface for the Optical Transport Network (OTN)", G.709 Recommendation (and Amendment 1), Belotti, et al. Expires April 21, 2011 [Page 14] Internet-Draft Information model for G.709 OTN October 2010 February 2001. [G.709-v2] ITU-T, "Interface for the Optical Transport Network (OTN)", G.709 Recommendation (and Amendment 1), March 2003. [G.709-v3] ITU-T, "Rec G.709, version 3", approved by ITU-T on December 2009. [G.872-am2] ITU-T, "Amendment 2 of G.872 Architecture of optical transport networks for consent", consented by ITU-T on June 2010. [OTN-FWK] F.Zhang, D.Li, H.Li, S.Belotti, "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", work in progress draft-ietf-ccamp-gmpls-g709-framework-00, April 2010. Authors' Addresses Sergio Belotti Alcatel-Lucent Via Trento, 30 Vimercate Italy Email: sergio.belotti@alcatel-lucent.com Pietro Vittorio Grandi Alcatel-Lucent Via Trento, 30 Vimercate Italy Email: pietro_vittorio.grandi@alcatel-lucent.com Belotti, et al. Expires April 21, 2011 [Page 15] Internet-Draft Information model for G.709 OTN October 2010 Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: daniele.ceccarelli@ericsson.com Diego Caviglia Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: diego.caviglia@ericsson.com Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 P.R.China Bantian, Longgang District Phone: +86-755-28972912 Email: zhangfatai@huawei.com Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 P.R.China Bantian, Longgang District Phone: +86-755-28973237 Email: danli@huawei.com Belotti, et al. Expires April 21, 2011 [Page 16]