Network Working Group X. Fu Internet-Draft M. Ke Intended status: Standards Track Y. Bao Expires: May 13, 2010 ZTE Corporation November 9, 2009 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for Evolutive OTNs control draft-fuxh-ccamp-gmpls-extension-for-evolutive-otn-02 Abstract This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology- specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN) based on ITU-T G.709 Amendment 3 reccomandation. References also to G.sup43 are provided. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 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 Fu, et al. Expires May 13, 2010 [Page 1] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. GMPLS Extension for G.709 Amendment 3 . . . . . . . . . . . . 3 4. GMPLS Extensions for G.Sup43 . . . . . . . . . . . . . . . . . 4 5. Generalized Label Request . . . . . . . . . . . . . . . . . . 4 5.1. Traffic Parameters . . . . . . . . . . . . . . . . . . . . 4 5.1.1. Signal Type (ST) . . . . . . . . . . . . . . . . . . . 5 5.1.2. Number of Multiplexed Components (NMC) . . . . . . . . 6 6. Generalized Label . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Label Space . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Label Distribution Rules . . . . . . . . . . . . . . . . . 11 7. RSVP-TE Signaling Protocol Extensions . . . . . . . . . . . . 11 8. Interworking Considerations . . . . . . . . . . . . . . . . . 11 9. Example of Generalized Label . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 13. Normative References . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Fu, et al. Expires May 13, 2010 [Page 2] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 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]. [RFC3473] describes the RSVP-TE-specific formats and mechanisms needed to support all four classes of interfaces. [RFC4328] describes the technology details that are specific to G.709 Optical Transport Networks (OTN) as defined in ITU-T G.709 recommendation [ITUT-G709]. This document extends the concepts presented in [RFC4328] with the technology details introduced by ITU-T G.709 Amendment 3 and G.sup43 supplement. 2. 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]. 3. GMPLS Extension for G.709 Amendment 3 G.709 Amendment 3 and G.sup43 introduce new signal types in the two layers constituting the digital transport hierarchy: - Optical Channel Transport Unit (OTUk): . OTU4 - Optical Channel Data Unit (ODUk): . ODU0 . ODU2e . ODU3e1 . ODU3e2 . ODU4 . ODUflex It also adds a new 1,25 Gbps Tributary Slot (TS) granularity for both the new and the old ODUk signals. [ITUT-G709-AMD3] introduces ODU4 mapping into OTU4 (and its related Fu, et al. Expires May 13, 2010 [Page 3] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 100Gbps optical channel), and new ODUk multiplexing. It refers to the multiplexing of ODUj (j = 0, 1, 2, 2e, 3, and flex) into an ODUk (k > j) signal, in particular: o ODU0 into ODU1 multiplexing o ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS granularity) o ODU0, ODU1, ODUflex, ODU2 and ODU2e into ODU3 multiplexing (with 1.25Gbps TS granularity) o ODU0, ODU1, ODU2, ODU3, ODU2e, ODUflex into ODU4 multiplexing (with 1.25Gbps TS granularity) o ODU2e into ODU3e1 multiplexing (with 2,5Gbps TS granularity) o ODU2e into ODU3e2 multiplexing (with 1,25Gbps TS granularity) 4. GMPLS Extensions for G.Sup43 G.Sup43 introduces two new types of signal: ODU3e1 and ODU3e2. These extension are not normative with respect the ITU-T standardization process. IETF needs to decide if these non normative ITU-T extensions need to be included in the scope of IETF works. In the rest of this ID we will highlight what is normative and what is not with respect to ITU-T process. What is referred to G.Sup43 will be indicated with [NN] tag in the text. 5. Generalized Label Request The Generalized Label Request as defined in [RFC3471], includes a common part (i.e. used for any switching technology) and a technology dependent part (i.e. the traffic parameters). Both parts have been extended by [RFC4328] in order to accommodate GMPLS signaling to the G.709 transport plane recommendation (see [ITUT-G.709]) All these extensions are still valid for G.709 Amendment 3 and G.Sup43 and only the technology dependent part is further extended to accommodate GMPLS signaling to the new signals introduced by G.709 Amendment 3 and G.Sup43. 5.1. Traffic Parameters The G.709 traffic parameters are defined as follows in [RFC4328] Section 3.2: Fu, et al. Expires May 13, 2010 [Page 4] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type | Reserved | NMC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NVC | Multiplier (MT) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Generalized label request and traffic parameters In this frame, NMC stands for Number of Multiplexed Components, NVC for Number of Virtual Components and MT for Multiplier. Each of these fields is tailored to support G.709 LSP requests. The RSVP-TE encoding of the G.709 traffic-parameters is detailed in [RFC4328] Section 6. [ITUT-G709-AMD3] defines new signals and Digital Path layer multiplexing combinations, therefore, the Signal Type and Number of Multiplexed Components fields need to be extended. 5.1.1. Signal Type (ST) This field (8 bits) indicates the type of G.709 Elementary Signal that comprises the requested LSP. Since G.709 Amendment 3 and G.Sup43 defines new ODUk and OCh layers, additional Signal Type code- points for G.709 Amendment 3 are defined to enlarge the existing ST code-point defined in [RFC4328]. Following is the Signal Type extended for G.709 Amendment 3 and G.sup43. Values from 0 to 8 are defined in [RFC4328]. The size of OPU2 and OPU3 tributary slots which are define in [RFC4328] is 2.5G. Fu, et al. Expires May 13, 2010 [Page 5] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 Value Type ----- ---- 0 Not significant 1 ODU1 (i.e., 2.5 Gbps) 2 ODU2 (i.e., 10 Gbps) 3 ODU3 (i.e., 40 Gbps) 4 Reserved (for future use) 5 Reserved (for future use) 6 OCh at 2.5 Gbps 7 OCh at 10 Gbps 8 OCh at 40 Gbps 9 OCh at 100 Gbps 10 ODU0 11 ODU2e 12 ODUflex 13 ODU4 14-255 Reserved (for future use) 5.1.2. Number of Multiplexed Components (NMC) The NMC values difined for G.709 Amendment 3 and G.sup43 are as follows: Fu, et al. Expires May 13, 2010 [Page 6] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 NMC Description --- ----------- 1 ODU0 is mapped into 1.25G tributary slots of OPU1. 1 ODU0 is mapped into 1.25G tributary slots of OPU2. 1 ODU0 is mapped into 1.25G tributary slots of OPU3. 1 ODU0 is mapped into 1.25G tributary slots of OPU4. 1 ODU1 is mapped into 2.5G tributary slots of OPU2. 1 ODU1 is mapped into 2.5G tributary slots of OPU3. 2 ODU1 is mapped into 1.25G tributary slots of OPU2. 2 ODU1 is mapped into 1.25G tributary slots of OPU3. 2 ODU1 is mapped into 1.25G tributary slots of OPU4. 4 ODU2 is mapped into 2.5G tributary slots of OPU3. 8 ODU2 is mapped into 1.25G tributary slots of OPU3. 8 ODU2 is mapped into 1.25G tributary slots of OPU4. 9 ODU2e is mapped into 1.25G tributary slots of OPU3. 8 ODU2e is mapped into 1.25G tributary slots of OPU4. 8 ODU2e is mapped into 1.25G tributary slots of OPU3e2. 4 ODU2e is mapped into 2.5G tributary slots of OPU3e1. 31 ODU3 is mapped into 1.25G tributary slots of OPU4. 1-8 ODUflex is mapped into 1.25G tributary slots of OPU2. 1-32 ODUflex is mapped into 1.25G tributary slots of OPU3. 1-80 ODUflex is mapped into 1.25G tributary slots of OPU4. 6. Generalized Label 6.1. Label Space At the Digital Path layer (i.e. ODUk layers), G.709, G.709 Amendment 3 and G.sup43 define seven different client payload bit rates. An Optical Data Unit (ODU) frame has been defined for each of these bit rates. ODUk refers to the frame at bit rate k, where k =0 (for 1.25 Gpbs), k = 1 (for 2.5 Gbps), 2 (for 10 Gbps), 2e for (10.25 Gbps), 3 (for 40 Gbps), 4 (for 100 Gbps) or flex (for 1.25*ts). In addition to the support of ODUk mapping into OTUk, the G.709 label space supports the sub-levels of ODUk multiplexing. ODUk multiplexing refers to multiplexing of ODUj (j = 0, 1, 2, 2e, 3, 3e1,3e2 and flex) into an ODUk (k > j). Following is the ODUk label format for the G.709 Amendment 3 and G.sup43. Fu, et al. Expires May 13, 2010 [Page 7] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserve | t4 | t3 | t2 |t1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Label Format for G.709 Amendment 3 and G.sup43 The specification of the fields t1, t2, t3 and t4 self-consistently characterizes the ODUk label space. The value space for the t1, t2, t3 and t4 fields is defined as follows: 1. t1 (2-bit): * t1=[1..2] indicates the tributary slot (t1th) used by the ODU0 in an ODTUG1 (via ODTU01) mapped into an ODU1 (via OPU1). ODU0 is mapped into 1.25G tributary slots of OPU1. * t1 is not significant for the other ODUk signal types (i.e., t1 value MUST be set to 0 and ignored). 2. t2 (5-bit): * t2=[1..8] indicates the tributary slot (t2th) used by the ODU0 in an ODTUG2 (via ODTU02) mapped into an ODU2 (via OPU2). ODU0 is mapped into 1.25G tributary slots of OPU2. * t2=[9..16] indicates the tributary slot (t2th-8) used by the ODU1 in an ODTUG2 (via ODTU12) mapped into an ODU2 (via OPU2). ODU1 is mapped into 1.25G tributary slots of OPU2. Two labels need to be allocated for one ODU1 connection. They may be continuous or non-continuous. * t2=[17..24] indicates the tributary slot (t2th-16) used by the ODUflex in an ODTUG2 (via ODTU2.ts) mapped into an ODU2 (via OPU2). ODUflex is mapped into 1.25G tributary slots of OPU2. How many labels need to be allocated for one ODUflex connection is based on transport of a particular physical layer client. The number of label is determined by the NMC value. They may be continuous or non-continuous. * t3=31 indicates an ODU2e sinal that is not further sub- divided. Two control planes controlling G.sup43 network elements which will be interworked should base on this Generalized Label format. * t2 is not significant for the other ODUk signal types (i.e., t2 value MUST be set to 0 and ignored). Fu, et al. Expires May 13, 2010 [Page 8] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 3. t3 (8-bit): * t3=[1..32] indicates the tributary slot (t3th) used by the ODU0 in an ODTUG3 (via ODTU03) mapped into an ODU3 (via OPU3). ODU0 is mapped into 1.25G tributary slots of OPU3. * t3=[33..64] indicates the tributary slot (t3th-32) used by the ODU1 in an ODTUG3 (via ODTU13) mapped into an ODU3 (via OPU3). ODU1 is mapped into 1.25G tributary slots of OPU3. Two labels need to be allocated for one ODU1 connection. They may be continuous or non-continuous. * t3=[65..96] indicates the tributary slot (t3th-64) used by the ODU2 in an ODTUG3 (via ODTU23) mapped into an ODU3 (via OPU3). ODU2 is mapped into 1.25G tributary slots of OPU3. Eight labels need to be allocated for one ODU2 connection. They may be continuous or non-continuous. * t3=[97..128] indicates the tributary slot (t3th-96) used by the ODU2e in an ODTUG3 (via ODTU3.ts) mapped into an ODU3 (via OPU3). ODU2e is mapped into 1.25G tributary slots of OPU3. Nine labels need to be allocated for one ODU2e connection. They may be continuous or non-continuous. * t3=[129..160] indicates the tributary slot (t3th-128) used by the ODUflex in an ODTUG3 (via ODTU3.ts) mapped into an ODU3 (via OPU3). ODUflex is mapped into 1.25G tributary slots of OPU3. How many labels needs to be allocated for one ODUflex connection is based on transport of a particular physical layer client. The number of label is determined by the NMC value. They may be continuous or non-continuous. * t3=[161..176] indicates the tributary slot (t5th-160) used by the ODU2e in an ODTUG3e1 (via ODTU2e3e1) mapped into an ODU3e1 (via OPU3e1). ODU2e is mapped into 2.5G tributary slots of OPU3e1. Four labels need to be allocated for one ODU2e connection. They may be continuous or non-continuous. [NN] The mapping of ODU2e into four 2.5G tributary slots is defined in the non normative G.sup43. Two control planes controlling G.sup43 network elements which will be interworked should base on this Generalized Label format. * t3=[177..208] indicates the tributary slot (t5th-176) used by the ODU2e in an ODTUG3e2 (via ODTU2e3e2) mapped into an ODU3e2 (via OPU3e2). ODU2e is mapped into 1.25G tributary slots of OPU3e2. Eight labels need to be allocated for one ODU2e connection.[NN] Fu, et al. Expires May 13, 2010 [Page 9] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 The mapping of ODU2e into eight 1.25G tributary slots is defined in the non normative G.sup43. Two control planes controlling G.sup43 network elements which will be interworked should base on this Generalized Label format. * t3 is not significant for the other ODUk signal types (i.e., t3 value MUST be set to 0 and ignored). 4. t4 (9-bit): * t4=1 indicates an ODU4 signal that is not further sub-divided. * t4=[2..81] indicates the tributary slot (t4th-1) used by the ODU0 in an ODTUG4 (via ODTU4.1) mapped into an ODU4 (via OPU4). ODU0 is mapped into 1.25G tributary slots of OPU4. * t4=[82..161] indicates the tributary slot (t4th-81) used by the ODU1 in an ODTUG4 (via ODTU4.2) mapped into an ODU4 (via OPU4). ODU1 is mapped into 1.25G tributary slots of OPU4. Two labels need to be allocated for one ODU1 connection. They may be continuous or non-continuous. * t4=[162..241] indicates the tributary slot (t4th-161) used by the ODU2 in an ODTUG4 (via ODTU4.8) mapped into an ODU4 (via OPU4). ODU2 is mapped into 1.25G tributary slots of OPU4. Eight labels need to be allocated for one ODU2 connection. They may be continuous or non-continuous. * t4=[242..321] indicates the tributary slot (t4th-241) used by the ODU2e in an ODTUG4 mapped into an ODU4 (via OPU4). ODU2e is mapped into 1.25G tributary slots of OPU4. Eight labels need to be allocated for one ODU2e connection. They may be continuous or non-continuous. * t4=[322..401] indicates the tributary slot (t4th-321) used by the ODUflex (via ODTU4.ts) in an ODTUG4 mapped into an ODU4 (via OPU4). ODUflex is mapped into 1.25G tributary slots of OPU4. How many labels needs to be allocated for one ODUflex connection is based on transport of a particular physical layer client. The number of label is determined by the NMC value. They may be continuous or non-continuous. * t4=[402..481] indicates the tributary slot (t4th-401) used by the ODU3 (via ODTU4.32) in an ODTUG4 mapped into an ODU4 (via OPU4). ODU3 is mapped into 1.25G tributary slots of OPU4. Tirty-one labels need to be allocated for one ODU3 connection. They may be continuous or non-continuous. Fu, et al. Expires May 13, 2010 [Page 10] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 * t4 is not significant for the other ODUk signal types (i.e., t4 value MUST be set to 0 and ignored). 6.2. Label Distribution Rules Label distribution rules are defined in [RFC4328] Section 4.2. 7. RSVP-TE Signaling Protocol Extensions RSVP-TE will reuse the protocol extensions defined in [RFC4328] Section 6 and does not need to be further extended. When a node receives a Generalized Label Request, it can infer the label format from the Signal Type and NMC pair. It don't need to depend on any other means (e.g., management configuration or auto-discocvery). Following is the example how to infer label format. Signal Type NMC Label Format ODU0 * [New Label Format] ODU2e * [New Label Format] ODUflex * [New Label Format] ODU4 * [New Label Format] ODU1 2 ----->[New Label Format] ODU2 8 [New Label Format] ODU3 31 [New Label Format] ODU1 1 [RFC4328] ODU2 4 [RFC4328] ODU1 0 [RFC4328] ODU2 0 [RFC4328] ODU3 0 [RFC4328] Instead when a non G.709 Amendment 3 aware node receives a Generalized Label Request for a signals introduced in [ITUT-G709- AMD3], it will not support the requested Signal Type and/or NMC values. Then the receiver node MUST generate a PathErr message with a "Traffic Control Error/Service unsupported" indication (see [RFC2205]) as specified in [RFC4328]. 8. Interworking Considerations ODU multiplex structure of G.709(200303) only supports 2.5G TS. ODU multiplex structure of G.709 Amd3 can support 1.25G TS or 2.5G TS and 1.25G TS. In terms of G.709 Amd 3, HO OPU2 and HO OPU3 interface ports supporting 1.25 TS must also support the 2.5 TS mode for interworking with interface ports supporting only the 2.5G TS mode. When a 1.25G TS capable equipment receive the OPUk signal whose Payload Type is 2.5G TS multiplex structure from the far end, it Fu, et al. Expires May 13, 2010 [Page 11] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 shall operate in 2.5G TS mode. It should be an automatic adaptataion process. There must be some considerations on interworking between G.709(200303) and G.709 Amd3 in the perspective of control plane. Control plane designed for G.709 Amendment 3 should have the ability to synchronously process the different Generalized Label format of ODU1, ODU2 and ODU3 defined in [RFC4328] and this document. The extension defined in this document is a supplement and extension of [RFC4328]. 1. When a new Path (Resv) message is to be sent for a downstream (upstream) TE link, the format of Generalized Label is determined by the Signal Type and/or multiplex structure of this port. * If the Signal Type is ODU0, ODU2e, ODUflex or ODU4, the format of Generalized Label must be based on this document. * If the Signal Type is ODU1, ODU2 or ODU3 and the port is operated only in 2.5G TS mode or directly mapping into OTU1, OTU2 or OTU3, the format of Generalized Label must be based on RFC4328. * If the Signal Type is ODU1, ODU2 or ODU3 and the port is operated only in 1.25G TS or 2.5G TS and 1.25G TS mode, the format of Generalized Label is bases on the operated mode of far-end interface port of this link. The tributary slot size can be carried in the Interface Switching Capability Descriptor(s) and one LSR can use its TED to determine the ISCD of far-end. Then it can know the tributary slot size of far-end. It shoud not depend on any configuration and discovery function. If the LSR could not know the tributary slot size of far-end, it should try 1.25G TS mode firstly and the format of Generalized Label is based on new format. When a LSR receives a Generalized Label Request and could not support the requested Signal Type and/or NMC values. It must generate a PathErr including the crankback information with a "Traffic Control Error/Service unsupported" indication. Then the ingress node will attemp to singal again with the same routing. So this node will try 2.5G TS operated mode and the format of Generalized Label is based on RFC4328. Fu, et al. Expires May 13, 2010 [Page 12] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 2. When a new Path (Resv) message is to be received on a upstream (downstream) TE link, the Generalized Label format is identified by the Signal Type and NMC pair in Traffic Parameters. * When the Signal Type and NMC pair is (ODU1, 2), (ODU2, 8) or (ODU3, 31), the format of Generalized Label should be based on this document, the node must check the interface port mode. If it can not support 1.25G TS mode or the Signal Type and NMC, the Path (Resv) message will be terminated, and a PathErr message including the crankback information with a "Traffic Control Error/Service unsupported" indication must be generated. * When the Signal Type and NMC pair is (ODU1, 1), (ODU1, 0), (ODU2, 4), (ODU2, 0), or (ODU3, 0), the format of Generalized Label should be based on [RFC4328]. In this case the receiver will always support this label format. If it can not support this Signal Type and NMC, the Path (Resv) message will be terminated, and a PathErr message including the crankback information with a "Traffic Control Error/Service unsupported" indication must be generated. * When a downstream (upstream) node receives Path (Resv) message in which Signal Type is ODU0, ODU2e, ODUflex and ODU4, it must identify the Generalized Label format based on this document. If it can not support this Signal Type, the Path (Resv) message will be terminated, and a PathErr message including the crankback information with a "Traffic Control Error/ Service unsupported" indication must be generated. Following figure is a interworking example between G.709(200303) and G.709 Amd 3. 4*2.5G TS 32*1.25G TS 80*1.25G TS 16*2.5G TS 8*1.25G TS | | | | | | | | | | \|/ \|/ \|/ \|/ \|/ +----+ OTU2 +----+ OTU3 +----+ OTU4 +----+ OTU3 +----+ OTU2 +----+ -|DXC1|------|DXC2|------|DXC3|------|DXC4|-------|DXC5|-------|DXC6|- +----+ +----+ +----+ +----+ +----+ +----+ Figure 2: Interworking Scenario between G.709(200303) and G.709 Amd3 When we need to setup a ODU2 (10G bandwidth) LSP between DXC1 and DXC6, the path computation entiy may computate an DXC1-DXC2-DXC3- DXC4-DXC5-DXC6 route. Fu, et al. Expires May 13, 2010 [Page 13] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 1. In the case of one end-to-end session, the NMC has to be changed in node where the TE link supporting 1.25G TS and the TE link supporting 2.5G TS are connected (i.e., DXC2, DXC4, and DXC5). +----+ +----+ +----+ +----+ +----+ +----+ -|DXC1|------|DXC2|------|DXC3|------|DXC4|-------|DXC5|-------|DXC6|- +----+ +----+ +----+ +----+ +----+ +----+ Path Path Path Path Path -------> ------> ------> -------> -------> ST=ODU2 ST=ODU2 ST=ODU2 ST=ODU2 ST=ODU2 NMC=4 NMC=8 NMC=8 NMC=4 NMC=8 Resv Resv Resv Resv Resv <------- <------ <------ <------- <------- ST=ODU2 ST=ODU2 ST=ODU2 ST=ODU2 ST=ODU2 NMC=4 NMC=8 NMC=8 NMC=4 NMC=8 Figure 3: Contiguous TE LSP 2. The end-to-end connection also can be setuped with multiple segment session (i.e., ODU1 LSP1, ODU1 LSP2, ODU1 LSP3, ODU1 LSP4). +----+ +----+ +----+ +----+ +----+ +----+ -|DXC1|------|DXC2|------|DXC3|------|DXC4|-------|DXC5|-------|DXC6|- +----+ +----+ +----+ +----+ +----+ +----+ | | | | | |<-ODU1 LSP1->|<-----ODU1 LSP2------>|<-ODU1 LSP3->|<-ODU1 LSP4->| Figure 4: Stitching TE LSP if the segment LSP can be created and prepaired for stitching by signaling, the end-to-end connection is stitched to several segment LSPs (i.e., ODU1 LSP1, ODU1 LSP2, ODU1 LSP3, ODU1 LSP4). The NMC in traffic parameters of this end-to-end session is no meaning. 9. Example of Generalized Label The following examples are given in order to illustrate the processing described in this document. 1. ODU2e in OTU2e mapping or ODU4 in OTU4 mapping: when one ODU2e (ODU4) signal is directly transported in an OTU2e (OTU4),the upstream node requests results simply in an ODU2e (ODU4) signal request. Fu, et al. Expires May 13, 2010 [Page 14] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 In such conditions, the downstream node has to return a unique label because the ODU2e (ODU4) is directly mapped into the corresponding OTU2e (OTU4). Because a single ODUk signal is requested, the downstream node has to return a single ODUk label, which can be, for instance, one of the following: - Signal type=ODU4, t4=1, t3=0, t2=0, t1=0; indicates a single ODU4 mapped into an OTU4 - Signal type=ODU2e, t4=0, t3=0, t2=31, t1=0; indicates a single ODU2e mapped into an OTU2e 2. ODU0 into ODUk multiplexing (k = 1, 2, 3 or 4): when one ODU0 is multiplexed into the payload of a structured ODU1 (ODU2, ODU3 or ODU4), the upstream node requests results simply in an ODU0 signal request. In such conditions, the downstream node has to return a unique label because the ODU0 is multiplexed into one ODTUG1 (ODTUG2, ODTUG3 or OTDUG4). The latter is then mapped into the ODU1 (ODU2, ODU3 or ODU4) via OPU1 (OPU2, OPU3 or OPU4) and then mapped into the corresponding OTU1 (OTU2, OTU3 or OTU4). Because a single ODU0 multiplexed signal is requested (Signal Type = ODU0 and NMC = 1), the downstream node has to return a single ODU0 label, which can take, for instance, one of the following values: - t4=0, t3=0, t2=0, t1=1; indicates the ODU0 in the 1st TS of the ODTUG1 - t4=0, t3=0, t2=4, t1=0; indicates the ODU0 in the 4th TS of the ODTUG2 - t4=0, t3=26, t2=0, t1=0; indicates the ODU0 in the 26th TS of the ODTUG3 - t4=69, t3=0, t2=0, t1=0; indicates the ODU0 in the 68th TS of the ODTUG4 3. ODU1 into 1.25G tributary slots of OPUk (k = 2, 3, 4) multiplexing: when one ODU1 is multiplexed into the payload of a structured ODU2 (ODU3 or ODU4), the upstream node requests results simply in an ODU1 signal request. In such conditions, the downstream node has to return two labels because the ODU1 is multiplexed into one ODTUG2 (ODTUG3 or ODTUG4). The latter is then mapped into the ODU2 (ODU3 or ODU4) via OPU2 (OPU3 or OPU4) and then mapped into the corresponding Fu, et al. Expires May 13, 2010 [Page 15] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 OTU2 (OTU3 or OTU4). Because a single ODU1 multiplexed signal is requested (Signal Type = ODU1 and NMC = 2), the downstream node has to return two ODU1 labels, which can take, for instance, the following values: - t4=0, t3=0, t2=13, t1=0; indicates the ODU1 in the 5th 1.25G TS of the ODTUG2 or - t4=0, t3=58, t2=0, t1=0; indicates the ODU1 in the 26th 1.25G TS of the ODTUG3 or - t4=82, t3=0, t2=0, t1=0; indicates the ODU1 in the 1st 1.25G TS of the ODTUG4 4. ODU2 into 1.25G tributary slots of OPU3: when one ODU2 is multiplexed into the payload of a structured ODU3, the upstream node requests results simply in an ODU2 signal request. In such conditions, the downstream node has to return eight labels because the ODU2 is multiplexed into one ODTUG3. The latter is then mapped into the ODU3 via OPU3 and then mapped into the corresponding OTU3. Because a single ODU1 multiplexed signal is requested (Signal Type = ODU2 and NMC = 8), the downstream node has to return eight ODU2 labels, which can take, for instance, the following values: - t4=0, t3=67, t2=0, t1=0; indicates the ODU2 in the 3rd 1.25G TS of the ODTUG3 - t4=0, t3=73, t2=0, t1=0; indicates the ODU2 in the 9th 1.25G TS of the ODTUG3 - t4=0, t3=82, t2=0, t1=0; indicates the ODU2 in the 18th 1.25G TS of the ODTUG3 5. ODU2/ODU2e into ODU4 multiplexing: when one ODU2 (or ODU2e) is multiplexed into the payload of a structured ODU4, the upstream node requests results simply in an ODU2 (or ODU2e) signal request. In such conditions, the downstream node has to return eight labels because the ODU2 (ODU2e) is multiplexed into one ODTUG4. The latter is then mapped into the ODU4 via OPU4 and then mapped into the corresponding OTU4. Because a single ODU2 (or ODU2e) Fu, et al. Expires May 13, 2010 [Page 16] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 multiplexed signal is requested (Signal Type = ODU2 and NMC = 8 or Signal Type = ODU2e and NMC = 8), the downstream node has to return eight ODU2 (or ODU2e) labels, one of which can take, for instance, the following values: - Signal type=ODU2, t4=182, t3=0, t2=0, t1=0; indicates the ODU2 in the 21st TS of the ODTUG4 - Signal type=ODU2e, t4=320, t3=0, t2=0, t1=0; indicates the ODU2e in the 79th TS of the ODTUG4 6. ODU3 into ODU4 multiplexing: when one ODU3 is multiplexed into the payload of a structured ODU4, the upstream node requests results simply in an ODU3 signal request. In such conditions, the downstream node has to return thirty-two labels because the ODU3 is multiplexed into one ODTUG4. The latter is then mapped into the ODU4 via OPU4 and then mapped into the corresponding OTU4. Because a single ODU3 multiplexed signal is requested (Signal Type = ODU3 and NMC = 31), the downstream node has to return thirty-one ODU3 labels, one of which can take, for instance, the following values: - t4=408, t3=0, t2=0, t1=0; indicates the ODU3 in the 7th TS of the ODTUG4 - t4=449, t3=0, t2=0, t1=0; indicates the ODU3 in the 48th TS of the ODTUG4 - t4=472, t3=0, t2=0, t1=0; indicates the ODU3 in the 71st TS of the ODTUG4 7. ODU2e into 1.25G tributary slots of OPU3: when one ODU2e is multiplexed into the payload of a structured ODU3, the upstream node requests results simply in an ODU2e signal request. In such conditions, the downstream node has to return nine labels because the ODU2e is multiplexed into one ODTUG3. The latter is then mapped into the ODU3 via OPU3 and then mapped into the corresponding OTU3. Because a single ODU2e multiplexed signal is requested (Signal Type = ODU2e and NMC = 9), the downstream node has to return nine ODU2e labels, one of which can take, for instance, the following values: Fu, et al. Expires May 13, 2010 [Page 17] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 - t4=0, t3=100, t2=0, t1=0; indicates the ODU2e in the 4th 1.25G TS of the ODTUG3 - t4=0, t3=112, t2=0, t1=0; indicates the ODU2e in the 16th 1.25G TS of the ODTUG3 - t4=0, t3=120, t2=0, t1=0; indicates the ODU2e in the 24th 1.25G TS of the ODTUG3 8. [NN]-ODU2e into ODU3e1 multiplexing: when one ODU2e is multiplexed into the payload of a structured ODU3e1, the upstream node requests results simply in an ODU2e signal request. In such conditions, the downstream node has to return four labels because the ODU2e is multiplexed into one ODTUG3e1. The latter is then mapped into the ODU3e1 via OPU3e1 and then mapped into the corresponding OTU3e1. Because a single ODU2e multiplexed signal is requested (Signal Type = ODU2e and NMC = 4), the downstream node has to return four ODU2e labels, which can take, for instance, the following values: - t4=0, t3=161, t2=0, t1=0; indicates the ODU2e in the 1st TS of the ODTUG3e1 - t4=0, t3=166, t2=0, t1=0; indicates the ODU2e in the 6th TS of the ODTUG3e1 - t4=0, t3=170, t2=0, t1=0; indicates the ODU2e in the 10th TS of the ODTUG3e1 - t4=0, t3=175, t2=0, t1=0; indicates the ODU2e in the 15th TS of the ODTUG3e1 9. [NN]-ODU2e into ODU3e2 multiplexing: when one ODU2e is multiplexed into the payload of a structured ODU3e2, the upstream node requests results simply in an ODU2e signal request. In such conditions, the downstream node has to return eight labels because the ODU2e is multiplexed into one ODTUG3e2. The latter is then mapped into the ODU3e2 via OPU3e2 and then mapped into the corresponding OTU3e2. Because a single ODU2e multiplexed signal is requested (Signal Type = ODU2e and NMC = 8), the downstream node has to return eight ODU2e labels, one of which can take, for instance, the following values: Fu, et al. Expires May 13, 2010 [Page 18] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 - t4=0, t3=181, t2=0, t1=0; indicates the ODU2e in the 5th TS of the ODTUG3e2 - t4=0, t3=197, t2=0, t1=0; indicates the ODU2e in the 21st TS of the ODTUG3e2 - t4=0, t3=207, t2=0, t1=0; indicates the ODU2e in the 31st TS of the ODTUG3e2 10. ODUflex is mapped into 1.25G tributary slots of OPU2 (OPU3 or OPU4). when one ODUflex is multiplexed into the payload of a structured ODU2 (ODU3 or ODU4), the upstream node requests results simply in an ODUflex signal request. In such conditions, the downstream node has to return some labels whose number is determined in terms of NMC value. Because the ODUflex is multiplexed into one ODTUG2 (ODTUG3 or ODTUG4). The latter is then mapped into the ODU2 (ODU3 or ODU4) via OPU2 (OPU3 or OPU4) and then mapped into the corresponding OTU2 (OTU3 or OTU4). Because a single ODUflex multiplexed signal is requested (Signal Type = ODUflex), the downstream node has to return some labels (i.e., the number of labels is NMC), which can take, for instance, the following values: - t4=0, t3=0, t2=21, t1=0; indicates the ODUflex in the 5th 1.25G TS of the ODTUG2 or - t4=0, t3=150, t2=0, t1=0; indicates the ODUflex in the 22nd 1.25G TS of the ODTUG3 or - t4=368, t3=0, t2=0, t1=0; indicates the ODUflex in the 47th 1.25G TS of the ODTUG4 10. Security Considerations The procedures described in this document rely completely on RSVP-TE messages and mechanism. The use of H bit set in Admin Status Object basically informs the receiving entity that no operations are to be done over Data Plane as consequence of such special signaling flow. Using specially flagged signaling messages we want to limit the function of setup and tear down messages to Control Plane, making them not effective over related Data Plane resource usage. So, no additional or special issues are arisen by adopting this procedure, Fu, et al. Expires May 13, 2010 [Page 19] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 that aren't already brought up by the use of the same messages, without H bit setting, for LSP control. For RSVP-TE Security please refer to [RFC3473]. 11. IANA Considerations TBD. 12. Acknowledgments The RFC text was produced using Marshall Rose's xml2rfc tool. 13. Normative References [ITUT-G709] ITU-T, "Interface for the Optical Transport Network (OTN)", G.709 Recommendation (and Amendment 1) , October 2001. [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. [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006. [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008. Fu, et al. Expires May 13, 2010 [Page 20] Internet-Draft GMPLS Extension for Evolutive OTN November 2009 Authors' Addresses Xihua Fu ZTE Corporation West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District Xi An 710065 P.R.China Phone: +8613798412242 Email: fu.xihua@zte.com.cn URI: http://wwwen.zte.com.cn/ Ming Ke ZTE Corporation 3F,R&D Building 3,ZTE Industrial Park,XiLi LiuXian Road Nanshan District,Shenzhen 518055 P.R.China Phone: +86 755 26773914 Email: ke.ming@zte.com.cn Yuanlin Bao ZTE Corporation 5F,R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road Nanshan District,Shenzhen 518055 P.R.China Phone: +86 755 26773731 Email: bao.yuanlin@zte.com.cn Fu, et al. Expires May 13, 2010 [Page 21]