CCAMP Working Group Khuzema Pithewan Internet-Draft Rajan Rao Intended status: Proposed Standard Ashok Kunjidhapatham Expires: December 31, 2011 Biao Lu Mohit Misra Infinera Lyndon Ong Ciena Igor Bryskin Adva June 29, 2011 Signaling Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks draft-khuzema-ccamp-gmpls-signaling-g709-02.txt 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License 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 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 Khuzema, et al. Expires December 31, 2011 [Page 1] Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011 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. Abstract As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting early version of G.709 [G.709-v1].The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. This document extends [RFC4328] to provide GMPLS signaling support for the new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The signaling extensions described in this document caters to ODU layer switching only. Optical Channel Layer switching considerations in [RFC4328] are not modified in this document. Khuzema, et al. Expires December 31, 2011 [Page 2] Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . . 5 3. Requirements for supporting services over hierarchical OTN network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview of GMPLS Signaling Extensions for supporting hierarchical OTN networks . . . . . . . . . . . . . . . . . . . 6 5. Extensions to G.709 Traffic Parameters . . . . . . . . . . . . . 7 5.1. Usage of Bit_Rate and Tolerance for ODUflex Service . . . . 9 6. New Generalized Label Format . . . . . . . . . . . . . . . . . . 9 6.1 Multi-stage Label . . . . . . . . . . . . . . . . . . . . . 9 6.2. Label format for NVC or Multiplier > 1 . . . . . . . . . 11 7. Usage of Multi-stage Label . . . . . . . . . . . . . . . . . . 11 8. Label Distribution Rules . . . . . . . . . . . . . . . . . . . 13 9. Interoperability Considerations . . . . . . . . . . . . . . . 14 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . 19 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix B : RFC4328 and G.709v3 . . . . . . . . . . . . . . . . 23 Khuzema, et al. Expires December 31, 2011 [Page 3] Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011 1. Introduction Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends MPLS from supporting Packet Switching Capable (PSC) interfaces and switching to include support of four new classes of interfaces and switching: Layer-2 Switching (L2SC), Time-Division Multiplex (TDM), Lambda Switch (LSC), and Fiber-Switch (FSC) Capable. A functional description of the extensions to MPLS signaling that are needed to support these new classes of interfaces and switching is provided in [RFC3471]. ITU-T Recommendations G.709 and G.872 provide specifications for OTN interface and network architecture respectively. As OTN network capabilities continue to evolve; there is an increased need to support GMPLS control for the same. GMPLS signaling extensions to support [G.709-v1] OTN interfaces are specified in [RFC4328]. Further extensions are required to support the new capabilities introduced since [G.709-v1]. Following are the features added in OTN since the first version [G.709-v1]. (a) OTU Containers: Pre-existing Containers: OTU1, OTU2 and OTU3 New Containers introduced in [G.709-v3]: OTU2e and OTU4 New Containers introduced in [GSUP.43]: OTU1e, OTU3e1 and OTU3e2 (b) Fixed ODU Containers: Pre-existing Containers: ODU1, ODU2 and ODU3 New Containers introduced in [G.709-v3]: ODU0, ODU2e and ODU4 New Containers introduced in [GSUP.43]: ODU1e, ODU3e1 and ODU3e2 (c) Flexible ODU Containers: ODUflex for CBR and GFP-F mapped services. ODUflex uses 'n' number of OPU Tributary Slots where 'n' is different from the number of OPU Tributary Slots used by the Fixed ODU Containers. (d) Tributary Slot Granularity: OPU2 and OPU3 support two Tributary Slot Granularities: (i) 1.25Gbps and (ii) 2.5Gbps. (e) ODU Multiplexing Hierarchy: Multi-stage multiplexing of LO-ODUs into HO-ODU is supported. Also, multiplexing could be heterogeneous (meaning LO-ODUs of different rates can be multiplexed into the same HO-ODU). OTN networks support switching at two layers: (i) ODU Layer - TDM Switching and (ii) OCH Layer - Lambda (LSC) Switching. The nodes on the network may support one or both the switching types. When Khuzema, et al. Expires December 31, 2011 [Page 4] Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011 multiple switching types are supported MLN based routing [RFC5339] is assumed. This document extends [RFC4328] to provide GMPLS signaling support for the new OTN capabilities defined in [G.709-v3] and [GSUP.43]. This complies with the requirements outlined in the framework document [G.709-FRAME]. The signaling extensions described in this document caters to ODU layer switching only. Optical Channel Layer switching considerations in [RFC4328] are not modified in this document. Following are the extensions described in this document: (i) G.709 Traffic Parameters defined in [RFC4328] is extended to include Bit Rate (in bytes/second) and Tolerance (in ppm) fields for supporting ODUflex service. (ii) New Generalized Label Format is introduced to provide compact encoding of Tributary Slot information and support multi-stage ODU multiplexing. 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 is to be interpreted as described in RFC-2119 [RFC2119]. In addition, the reader is assumed to be familiar with the terminology used in ITU-T [G.709-v3], [G.872] and [GSUP.43], as well as [RFC4201] and [RFC4203]. 3. Requirements for supporting services over hierarchical OTN network R1. Support signaling mechanism to instantiate ODUj service layer on a ODUk link via single stage muxing. A ODUj LSP could involve zero (j=k) or one stage (j 1 For NVC or Multiplier field value > 1, the label format defined in section 5 needs to be repeated NVC/multiplier times. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Instance #1 | | (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Instance #n | | (n = NVC/Multiplier) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7. Usage of Multi-stage Label Multi-stage Label is needed when switching of an ODU Layer requires termination of more than one HO-ODUs on a given OTU/ODU Link. This eliminates the need for creating H-LSPs whose span matches its parent TE-Link. Khuzema, et al. Expires December 31, 2011 [Page 11] Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011 Example-1: Assume on an OTU3 Link, a restrictive MUX hierarchy (as shown in figure below) is supported on the associated interfaces. In order to switch ODU1 on this Link, ODU3 and ODU2 need to be terminated on the same span as the OTU3 link. If multi-stage Label is not supported, H-LSP need to be created for ODU3 and ODU2 layers (or just ODU2 layer at the minimum) inorder to support ODU1 LSP. Creation of ODU3 and ODU2 H-LSP on top of OTU3 Link on the same span is not really required as bandwidth management for all ODU layers can still be managed on the OTU3 Link itself. Multi-stage Label helps in implicit creation of ODU3 and ODU2 layers as part of ODU1 LSP setup and thus eliminates the need for the creation of the H-LSP on every hop. ODU0 | ODU1 ODU0 \ / ODU2 | ---------- ODU3 ---------- | | | | | | Node | OTU3 | Node | | |-----------------------------| | | A | | B | | | | | ---------- ---------- |<----- OTU3 TE-Link ------->| Label Format: Stage-1: ODU3<-ODU2/TPN/Trib Slots Stage-2: ODU2<-ODU1/TPN/Trib Slots Figure-2: Multi-stage Label on OTUk Link Example-2: Assume on an ODU3 H-LSP (B-C-D), signaling of ODU1 LSP requires termination of ODU2. Multi-stage Label helps in implicit creation of ODU2 layer as part of ODU1 LSP setup (A-B-D-E). Khuzema, et al. Expires December 31, 2011 [Page 12] Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011 ODU1 ODU1 | | ODU2 ODU2 | | ODU3 ODU3 | | OTU3 OTU3 / \ ------ -----/ ------ \------ ------ | | | | | | | | | | |Node| |Node| |Node| |Node| |Node| | |--------| |--------| |--------| |--------| | | A | | B | | C | | D | | E | | | | | | | | | | | ------ ------ ------ ------ ------ |<-OTU2->| |<-OTU3->| |<-OTU3->| |<-OTU2->| | | |<-----ODU3 H-LSP----->| Figure-3: Multi-stage Label on ODUk Link Note: Multi-stage Label is NOT intended to facilitate the creation of H-LSP or Hierarchical LSP. It is basically used to eliminate the need for H-LSP in some obvious scenarios. 8. Label Distribution Rules This document does not change the existing label distribution procedures defined in [RFC4328] except that the new ODU label should be processed as follows. A. Sending Side When Generalized Label Request is received on given node for setting up an ODU LSP from its upstream neighbor, it reserves the bandwidth required for the ODU Layer being switched and also the terminating HO-ODUs layers involved. It sends upstream label and suggested label (if applicable) to the downstream node and downstream label via PATH Message and downstream label to the upstream node via RESV Message. Note that Label can also be explicitly specified by source node. The encoding of Generalized Label is as follows: Khuzema, et al. Expires December 31, 2011 [Page 13] Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011 Case-1: ODUk mapping into OTUk Number of MUX stages = 0 Tributary Slot information is not included. Case-2: ODUj mux into ODUk Number of MUX Stages = 1. Stage-1: Length = . TPN = TS BitMap = Case-3 ODUh mux into ODUj into ODUk Number of MUX Stages = 2. Stage-1: Length = . TPN = TS BitMap = Stage-2: Length = . TPN = TS BitMap = B. Receiving Side The decoding of the Generalized Label is as follows: Case-1: ODUk mapping into OTUk For ODUk to OTUk mapping, the Tributary Slot Information is not expected. Case-2: ODUj mux into ODUk For ODUj to ODUk multiplexing, one MUX stage Label is expected. The node extracts the Bit Map field in Tributary Slot Info using the Length field. The position of Bit in the Bitmap interpreted as the Tributary Slot Number. The value stored in the bit indicates if it is reserved for the ODUj. Case-3: ODUh mux into ODUj into ODUk For ODUh mux into ODUj into ODUk, two MUX stage Label is expected. Each stage is further decoded as explained in case-2 above. 9. Interoperability Considerations The neighbor nodes on a TE-Link span should exchange the signaling stack versions (via some link discovery mechanism) in order to determine the Generalized Label Format to use. In the following example, Switch B and C are running the newer version of signaling stack (that support the new G.709 Traffic Parameters and Generalized Label Format) while Switch A is Khuzema, et al. Expires December 31, 2011 [Page 14] Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011 running the older version. +-------+ +-------+ +-------+ | OTN | | OTN | | OTN | |Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch | | A | | B | | C | +-------+ +-------+ +-------+ |<-- Legacy -->| |<-- New TE-Link -->| Figure-4: OTUk TE-Link Link A-B: G.709-v1 version (2001) based OTUk link TSG: 2.5G; Label format: as per RFC 4328 Link B-C: G.709-v3 version based OTUk link (12/09) TSG: 1.25G; Label format: new label format proposed in this draft. For an ODU2 connection going from A-C, On link A-B : NMC is set to 4 & [RFC4328] label format is used. On link B-C : NMC is not used & new label format is used. 10. Examples Example-1 : ODUj LSP over OTUk Links Consider the network topology shown in the Figure-5 below: +-----+ +-----+ +-----+ +-----+ | OTN | | OTN | | OTN | | OTN | | SW |<-OTU2 Link->| SW |<-OTU3 Link->| SW |<-OTU2 Link->| SW | | A | | B | | C | | D | +-----+ +-----+ +-----+ +-----+ Figure-5: OTN Signaling Example Assumptions: (1) ODU2 links between OTN-Switches A & B and C & D support 1.25Gbps TS Granularity. (2) ODU3 link between OTN-Switches B & C supports TS Granularity of 2.5Gbps only. Hence, ODU0 switching on this link is possible only through ODU3-ODU2-ODU0 or ODU3-ODU1-ODU0 multiplexing hierarchies. Khuzema, et al. Expires December 31, 2011 [Page 15] Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011 G.709 Traffic Parameters and Generalized Label for ODU0 LSP from node A to D is captured below: A. G.709 Traffic Parameters Signal Type = ODU0 NMC/Tolerance = 0 // NMC is not used. NVC = 0 Multiplier (MT) = 1 Bit_Rate = 0 Khuzema, et al. Expires December 31, 2011 [Page 16] Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011 B. Generalized Label Format: +=============+==============+==============+==============+ | | A to B | B to C | C to D | +=============+==============+==============+==============+ | # of Stages | 1 | 2 | 1 | +-------------+--------------+--------------+--------------+ | Stage-1 | ODU2<--ODU0 | ODU3<--ODU2 | ODU2<--ODU0 | | | TSG = 1.25G | TSG = 2.5G | TSG = 1.25G | | | #TSs = 8 | #TSs = 16 | #TSs = 8 | | | TPN = <1..8> | TPN = <1..4> | TPN = <1..8> | | | BMap = 4bytes| BMap = 4bytes| BMap = 4bytes| +-------------+--------------+--------------+--------------+ | Stage-2 | N/A | ODU2<--ODU0 | N/A | | | | TSG = 1.25G | | | | | #TSs = 8 | | | | | TPN = <1..8> | | | | | BMap = 4bytes| | +-------------+--------------+--------------+--------------+ Example 2: ODUj LSP over ODUk H-LSP Refer to Figure-3 in section 6. The G.709 Traffic Parameters and Generalized Label for ODU1 LSP from Node A to E is captured below: A. G.709 Traffic Parameters: Signal Type = ODU1 NMC/Tolerance = 0 // NMC is not used. NVC = 0 Multiplier (MT) = 1 Bit_Rate = 0 B. Generalized Label Format: +=============+==============+==============+==============+ | | A to B | B to D | D to E | +=============+==============+==============+==============+ | # of Stages | 1 | 2 | 1 | +-------------+--------------+--------------+--------------+ | Stage-1 | ODU2<--ODU1 | ODU3<--ODU2 | ODU2<--ODU1 | | | TSG = 1.25G | TSG = 2.5G | TSG = 1.25G | | | #TSs = 8 | #TSs = 16 | #TSs = 8 | | | TPN = <1..4> | TPN = <1..4> | TPN = <1..4> | | | BMap = 4bytes| BMap = 4bytes| BMap = 4bytes| +-------------+--------------+--------------+--------------+ | Stage-2 | N/A | ODU2<--ODU1 | N/A | | | | TSG = 1.25G | | | | | #TSs = 8 | | | | | TPN = <1..4> | | | | | BMap = 4bytes| | +-------------+--------------+--------------+--------------+ Khuzema, et al. Expires December 31, 2011 [Page 17] Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011 11. Security Considerations There are no additional security implications to Signaling protocol due to the extensions captured in this document. 12. IANA Considerations TBD 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels". [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)" [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)" [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005. [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006. [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. [VCAT-LCAS] G. Bernstein (ed.), D. Caviglia, R. Rabbat and H. van Helvoort, "Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)", draft-bernstein-ccamp-gmpls-vcat-lcas-11.txt, March 09, 2011 Khuzema, et al. Expires December 31, 2011 [Page 18] Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011 [G.709-v3] ITU-T, "Interfaces for the Optical Transport Network (OTN)", G.709 Recommendation, December 2009. 13.2. Informative References [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [G.709-v1] ITU-T, "Interface for the Optical Transport Network (OTN)," G.709 Recommendation (and Amendment 1), February 2001 (October 2001). [G.872] ITU-T, "Architecture of optical transport networks", November 2001 (11 2001). [G.709-FRAME] F. Zhang, D. Li, H. Li, S. Belotti, "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", draft-zhang-ccamp-gmpls-g709-framework-02, work in progress. [WSON-FRAME] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)", draft-ietf-ccamp-rwa-wson-framework, work in progress. [OSPF-EXTN-FOR-OTN] S. Bardalai, R. Rao, A. Kunjidhapatham, K. Pithewan, "OSPF TE Extensions for GMPLS Control of G.709 Optical Transport Networks", draft-ashok-ccamp-gmpls-ospf-g709-02, work in progress. 14. Acknowledgements Authors would like to thank Lou Berger, Steve Balls and Radhakrishna Valiveti for review comments and suggestions. Author's Addresses Khuzema Pithewan Infinera Corporation 169, Java Drive Sunnyvale, CA-94089, USA Email: kpithewan@infinera.com Mohit Misra Infinera Corporation 169, Java Drive Khuzema, et al. Expires December 31, 2011 [Page 19] Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011 Sunnyvale, CA-94089, USA Email: mmisra@infinera.com Rajan Rao Infinera Corporation 169, Java Drive Sunnyvale, CA-94089, USA Email: rrao@infinera.com Ashok Kunjidhapatham Infinera Corporation 169, Java Drive Sunnyvale, CA-94089, USA Email: akunjidhapatham@infinera.com Biao Lu Infinera Corporation 169, Java Drive Sunnyvale, CA-94089, USA Email: blu@infinera.com Lyndon Ong Ciena 10480 Ridgeview Court Cupertino, CA 95014, USA EMail: lyong@ciena.com Igor Bryskin Adva Optical EMail: IBryskin@advaoptical.com Appendix A: Abbreviations & Terminology A.1 Abbreviations: CBR Constant Bit Rate GFP Generic Framing Procedure HO-ODU Higher Order ODU LSC Lambda Switch Capable LSP Label Switched Path LO-ODU Lower Order ODU ISCD Interface Switch Capability Descriptor OCC Optical Channel Carrier Khuzema, et al. Expires December 31, 2011 [Page 20] Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011 OCG Optical Carrier Group OCh Optical Channel (with full functionality) OChr Optical Channel (with reduced functionality) ODTUG Optical Date Tributary Unit Group ODU Optical Channel Data Unit OMS Optical Multiplex Section OMU Optical Multiplex Unit OPS Optical Physical Section OPU Optical Channel Payload Unit OSC Optical Supervisory Channel OTH Optical Transport Hierarchy OTM Optical Transport Module OTN Optical Transport Network OTS Optical Transmission Section OTU Optical Channel Transport Unit OTUkV Functionally Standardized OTUk SCSI Switch Capability Specific Information TDM Time Division Multiplex TPN Tributary Port Number TS Tributary Slot or Time Slot A.2 Terminology 1. ODUk and ODUj ODUk refers to the ODU container that is directly mapped to an OTU container. ODUj refers to the lower order ODU container that is mapped to an higher order ODU container via multiplexing. 2. LO-ODU and HO-ODU LO-ODU refers to the ODU client layer of lower rate that is mapped to an ODU server layer of higher rate via multiplexing. HO-ODU refers to the ODU server layer of higher rate that supports mapping of one or more ODU client layers of lower rate. In multi-stage multiplexing case, a given ODU layer can be a client for one stage (interpreted as LO-ODU) and at the same time server for another stage (interpreted as HO-ODU). In this case, the notion of LO-ODU and HO-ODU needs to be interpreted in a recursive manner. Khuzema, et al. Expires December 31, 2011 [Page 21] Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011 ODU3 | (HO-ODU) ^ | | | Stage #1 | | (HO-ODU) | ODU2 | (LO-ODU) | ^ Stage #2 | | | | (LO-ODU) | ODU1 | (HO-ODU) ^ | | | Stage #3 | | ODU0 | (LO-ODU) Figure-6 : LO-ODU and HO-ODU 3. Single Stage Multiplexing When ODU multiplexing hierarchy involves only two levels (ODUk and ODUj), it is referred as single stage multiplexing. ODU3 | Level-1 ^ | | | | | ODU1 | Level-2 Figure-7: Single Stage Multiplexing 4. Multi Stage Multiplexing When ODU multiplexing hierarchy involves more than two levels, it is referred as multi-stage multiplexing. Two adjoining levels form a multiplexing stage. ODU3 | Level-1 ^ | | | Stage #1 | | Level-2 | ODU2 | Level-2 | ^ Stage #2 | | | | Level-3 | ODU1 | Level-3 ^ | | | Stage #3 | | ODU0 | Level-4 Figure-8 : Multi Stage Multiplexing Khuzema, et al. Expires December 31, 2011 [Page 22] Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011 Appendix B : RFC4328 and G.709v3 B.1 G.709 Traffic Parameters The G.709 Traffic Parameters defined in [RFC4328] does not work well for the new features introduced in [G.709-v3]. The basic draw-backs are: (a) NMC attribute defined in G.709 Traffic Parameters does not apply end-to-end especially when links with different TSG are involved in the path of a LSP. (b) ODUflex needs absolute nominal rate and tolerance to be specified. B.2 Label Format The Label format defined in [RFC4328] is not scalable/extensible to cover the new ODU rates defined in [G.709-v3]. Some of the limitations are captured below: (a) The bit-fields defined to represent TSs for specific ODU rates are not future proof. The reserved bits are not sufficient to cover the future ODU types. (b) The label format assumes 2.5G Tributary Slot Granularity. It needs to be redefined for 1.25G Tributary Slot Granularity. (c) One Tributary Slot information is coded in 4 bytes. ODU3 and ODU4 requires 32 and 80 TSs respectively. This would dramatically increase the label size and thus impact the scalability. Khuzema, et al. Expires December 31, 2011 [Page 23]