Network Working Group Zhenbin Li Internet-Draft Tao Zhou Intended status: Informational Quintin Zhao Expires: April 25, 2013 Huawei Technologies October 22, 2012 Applicability of LDP Multi-Topology for Unicast Fast-reroute Using Maximally Redundant Trees draft-li-rtgwg-ldp-mt-mrt-frr-01 Abstract In this document, procudures' considerations on the applicability of LDP MT for unicast fast-reroute using MRT are provided. The behaviors of label allocation and label forwarding entry setup with LDP Multi-Topology and MRT fast-reroute are described in details. Different application scenarios of the combining of the LDP multi- topology(MT) and unicast fast-reroute using Maximally Redundant Trees(MRT) are also anlyzed. 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 April 25, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Zhenbin Li, et al. Expires April 25, 2013 [Page 1] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Procedure Considerations . . . . . . . . . . . . . . . . . . . 4 3.1. Routing Calculation . . . . . . . . . . . . . . . . . . . 4 3.2. Label Distribution . . . . . . . . . . . . . . . . . . . . 5 3.3. Forwarding Entry Creation . . . . . . . . . . . . . . . . 5 3.4. Switchover and Re-Convergence . . . . . . . . . . . . . . 6 3.5. Switchback . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6. IGP MT and LDP MT . . . . . . . . . . . . . . . . . . . . 6 3.7. Multiple IGP . . . . . . . . . . . . . . . . . . . . . . . 7 3.8. Label Space . . . . . . . . . . . . . . . . . . . . . . . 7 3.9. Proxy Egress . . . . . . . . . . . . . . . . . . . . . . . 7 3.10. Policy Control . . . . . . . . . . . . . . . . . . . . . . 8 3.11. LDP DOD . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.12. Resource Allocations . . . . . . . . . . . . . . . . . . . 8 4. Application Scenarios' Analysis . . . . . . . . . . . . . . . 8 4.1. 2-Connected Network . . . . . . . . . . . . . . . . . . . 8 4.2. Non-2-Connected Network . . . . . . . . . . . . . . . . . 12 4.3. Proxy Node . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Inter-Area and Inter-AS . . . . . . . . . . . . . . . . . 13 4.5. Partial Deployment . . . . . . . . . . . . . . . . . . . . 16 4.6. LDP over TE . . . . . . . . . . . . . . . . . . . . . . . 18 4.7. IP-Only Network . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. Normative References . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Zhenbin Li, et al. Expires April 25, 2013 [Page 2] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 1. Introduction [I-D.ietf-rtgwg-mrt-frr-architecture] describes the architecture based on Maximally Redundant Trees (MRT) to provide 100% coverage for fast-reroute of unicast traffic. LDP multi-topology [I-D.ietf-mpls-ldp-multi-topology] has been proposed to provide multi-topology-based unicast forwarding in the architecture. Guidance is provided for different application scenarios to improve the applicability. The analysis of the applicability of LDP MT for unicast fast-reroute using MRT is provided. The procedures are described and typical examples are provided based on LDP MT and MRT unicast FRR architecture. When LDP MT is combined with MRT FRR, follow advantages can be achieved: o Provide 100% coverage for unicast traffic. o The complexity of the algorithm is moderate in O(e) or o( e + n log n ). o Co-deployment with LFA to provide better protection coverage. o Simplify operation and management with few additional configurations and states introduced. o Inherit procedures of LDP to achieve high scalability. o Propose no additional change on label forwarding behavior in the forwarding plane to facilitate incremental deployment. 2. Terminology Some of terminologies defined in the [I-D.ietf-rtgwg-mrt-frr-architecture] are repeated here for the clarity of this document. o 2-connected: A graph that has no cut-vertices. This is a graph that requires two nodes to be removed before the network is partitioned. o 2-connected cluster: A maximal set of nodes that are 2-connected. o 2-edge-connected: A network graph where at least two links must be removed to partition the network. Zhenbin Li, et al. Expires April 25, 2013 [Page 3] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 o cut-link: A link whose removal partitions the network. A cut-link by definition must be connected between two cut-vertices. If there are multiple parallel links, then they are referred to as cut-links in this document if removing the set of parallel links would partition the network. o cut-vertex: A vertex whose removal partitions the network. o ECMP Equal cost multi-path: Where, for a particular destination D, multiple primary next-hops are used to forward traffic because there exist multiple shortest paths from S via different output layer-3 interfaces. o FIB Forwarding Information Base. The database used by the packet forwarder to determine what actions to perform on a packet. o LFA Loop-Free Alternate. A neighbor N, that is not a primary neighbor E, whose shortest path to the destination D does not go back through the router S. The neighbor N must meet the following condition: Distance_opt(N, D)[D]->[H]->[J] | | | | | ^ ^ ^ ^ | | | | | | | v | | | | v v v [R] [C] [G]--[I] [R] [C] [G]->[I] [R] [C] [G]<-[I] | | | | | ^ ^ ^ ^ | | | | | | | v | | | | v v | [A]--[B]--[F]---| [A]->[B]->[F]---| [A]<-[B]<-[F]<--| (a) Topology (b) Blue Topology (c) Red Topology Figure 1: 2-Connected Network According to the MRT calculation, for a specific destination H, there are following paths in different topologies for other nodes, Default Topology Blue Topology Red Topology R R->A->B->F->G->H R->A->B->F->G->H R->E->D->H A A->B->F->G->H A->B->F->G->H A->R->E->D->H B B->F->G->H B->F->G->H B->A->R->E->D->H C C->B->F->G->H C->B->F->G->H C->D->H D D->C->B->F->G->H D->E->R->A->B->F D->H E E->D->C->B->F->G->H E->R->A->B->F->G->H E->D->H F F->G->H F->G->H F->B->A->R->E->D->H G G->H G->H G->F->B->A->R->E->D->H I I->G->H I->J->H I->G->F->B->A->R->E->D->H J J->H J->H J->I->G->F->B->A->R->E->D->H Figure 2: Paths in Different Topologies for H Note: 1. Assume that the metric of {E,R}, {D,H}, {R,C}, {G,I} and {F,I} is extreme high so that the route of the default topology is reasonable. 2. Assume tie-breaking rules determine that in blue topology the route from G to H chooses the path G->H instead of G->I->J->H. 3. Assume tie-breaking rules determine that in red topology the route from I to H chooses the path I->G->F->B->A->R->E->D->H instead of I->F->B->A->R->E->D->H. 4. For D node, both blue topology and red topology are available for the backup. The blue topology is preferred. From the above calculation example, we can see that how the tie- breaking rule has to be applied when choose the nexthop in a specific topology and the topology which is used for the secondary route. For the reason of simplicity, there is no LFA calculation for the secondary route. If exists, it should be preferred. Zhenbin Li, et al. Expires April 25, 2013 [Page 9] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 We assume that labels are allocated in different topologies as the following figure. <-- L/Lb/Lr <-- L/Lb/Lr <-- L/Lb/Lr --> L/Lb/Lr --> L/Lb/Lr --> L/Lb/Lr [E]------------------[D]------------------[H]-------------------[J] | | | | | | ^ | | ^ | | ^ | | ^ | | | | | | | | | | | | v | | v | | v | | v | | L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr | | | | | | | <-- L/Lb/Lr | | | | --> L/Lb/Lr | [R]------------------[C] [G]-------------------[I] | | | | | | ^ | | ^ | | ^ | | ^ | | | | | | | | | | | | v | | v | | v | | v | | L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr | | | | | | | | | | | | [A]------------------[B]------------------[F]--------------------| <-- L/Lb/Lr <-- L/Lb/Lr <-- L/Lb/Lr --> L/Lb/Lr --> L/Lb/Lr --> L/Lb/Lr Figure 3: Label Allocation for LDP Multi-Topology Note: 1. "<--" means the direction in which the label is distributed. For example, "<--" from D to E means that the label is distributed by D to E. 2. L means the label for H distributed in the default topology. Lb means the label for H distributed in the blue topology. Lr means the label for H distributed in the red topology. 3. L distributed by different nodes in the default topology does not mean they must be the same. This is also applied to Lb and Lr. According to above MRT calculation result and label allocation for multi-topology, following forwarding entries will be installed for each node: Zhenbin Li, et al. Expires April 25, 2013 [Page 10] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 Default Topology Blue Topology Red Topology R Ingress --/L A /Lr E Transit L/L A Lb/Lb A Lr/Lr E /Lr E /Lr E A Ingress --/L B /Lr R Transit L/L B Lb/Lb B Lr/Lr R /Lr R /Lr R B Ingress --/L F /Lr A Transit L/L F Lb/Lb F Lr/Lr A /Lr A /Lr A C Ingress --/L B /Lr D Transit L/L B Lb/Lb B Lr/Lr D /Lr D /Lr D D Ingress --/L C /Lb E Transit L/L C Lb/Lb E Lr/Lr H /Lb E /Lr H E Ingress --/L D /Lb R Transit L/L D Lb/Lb R Lr/Lr D /Lb R /Lr D F Ingress --/L G /Lr B Transit L/L G Lb/Lb G Lr/Lr B /Lr B /Lr B G Ingress --/L H /Lr F Transit L/L H Lb/Lb H Lr/Lr F /Lr F /Lr F I Ingress --/L G /Lb J Transit L/L G Lb/Lb J Lr/Lr G /Lb J /Lr G J Ingress --/L H /Lr I Transit L/L H Lb/Lb H Lr/Lr I /Lr I /Lr I Figure 4: Label Forwarding Entries Installed in Each Node for FEC H Note: 1. For an ingress label forwarding entry as follows, when forward, L will be pushed and sent to the next hop A. If failure happens, Lr will be pushed and sent to the next hop E. Zhenbin Li, et al. Expires April 25, 2013 [Page 11] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 Ingress --/L A /Lr E 2. For a transit label forwarding entry as follows, when packet with the incoming label L arrives, L will be swapped to L and sent to the next hop A. If failure happens, L will be swapped to Lr and sent to the next hop E. Transit L/L A /Lr E Above forwarding entries construct the label switch path used for fast-reroute in the forwarding plane. We can see that the existing MPLS label forwarding can be used without any extension. 4.2. Non-2-Connected Network [I-D.ietf-rtgwg-mrt-frr-architecture] proposes following non-2- connected network. [E]---[D]---| | | | |----[I] | | | | | [R]---[C] [F]---[G] | | | | | | | | | |----[J] [A]---[B]---| (a) a non-2-connected graph [E]<--[D]<--| [E]-->[D]---| | ^ | [I] ^ | | |--->[I] V | | ^ | V V | [R]-->[C] [F]-->[G] | [R]<--[C] [F]-->[G] | ^ ^ | | ^ | | ^ V | | |--->[J] | V | |----[J] [A]-->[B]---| [A]<--[B]<--| (b) (c) Blue MRT towards I Red MRT towards I Figure 5: A non-2-connected network We will not explain how LDP MT is applied for the MRT FRR in detail. We choose the node I as the destination and choose R and F to observe how MRT and LDP MT work for fast-reroute. Zhenbin Li, et al. Expires April 25, 2013 [Page 12] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 According to MRT calculation, the path from R to I in the blue topology is R->A->B->F->G->J->I and the path from R to I in the red topology is R->E->D->F->G->I. We assume in the default topology the path from R to I is R->C->D->F->G->I. Then following forwarding entry will be created in the node R for the destination I. Default Topology Blue Topology Red Topology R Ingress --/L C /Lb A Transit L/L C Lb/Lb A Lr/Lr E /Lb A /Lr E Figure 6: Label Forwarding Entry of Node R for FEC I For the node F, the path from F to I in the blue topology is F->G->J->I and the path in the red is F->G->I. We assume in the default topology the path from F to I is F->G->I. The following forwarding entry will be created in the node F for the destination I. Default Topology Blue Topology Red Topology F Ingress --/L G Transit L/L G Lb/Lb G Lr/Lr G Figure 7: Label Forwarding Entry of Node F for FEC I We can see that there is no secondary route in the node F for the destination I and correspondingly there is no LDP FRR forwarding entry. 4.3. Proxy Node There are several application scenarios proposed by [I-D.ietf-rtgwg-mrt-frr-architecture] which will use proxy node for MRT. That is, if a set of prefixes are advertised by border routers of an MRT island, a single proxy node can be used to represent the set and the proxy node and associated links are added to the network topology for MRT calculation. The application scenarios include inter-area, inter-AS and partial deployment of compatible MRT FRR routers. 4.4. Inter-Area and Inter-AS For Inter-area scenarios, it is desirable to go back to the default forwarding topology when leaving an area/level. There are two mechanisms proposed by [I-D.ietf-rtgwg-mrt-frr-architecture]. The first one is that ABR will advertise different labels for one specific FEC in different areas. The second one is that penultimate hop pop is done through additional computation by the penultimate Zhenbin Li, et al. Expires April 25, 2013 [Page 13] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 router along the in-local-area MRT immediately before the ARB/LBR is reached. The first one need change of the traditional label allocation method for LDP which always distributes the same label for one FEC to all peers. When the second one used, it must be guaranteed that the IP forwarding should be done by ABR. If there is an inner label, it will cause wrong forwarding behavior. Since it is difficult to determine the type of the packet, the second mechanism must be used carefully. In order to optimize the second mechanism, when the penultimate router receive a packet with MRT label, it can swap the label to corresponding FEC's default topology label instead of penultimate hop pop. Zhenbin Li, et al. Expires April 25, 2013 [Page 14] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 2 2 2 2 A----B----C A----B----C 2 | | 2 2 | | 2 | | | | [ABR1] [ABR2] [ABR1] [ABR2] | | | | p,10 p,15 10 |---[P]---| 15 (a) Initial topology (b)with proxy-node <-- L/Lb/Lr <-- L/Lb/Lr --> L/Lb/Lr --> L/Lb/Lr A------------------B------------------C | | ^ ^ | | | | | | | | v | | | | v L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr [ABR1] [ABR2] | | ^ ^ | | | | | | | | v | | | | v L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr 10 |-----------------[P]-----------------| 15 (c) Label Distribution <-- L/Lb/Lr <-- L/Lb/Lr --> L/Lb/Lr --> L/Lb/Lr A------------------B------------------C | | ^ ^ | | | | | | | | v | | | | v L/Lb/Lr | L/L/L L/L/L | L/Lb/Lr [ABR1] [ABR2] | | ^ ^ | | | | | | | | v | | | | v L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr 10 |-----------------[P]-----------------| 15 (d) Label Distribution Change Figure 8: Inter-area Network and LDP MT Label Distribution for MRT FRR According to the label distribution and MRT computation as shown in (c) of the above figure, following forwarding entries can be created in the node ABR1 and ABR2: Zhenbin Li, et al. Expires April 25, 2013 [Page 15] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 Default Topology Blue Topology Red Topology ABR1 Ingress --/L P /Lr A Transit L/L P Lb/Lb P Lr/Lr A /Lr A /Lr A ABR2 Ingress --/L P /Lb C Transit L/L P Lb/Lb C Lr/Lr P /Lb C /Lr P Figure 9: Label Forwarding Entry of Node ABR1 and ABR2 for Proxy Node If the first method on change of label allocation as shown in (d) of the above figure, following forwarding entry will be created in the node A and C: Default Topology Blue Topology Red Topology A Ingress --/L ABR1 /Lr B Transit L/L ABR1 Lb/L ABR1 Lr/Lr B /Lr B /Lr B C Ingress --/L ABR2 /Lb B Transit L/L ABR2 Lb/Lb B Lr/L ABR2 /Lb B /L ABR2 Figure 10: Label Forwarding Entry of Node A and C for Proxy Node For inter-AS scenarios, prefixes advertised by ASBRs will set up LSP in the default topology as proxy egress. The number of prefixes will have great effect on the label allocation of LDP. When MRT fast- reroute deploys, it should be confirmed firstly that labels are enough. Or else, MRT will have negative effect on the deployment of normal service. Besides this, the complexities for ASBR protection has been proposed by [I-D.ietf-rtgwg-mrt-frr-architecture]. It need further study. 4.5. Partial Deployment For partial deployment and islands of compatible MRT FRR routers, proxy nodes and associated links are added to the network topology for MRT computation. The difference between partial deployment and inter-area is that in the partial deployment scenario the border nodes need proxy egress process for LDP in the blue topology and the red topology. That is, in the blue topology and red topology, the border node of the MRT network topology is not the actual egress for a prefix out of the MRT network. The border node has to advertise label for the prefix as the proxy egress. Zhenbin Li, et al. Expires April 25, 2013 [Page 16] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 2 2 2 2 A----B----C A----B----C 2 | | 2 2 | | 2 | | | | [D] [E] [D] [E] | | | | F---------G |---[P]---| (a) Initial topology (b)with proxy-node <-- L/Lb/Lr <-- L/Lb/Lr --> L/Lb/Lr --> L/Lb/Lr A------------------B------------------C | | ^ ^ | | | | | | | | v | | | | v L/Lb/Lr | L/Lb/Lr L/Lb/Lr | L/Lb/Lr [D] [E] | | ^ ^ | | | | | | | | v | | | | v L | L L | L |-----------------[P]-----------------| (c) Label Distribution Figure 11: Partial Deployment Network and LDP MT Label Distribution for MRT FRR According to the label distribution and MRT computation as shown in (c) of the above figure, following forwarding entries can be created in the node D and E: Default Topology Blue Topology Red Topology D Ingress --/L P /Lr A Transit L/L P Lb/L P Lr/Lr A /Lr A /Lr A E Ingress --/L P /Lb C Transit L/L P Lb/Lb C Lr/L P /Lb C /L P Figure 12: Label Forwarding Entry of Node D and E for Proxy Node Zhenbin Li, et al. Expires April 25, 2013 [Page 17] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 4.6. LDP over TE There is also additional complexity for LDP over TE. An example deployment is shown in the following figure. LDP over TE is deployed in nodes B, C, E and H. That is, nodes I, J and K do not support LDP. For MRT FRR, the deployment can be seen as two independent topologies. For nodes I, J and K, as shown in the figure (b) it is similar as the process of partial deployment. For other nodes, as shown in the figure (c) it is similar as the process of 2-connected network and the bidirectional MPLS TE paths can be used as the virtual links in MRT computation. Noted that, if the MPLS TE paths are unidirectional, the proxy node should present all the nodes not in the same side, which side the tunnels' ingress LSR belongs to. [D]--[C]--[I]--[H]--[G] | | \ / | | | | \ / | | [R] | [J] | | | | / \ | | | | / \ | | [A]--[B]--[K]--[E]--[F] (a) Default Topology [D]--[C] [H]--[G] | | \ / | | | | \ / | | [R] | [Proxy] [Proxy] | | | | / \ | | | | / \ | | [A]--[B] [E]--[F] (b) Graph I for MRT Computation [D]--[C]======[H]--[G] | | \\ // | | | | \\// | | [R] | \\ | | | | //\\ | | | | // \\ | | [A]--[B]======[E]--[F] (c) Graph II for MRT Computation Figure 13: LDP over TE Network and LDP MT Label Distribution for MRT FRR Zhenbin Li, et al. Expires April 25, 2013 [Page 18] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 4.7. IP-Only Network In the IP-only network IP-in-IP has to be used. This means additional loopback addresses have to be introduced. And they are announced with associated MRT color. It will propose complexities for operation and management of the network. We recommend LDP MT should be deployed in the network for the fast-reroute usage to reduce the complexities. It also will not introduce any complexity of IP MT forwarding in the ingress node since the multi-topology only takes effect for protection. Comparing with tunnel IP packet in IP, LDP MT is an easy way to provision fast-reroute. 5. IANA Considerations This document makes no request of IANA. 6. Security Considerations There is no security issue introduced by this specification. 7. Acknowledgements 8. Normative References [I-D.enyedi-rtgwg-mrt-frr-algorithm] Atlas, A., Envedi, G., Csaszar, A., and A. Gopalan, "Algorithms for computing Maximally Redundant Trees for IP/LDP Fast- Reroute", draft-enyedi-rtgwg-mrt-frr-algorithm-02 (work in progress), October 2012. [I-D.ietf-mpls-ldp-multi-topology] Zhao, Q., Fang, L., Zhou, C., Li, L., Ning, S., and K. Raza, "LDP Extensions for Multi Topology Routing", draft-ietf-mpls-ldp-multi-topology-05 (work in progress), October 2012. [I-D.ietf-rtgwg-mrt-frr-architecture] Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Konstantynowicz, M., White, R., and M. Shand, "An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-01 (work in progress), March 2012. Zhenbin Li, et al. Expires April 25, 2013 [Page 19] Internet-Draft App of LDP MT for Unicast MRT FRR October 2012 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010. Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Tao Zhou Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: tao.chou@huawei.com Quintin Zhao Huawei Technologies 125 Nagog Technology Park Acton, MA 01719 US Email: quintin.zhao@huawei.com Zhenbin Li, et al. Expires April 25, 2013 [Page 20]