Network Working Group Fatai Zhang Internet Draft Dan Li Category: Standards Track JIanrui Han Huawei Han Li CMCC Expires: April 2010 October 16, 2009 Framework for GMPLS and PCE Control of G.709 Optical Transport Networks draft-zhang-ccamp-gmpls-g709-framework-00.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/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 April 16, 2010. Abstract This document provides a framework for applying Generalized Mulit- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of G.709 Optical Transport Networks (OTN) as specified in the ITU-T G.709 recommendation, including the enhanced functionality in the recently consented revision. zhang Expires April 2010 [Page 1] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 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 are to be interpreted as described in [RFC2119]. Table of Contents 1. Introduction...................................................3 2. Terminology....................................................4 3. G.709 Optical Transport Network (OTN)..........................4 3.1. OTN Layer Network.........................................4 3.1.1. Analogue Layer.......................................6 3.1.1.1. Optical channel Layer network (OCh).............6 3.1.1.2. Optical multiplex section layer network (OMS)...6 3.1.1.3. Optical transmission section layer network (OTS)7 3.1.2. Digital layer........................................7 3.1.2.1. Optical channel transport unit (OTU)............7 3.1.2.2. Optical channel data unit (ODUk)................7 3.1.2.3. Optical channel payload unit (OPUk).............8 3.2. Mapping/Multiplexing......................................8 3.2.1. Mapping..............................................9 3.2.1.1. Mapping of client signals.......................9 3.2.1.2. Other mapping relationships.....................9 3.2.2. Multiplexing.........................................9 3.2.2.1. ODUk Time-Division Multiplex....................9 3.2.2.1.1. Tributary Slot introduction...............10 3.2.2.1.2. Multiplexing Hierarchy....................11 3.2.2.1.3. Tributary Slot allocation.................11 3.2.2.1.4. Tributary Port Number assignment..........13 3.2.2.2. ODUflex........................................13 3.2.2.3. Wavelength division multiplex..................13 4. Connection management in OTN..................................13 4.1. Connection management of OCh.............................14 4.2. Connection management of ODU.............................14 5. GMPLS/PCE Implications........................................19 5.1. Implications for LSP Hierarchy with GMPLS TE.............19 5.2. Implications for GMPLS Signaling.........................19 5.2.1. Identifying OTN signals.............................20 5.2.2. Tributary Port Number assignment....................21 5.3. Implications for GMPLS Routing...........................21 5.3.1. Requirement for conveying Interface Switching Capability specific information.....................21 5.4. Implications for Auto-discovery..........................22 5.4.1. Discovering the Granularity of the TS...............22 5.4.2. Discovering the Supported LO ODU Signal Types.......23 zhang Expires April 2010 [Page 2] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 5.5. Implications for PCE.....................................23 6. Security Considerations.......................................23 7. IANA Considerations...........................................23 8. Acknowledgments...............................................23 9. References....................................................24 9.1. Normative References.....................................24 9.2. Informative References...................................24 10. Author's Addresses...........................................25 1. Introduction OTN is becoming a mainstream support technology for the backbone transport network and the metropolitan core transport layer. It is desirable for operators to introduce control plane such as Generalized Multi-Protocol Label Switching (GMPLS) to the OTN networks, because GMPLS can improve the network reliability through restoration mechanisms (e.g., resist multiple failures) and resource usage efficiency through mesh-shared. GMPLS extends MPLS to encompass time division multiplexing (TDM) networks (e.g., SONET/SDH, PDH, and G.709 digital wrapper), lambda switching optical networks, and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). [RFC3945] provides the architecture of GMPLS. For GMPLS networks, signaling, routing and link management are the basic modules. The signaling function and Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are described in [RFC3471] and [RFC3473]. The routing extensions and OSPF extensions are described in [RFC4202] and [RFC4203]. The link management protocol is described in [RFC4204]. The existing GMPLS protocol suite can provide the basic principle for GMPLS control of OTN networks. However, there is some difference between normal TDM networks (e.g., SDH/Sonet) and OTN networks (especially for OTN digital wrapper), because some new features are introduce recently in ITU-T, for example, various multiplexed structure, two types of Tributary Slot (i.e., 1.25Gbps and 2.5Gbps) and the ODUk definition has been extended to include the ODUflex function. Therefore, this document reviews the OTN technology and provides a framework for applying GMPLS and PCE architecture to the control of OTN networks. Note that G.709 OTN can be divided into two layers roughly, which are digital wrapper layer and wavelength layer, in this document, it only zhang Expires April 2010 [Page 3] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 focuses on digital wrapper layer and wavelength layer is out of the scope. Please refer to [WSON-Frame] for further information. 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. G.709 Optical Transport Network (OTN) This section provides an overview of G.709 Optical Transport Network based on ITU-T G.709 related recommendations. [ITUT-G872] describes the functional architecture of optical transport networks providing optical signal transmission, multiplexing, routing, supervision, performance assessment, and network survivability. [ITUT-G709] defines the interfaces of the optical transport network to be used within and between subnetworks of the optical network. With the evolution and deployment of G.709 technology many new features are defined in ITU-T recommendations. For example, ODU0, ODU2e, ODU4 containers and ODUflex are described in [G709-V3], ODU3e1, ODU3e2 are described in [Gsup43]. The purpose of this section is to provide some background and basic reference about OTN technology and then determine how the current GMPLS protocol suit and the PCE architecture can be accommodated to encompass the OTN. For the detailed OTN related technical information please refers to the ITU-T recommendations. 3.1. OTN Layer Network The basic structure of OTN is shown in Figure 1. Three layer networks are illustrated which include optical channel layer (OCh), section layers: OMSn (Optical Multiplex section) and OTNn (Optical Transmission Section), and single channel section layer: OPSn (optical physical section). OCh substructure indicated by Figure 1 consists of - Analogue layer (OCh/OChr): The optical channel with full (OCh) or reduced functionality (OChr), which provides transparent network connections between 3R regeneration points in the OTN. - Digital layer (OTU): The completely or functionally standardized optical channel transport unit (OTUk/OTUkV) which provides zhang Expires April 2010 [Page 4] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 supervision and conditions the signal for transport between 3R regeneration points in the OTN. - Digital layer (ODU/OPU): The optical channel data unit (ODUk) which provides: o tandem connection monitoring (ODUkT); o end-to-end path supervision (ODUkP); and o adaptation of client signals via the Optical Channel Payload Unit (OPUk) Client (e.g., STM-N, ATM, IP, Ethenet, MPLS, ...) | | | | +-------+------+-----+-----+-----+------+--------+.......... | | LO OPUk | | ^ | +- - - - - - - - - - - - - - - -+ | | | / ODUkP | | | LO ODUk< - - - - - - - - - - - - - - - - - - - + | | \ ODUkT | +-------+-------------------------------+--------+ OCh | | HO OPUk | | | +- - - - - - - - - - - - - - - -+ | Sub- | / ODUkP | structure | HO ODUk< - - - - - - - - - - - - - - - - - - - + | \ ODUkT | | +-------+-------+---+-------+-------+---+--------+ | | OTUkV | OTUk | | OTUkV | OTUk | | OTUk | | +-------+-------+ +-------+-------+ .+--------+.....V.... | OCh | | OChr | . | | +---------------+...+---------------+. | | | OMSn | | | | OPSMnk | +---------------+ | OPSn | | | | OTSn | | | | | +-------+-------+ +-------+-------+ +---+----+ | | | OTM-n.m OTM-0.m, OTM-0.mvm OTM-nr.m Full Reduced Multi Lane, functionality functionality Reduced OTM interface OTM interface functionality OTM interface zhang Expires April 2010 [Page 5] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 Client (e.g., STM-N, ATM, IP, Ethenet, MPLS, ...) | | | | +-------+------+-----+-----+-----+------+--------+.......... | | LO OPUk | | ^ | +- - - - - - - - - - - - - - - -+ | | | / ODUkP | OCh | LO ODUk< - - - - - - - - - - - - - - - - - - - + Sub- | \ ODUkT | structure +-------+-------+---+-------+-------+---+--------+ | | OTUkV | OTUk | | OTUkV | OTUk | | OTUk | | +-------+-------+ +-------+-------+ .+--------+.....V.... | OCh | | OChr | . | | +---------------+...+---------------+. | | | OMSn | | | | OPSMnk | +---------------+ | OPSn | | | | OTSn | | | | | +-------+-------+ +-------+-------+ +---+----+ | | | OTM-n.m OTM-0.m, OTM-0.mvm OTM-nr.m Full Reduced Multi Lane, functionality functionality Reduced OTM interface OTM interface functionality OTM interface Figure 1 OTN layers 3.1.1. Analogue Layer 3.1.1.1. Optical channel Layer network (OCh) The OCh transports a digital client signal between 3R regeneration points. The OCh client signals defined in [ITUT-G709] are the OTUk signals. Optical Transport Module (OTM-n.m, OTM-nr.m, OTM-0.m, OTM- 0.mvn) is described in [ITUT-G709] in detail. 3.1.1.2. Optical multiplex section layer network (OMS) The OMS provides the transport of optical channels through an optical multiplex section trail between access points. zhang Expires April 2010 [Page 6] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 3.1.1.3. Optical transmission section layer network (OTS) The optical transmission section layer network provides for the transport of an optical multiplex section through an optical transmission section trail between access points. 3.1.2. Digital layer 3.1.2.1. Optical channel transport unit (OTU) The OTUk conditions the ODUk for transport over an optical channel network connection. Currently, the following OTUk types are defined: OTU1, OTU2, OTU3, OTU4, OTU2e, OTU3e1, OTU3e2. OTUk has a bandwidth/bit rate BR and a bit rate tolerance T i.e. OTU(BR,T). The detailed bit rates and tolerance of the OTUk signals are defined in [ITUT-G709], [Gsup43] and [G709-V3]. 3.1.2.2. Optical channel data unit (ODUk) The optical channel data unit (ODUk) provides adaptation of client signals via the Optical Channel Payload Unit (OPUk) LO ODU (Lower order ODU) can be multiplexed into HO ODU (higher order ODU), which is described in section 3.2.2. Currently, the following ODUk types are defined: ODU0, ODU1, ODU2, ODU3, ODU4, ODU2e, ODUflex, ODU3e1, ODU3e2. ODUk has a bandwidth/bit rate BR and a bit rate tolerance T i.e. ODU(BR,T). The detailed bit rates and tolerance of the ODUk signals (except ODUflex) are defined in [ITUT-G709], [Gsup43] and [G709-V3]. The bitrate and tolerance of the ODUflex is dependent on the client signal. HO ODUk types are: ODU1, ODU2, ODU3, ODU4, ODU3e1, ODU3e2. LO ODUk types are: ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4, ODUflex. ODU3e1 and ODU3e2 can be treated as LO ODU signals outside the domain in which these signals terminate. zhang Expires April 2010 [Page 7] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 3.1.2.3. Optical channel payload unit (OPUk) The OPUk encapsulates the Client signal (e.g. SONET/SDH, Ethernet bit/codeword streams, Ethernet VLANs) and fulfils any rate justification that is needed. It is mapped at the source, demapped at the sink, and not modified by the network. Currently, the following OPUk types are defined: OPU0, OPU1, OPU2, OPU3, OPU4, OPU2e, OPUflex, OPU3e1, OPU3e2. OPUk has a bandwidth/bit rate BR and a bit rate tolerance T i.e. OPU(BR,T). The detailed bit rates and tolerance of the OPUk signals are defined in [ITUT-G709], [Gsup43] and [G709-V3]. 3.2. Mapping/Multiplexing From the perspective of digital and analogue layers, there are two processes for the mapping and multiplexing. One process is that a (non-OTN) client signal is mapped into a lower order OPU, which will be mapped into the associated LO ODU. The LO ODU signal can be either mapped into the associated OTU[V] signal, or into an ODTU, which will be multiplexed into an ODTU Group (ODTUG). The ODTUG signal is mapped into a higher order OPU, and the HO OPU signal is then mapped into the associated HO ODU, which will be mapped into the associated OTU[V]. Therefore a LO ODU may be carried either directly over an OCh or over a HO ODU. A HO ODU may be treated in a second domain as a LO ODU, and be mapped in that domain in to an ODTU. For interworking with OTN networks based on the 2003 version of G.709, this mapping of a HO ODU into another HO ODU may occur within one domain for the cases of ODU0 -> ODU1 -> ODU2, ODU0 -> ODU1 -> ODU3, ODU0 -> ODU2 -> ODU3 and ODUflex -> ODU2 -> ODU3. The other process is that an OTU[V] signal is mapped either into an Optical Channel signal (i.e., OCh and OChr), or into an OTLk.n. The OCh/OChr signal is mapped into an Optical Channel Carrier (i.e., OCC and OCCr). The OCC/OCCr signal is multiplexed into an OCC Group, identified as OCG-n.m and OCG-nr.m. The OCG-n.m signal is mapped into an OMSn. The OMSn signal is mapped into an OTSn. The OTSn signal is presented at the OTM-n.m interface. The OCG-nr.m signal is mapped into an OPSn. The OPSn signal is presented at the OTM-nr.m interface. A single OCCr signal is mapped into an OPS0. The OPS0 signal is presented at the OTM-0.m interface. The OTLk.n signal is mapped into an Optical Transport Lane Carrier, identified as OTLC. The OTLC zhang Expires April 2010 [Page 8] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 signal is multiplexed into an OTLC Group, identified as OTLCG. The OTLCG signal is mapped into an OPSMnk. The OPSMnk signal is presented at the OTM-0.mvn interface. The detailed multiplexing and mapping structures are described in [ITUT-G709], [Gsup43] and [G709-V3]. 3.2.1. Mapping There are several kinds of mapping. For example, the client signal or an Optical channel Data Tributary Unit Group (ODTUGk) is mapped into the OPUk. The OPUk is mapped into an ODUk and the ODUk is mapped into an OTUk[V]. The OTUk[V] is mapped into an OCh[r] and the OCh[r] is then modulated onto an OCC[r]. 3.2.1.1. Mapping of client signals OPUk supports mapping of various of client signals like CBR2G5, CBR10G, CBR10G3, CBR10G3 and CBR40G signals, ATM cell stream, GFP encapsulated IP, MPLS, Ethernet packet/frame streams, test signal, fibre channel, etc, which are described in [ITUT-G709] in more detail. 3.2.1.2. Other mapping relationships OTN supports other mapping like ODUj into ODTUjk or ODTUk.ts, ODTU into OPUk, etc. which are described in [ITUT-G709] and [G709-V3] in more detail. 3.2.2. Multiplexing OTN has a multi stage multiplexing capability including one or more TDM stages and one WDM stage which are introduced in the following sections. 3.2.2.1. ODUk Time-Division Multiplex LO ODU can be multiplexed into HO ODU, the process is as follows: LO ODU signal is mapped into an ODTU, which will be multiplexed into an ODTU Group (ODTUG). And then the ODTUG signal is mapped into a higher order OPU, which then is mapped into the associated HO ODU. In this process, multiplexing an ODTU into an OPU is realized by means of the mapping of the ODTU signal in one or several OPU Tributary Slots. This section is only concerned about multiplexing zhang Expires April 2010 [Page 9] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 process not mapping process. This section describes the means of Tributary Slot allocation when multiplexing LO ODU into HO ODU. 3.2.2.1.1. Tributary Slot introduction The OPUk is divided in a number of Tributary Slots (TS) and these Tributary Slots are interleaved within the OPUk. There are two types of Tributary Slots: 1. Tributary Slot with a bandwidth of approximately 2.5 Gbps introduced in [ITUT-G709]; an OPUk is divided in n Tributary Slots, numbered 1 to n. 2. Tributary Slot with a bandwidth of approximately 1.25 Gbps introduced in [G709-V3]; an OPUk is divided in 2n Tributary Slots, numbered 1 to 2n. Equipment supporting a 1.25Gbps TS structure for OPU2 or OPU3 must be backward compatible with equipment which supports only the 2.5G TS structure. Specific Tributary Slots must be combined together (e.g., combination of TS#i and TS#i+4 on an HO ODU2 link) for the LO ODU at one end of the HO ODU link which supports the 1.25Gbps TS structure, so that the LO ODU can be carried on the HO ODU link correctly. In the following example, suppose that the two ends of an ODU2 or ODU3 link support different TS structure, where node A supports the 1.25Gbps TS structure, while node B supports the 2.5Gbps TS, as shown in the figure below: +-----+ +-----+ | | | | | A +-------ODU2/ODU3 link-------+ B | | | | | +-----+ +-----+ (Support 1.25G TS) (Support 2.5G TS) o In case of ODU1 multiplexing into ODU2, node A maps the ODU1 into the TS#i and TS#i+4 (where i<=4) (with the granularity of 1.25Gbps) of OPU2, so that node B can retrieve the ODU1 from the TS#i (with the granularity of 2.5Gbps) of the OPU2, and vice versa. o In case of ODU1 multiplexing into ODU3, node A maps the ODU1 into the TS#i and TS#i+16 (where i<=16) (with the granularity of zhang Expires April 2010 [Page 10] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 1.25Gbps) of OPU3, so that node B can retrieve the ODU1 from the TS#i (with the granularity of 2.5Gbps) of the OPU3, and vice versa. o In case of ODU2 multiplexing into ODU3, node A maps the ODU2 into the TS#a/TS#a+16, TS#b/TS#b+16, TS#c/TS#c+16 and TS#d/TS#d+16 (where a j) signal can be depicted as follows: - ODU0 into ODU1 multiplexing (with 1,25Gbps TS granularity) - ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS granularity) - ODU1 into ODU2 multiplexing (with 2.5Gbps TS granularity) - ODU0, ODU1, ODU2, ODU2e and ODUflex into ODU3 multiplexing (with 1.25Gbps TS granularity) - ODU1, ODU2 into ODU3 multiplexing (with 2.5Gbps TS granularity) - ODU0, ODU1, ODU2, ODU2e, ODU3 and ODUflex into ODU4 multiplexing (with 1.25Gbps TS granularity) - ODU2e into ODU3e1 multiplexing (with 2.5Gbps TS granularity) - ODU0, ODU1, ODU2, ODU2e, ODUflex into ODU3e2 multiplexing (with 1.25Gbps TS granularity) 3.2.2.1.3. Tributary Slot allocation When LO ODUj (e.g., ODU0, ODU1, ODU2, ODU3, etc.) at different rate is multiplexed into HO ODUk, it will need different amount of tributary slots to be allocated in OPUk. And when LO ODUj at a certain rate is multiplexed into HO ODUk, it will also need different amount of tributary slots with different TS granularity to be allocated in OPUk. Allocations of TS numbers for different cases are show as follows: zhang Expires April 2010 [Page 11] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 - ODU0 into ODU1, ODU2, ODU3, ODU3e2 or ODU4 multiplexing with 1,25Gbps TS granularity o ODU0 occupies 1 of the 2, 8, 32, 32 or 80 TS for ODU1, ODU2, ODU3, ODU3e2 or ODU4 - ODU1 into ODU2, ODU3, ODU3e2 or ODU4 multiplexing with 1,25Gbps TS granularity o ODU1 occupies 2 of the 8, 32, 32 or 80 TS for ODU2, ODU3, ODU3e2 or ODU4 - ODU1 into ODU2, ODU3 multiplexing with 2.5Gbps TS granularity o ODU1 occupies 1 of the 4 or 16 TS for ODU2 or ODU3 - ODU2 into ODU3, ODU3e2 or ODU4 multiplexing with 1.25Gbps TS granularity o ODU2 occupies 8 of the 32, 32 or 80 TS for ODU3, ODU3e2 or ODU4 - ODU2 into ODU3 multiplexing with 2.5Gbps TS granularity o ODU2 occupies 4 of the 16 TS for ODU3 - ODU3 into ODU4 multiplexing with 1.25Gbps TS granularity o ODU3 occupies 32 of the 80 TS for ODU4 - ODUflex into ODU2, ODU3, ODU3e2 or ODU4 multiplexing with 1.25Gbps TS granularity o ODUflex occupies n of the 8, 32, 32 or 80 TS for ODU2, ODU3, ODU3e2 or ODU4 (n <= Total TS numbers of ODUk) - ODU2e into ODU3, ODU3e2 or ODU4 multiplexing with 1.25Gbps TS granularity o ODU2e occupies 9 of the 32 TS for ODU3, 8 of the 80 TS for ODU3e2, or 8 of the 32 TS for ODU4 - ODU2e into ODU3e1 multiplexing with 2.5Gbps TS granularity o ODU2e occupies 8 of the 32 TS for ODU3e1 zhang Expires April 2010 [Page 12] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 3.2.2.1.4. Tributary Port Number assignment TBD. 3.2.2.2. ODUflex ODUk has a bandwidth/bit rate BR and a bit rate tolerance T i.e. ODU(BR,T). Compared with ODU0, ODU1, ODU2, ODU3, ODU4 and ODU2e, ODUflex has a bandwidth which is locked to the CBR client signal's bandwidth or which is configurable for case of GFP encapsulated packet/frame streams. This is a new feature of OTN specified in [G709-V3]. That is, for ODUflex, BR and T are not predefined. ODUflex is transported by mapping into n (n <= Total TS numbers of OPUk) tributary slots of an OPUk (of a HO ODUk) for k>=1. The value of n depends on the BR, T of ODUflex and the BR, T of the ODU2/ODU3/ODU3e2/ODU4 which ODUflex will be multiplexed into. For example, for multiplexing the ODUflex at a certain rate like ODUflex (2.5G, +/-20ppm), it will need 3 of the 8 TS into ODU2, but it will only need 2 of the 32 TS into ODU3. 3.2.2.3. Wavelength division multiplex Up to n (n>=1) OCC[r] are multiplexed into an OCG-n[r].m using wavelength division multiplexing. The OCG-n[r].m is transported via the OTM-n[r].m. For the case of the full functionality OTM-n.m interfaces the OSC is multiplexed into the OTM-n.m using wavelength division multiplexing. 4. Connection management in OTN There are four main layers in OTN: (1) OMSn/OTSn and OPSn layers (2) OCh layer (3) HO ODU layer, (4) LO ODU layer. As [ITUT-G872] described, OTN-based transport network equipment is concerned with control of connectivity of ODU paths and optical channels and not with control of connectivity of the client layer. So this document focuses on the connection management of LO and HO ODU paths and optical channel paths. This section provides the overview of management of two layers: OCh and ODU (both LO and HO). zhang Expires April 2010 [Page 13] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 4.1. Connection management of OCh In the general case of limited or no wavelength converters, an OCh connection request needs a light path from source to destination. This path computation is known as the Routing and Wavelength Assignment (RWA) problem [HZang00]. In the case of full wavelength converters at each node, OCh path computation is equivalent to a circuit-switch TDM network with full time slot interchange capability. The control of connectivity of optical channels is within the scope of WSON (Wavelength Switched Optical Networks) ongoing working in CCAMP Working Group in IETF. OCh connections are managed as part of the LO and HO ODU connection set up. OCh connections do not exist outside the scope of a LO or HO ODU in the OTN. 4.2. Connection management of ODU As described above, LO ODUj can be either mapped into the associated OTUk signal (k = j), or multiplexed to HO ODUk (k > j), and HO ODUk is mapped into an OTUk, and the OTUk is mapped into an OCh. In the case of LO ODUj mapping into OTUk (k = j), Figure 2 give an example of this kind of LO ODU connection. In Figure 2, The LO ODUj is switched at the intermediate ODXC node. From the viewpoint of connection management, when a LO ODU connection is setup, the OTUk and OCh connections are setup correspondingly; i.e. the OTU/OCh connection set up is slaved to the LO ODU connection set up. The management of this OTUk is similar to ODU. LO ODUj and OCh/OTUk have client/server relationships. For example, one LO ODU1 connection can be setup between Node A and Node C. When there is no HO ODU supported ODU1 links available, this LO ODU1 connection is to be supported by OCh/OTU1 connections, which are to be set up between Node A and Node B and between Node B and Node C. LO ODU1 can be mapped into OTU1 at Node A, demapped from it in Node B, switched at Node B, and then mapped into the next OTU1 and demapped from this OTU1 at Node C. zhang Expires April 2010 [Page 14] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 | LO ODUj | +------------------------------(b)---------------------------+ | | OCh/OTUk | | OCh/OTUk | | | +--------(a)---------+ +--------(a)---------+ | | | | | | | +------++-+ +--+---+--+ +-++------+ | |EO| |OE| |EO| |OE| | | +--+----------------+--+ +--+----------------+--+ | | ODXC | | ODXC | | ODXC | +---------+ +---------+ +---------+ Node A Node B Node C Figure 2 Connection of LO ODUk (1) In the case of LO ODUj multiplexing into HO ODUk, Figure 3 gives an example of this kind of LO ODU connection. In Figure 3, OCh, OTUk, HO ODUk are associated with each other. The LO ODUj is multiplexed/de-multiplexed into/from the HO ODU at each ODXC node and switched at each ODXC node (i.e. trib port to line port, line card to line port, line port to trib port). From the viewpoint of connection management, when a LO ODU connection is setup, it will be using the existing HO ODUk (/OTUk/OCh) connections which have been set up prior to the LO ODU service request. Those HO ODUk connections provide LO ODU links, of which the LO ODU connection manager requests a link connection to support the LO ODU connection. LO ODUj and OCh/OTUk/HO ODUk have client/server relationships. For example, one HO ODU2 (/OTU2/OCh) connection can be setup between Node A and Node B, another HO ODU3 (/OTU3/OCh) connection can be setup between Node B and Node C prior to any LO ODU service requests. LO ODU1 can be generated at Node A, switched to one of the 10G line ports and multiplexed into a HO ODU2 at Node A, demultiplexed from the HO ODU2 at Node B, switched at Node B to one of the 40G line ports and multiplexed into HO ODU3 at Node B, demultiplexed from HO ODU3 at Node C and switched to its LO ODU1 terminating port at Node C. zhang Expires April 2010 [Page 15] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 | LO ODUj | +----------------------------(b)-----------------------------+ | | OCh/OTUk/HO ODUk | | OCh/OTUk/HO ODUk | | | +--------(a)---------+ +---------(a)--------+ | | | | | | | +------++-+ +--+---+--+ +-++------+ | |EO| |OE| |EO| |OE| | | +--+----------------+--+ +--+----------------+--+ | | ODXC | | ODXC | | ODXC | +---------+ +---------+ +---------+ Node A Node B Node C Figure 3 Connection of LO ODUk (2) Figure 4 gives another example which is kind of a hybrid case. In this case, a LO ODUj is set up via an OTUk/OCh (k = j) connection between Node A and Node B and via one or more tributary slots in an existing HO ODUk (/OTUk/OCh)(k > j) connection between Node B and Node C. The OTUk/OCh connection between Node A and Node B must be set up as part of the LO ODUj connection set up. A LO ODUj link connection must be instantiated within the HO ODUk between Node B and Node C. A LO ODU2 can be generated at Node A, switched to one of the 10G line ports and mapped into an OTU2/OCh at Node A, demapped from the OTU2 at Node B, switched at Node B to one of the 40G line ports and multiplexed into HO ODU3 at Node B, demultiplexed from HO ODU3 at Node C and switched to its LO ODU2 terminating port at Node C. | LO ODUj | +----------------------------(b)-----------------------------+ | | OCh/OTUj | | OCh/OTUk/HO ODUk | | | +--------(c)---------+ +--------(a)---------+ | | | | | | | +------++-+ +--+---+--+ +-++------+ | |EO| |OE| |EO| |OE| | | +--+----------------+--+ +--+----------------+--+ | | ODXC | | ODXC | | ODXC | +---------+ +---------+ +---------+ Node A Node B Node C Figure 4 Connection of LO ODUk (3) The LO ODUj connection request (b) in Figure 2 generates OTUk/OCh connection requests (a) as a consequence. zhang Expires April 2010 [Page 16] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 Prior to any LO ODUj connection request, network planning/engineering will generate connection requests (a) in figure 3 for the creation of HO ODUk/OTUk/OCh connections. Afterwards a LO ODUj connection request (b) will make use of the LO ODU link bandwidth provided by those HO ODUk connections. Prior to any LO ODUj connection request, network planning/engineering will generate connection request (a) in figure 4 for the creation of the HO ODUk/OTUk/OCh connection. Afterwards a LO ODUj connection request (b) will make use of the LO ODU link bandwidth provided by this HO ODUk connection. In addition, the LO ODUj connection request (b) generates an OTUk/OCh connection request (c) to cross the OCh subnetwork between nodes A and B. So Connection Management should consider how to manage these different LO ODU, HO ODU, OTU and OCh connections within the OTN. As agreed in Q.12/15 each ODU layer (LO ODU, HO ODU) will have visibility into the OCh layer to enable ODU connection set up through a mix of subwavelength and wavelength links and matrices. For the connection indicated by (b) in Figure 2-4, this LO ODUk is a client of the connections indicated by (a) and (c). There are many Levels at different rates for LO ODUk (e.g., ODUflex, ODU0, ODU1, ODU2, ODU3, etc.). Each LO ODUk may share the same server Higher ODUk. For example, in Figure 5, LO ODU1 and LO ODU2 share the same server Higher ODU3. From the viewpoint of layer connection, a simpler representation is to describe the LO ODU as a single layer network, in which the bit rate of a client is a parameter. This representation shows a single topology containing (OTUk/OCh/OMSn/OTSn, OTUk/OChr/OPSn and HO ODUk/OTUk/OCh supported) LO ODU links and subnetworks (i.e. resources) that is shared by all client ODU signals. | LO ODU2 | <-----------------(b)-----------------> | LO ODU1 | | | <---------------(b)-|------------------> | | |OCh/OTU1| ||OCh/OTU3/HO ODU3 | |OCh/OTU2| | | +---(a)--+ |+-----(a)-------+ | +---(a)--+ | | | | || | | | | | +-++-+ +--+---+-++ +-++---+--+ +-++-+ | |3R| |3R| |3R| |3R| |3R| |3R| | | +--+--------+--+ +--+---------------+--+ +--+--------+--+ | |ODXC| | ODXC | | ODXC | |ODXC| +----+ +---------+ +---------+ +----+ Node A Node B Node C Node D Figure 5 Connection of LO ODUk (4) zhang Expires April 2010 [Page 17] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 The path computation for LO ODU is to select a suitable route through the network using available LO wavelength and sub-wavelength ODU links and matrices, allocate on sub-wavelength LO ODU links one or more tributary slots of the Higher Order OPU to the LO ODU link connection and allocate on wavelength LO ODU links one wavelength to the LO ODU link connection. The path computation for HO ODU is to select a suitable route through the network using available HO wavelength and sub-wavelength ODU links and matrices, allocate on sub-wavelength HO ODU links one or more tributary slots to the HO ODU link connection and allocate on wavelength HO ODU links one wavelength to the HO ODU link connection. OTM-0.m and OTM-0.mvn connections support a single OTUk and a single ODUk link connection. LO ODU or HO ODU path computation can select such OTM-0 support LO ODU or HO ODU link, in which case the full capacity is allocated to the LO or HO ODU link connection. Take the following Figure 6 as an example, the single topology containing links and matrices can be illustrated as follows: LO ODU Link #1: HO ODU2, support transport of ODU0, ODU1, ODU2; LO ODU Link #2: HO ODU3, support transport of ODU0, ODU1, ODU2, ODU3; LO ODU Link #3: HO ODU2, support transport of ODU0, ODU1, ODU2; LO ODU Link #4: HO ODU1, support transport of ODU0; LO ODU Link #5: HO ODU1, support transport of ODU0; LO ODU Matrix A LO ODU Matrix B LO ODU Matrix C LO ODU Matrix D LO ODU Matrix E If the LO ODUk (k = 0) connection from A to D is requested, two paths may be feasible. One alternative is A-> Link #1 -> B -> Link #2 -> C -> Link #3 -> D. Along this path, LO ODU0 is multiplexed into HO ODU2, and then transported along Link #1 to Node B where it is zhang Expires April 2010 [Page 18] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 demultiplexed from the HO ODU, switched through LO ODU Matrix B and then multiplexed onto Link #2 to go to Node C. At Node C the LO ODU0 is demultiplexed, switched through LO ODU Matrix C and then multiplexed onto Link #3 to go to Node D. At Node D the LO ODU0 is demultiplexed from the HO ODU, switched through LO ODU Matrix D and then terminated. Link #5 +--+---+--+ Link #4 +--------------------------+3R| |3R+--------------------------+ | +--+ +--+ | | | ODXC | | | +---------+ | | Node E | | | +-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++ |3R| |3R|Link #1 |3R| |3R|Link #2 |3R| |3R|Link #3 |3R| |3R| +--+ +--+--------+--+ +--+--------+--+ +--+--------+--+ +--+ | ODXC | | ODXC | | ODXC | | ODXC | +---------+ +---------+ +---------+ +---------+ Node A Node B Node C Node D Figure 6 Example of connection LO ODU 5. GMPLS/PCE Implications 5.1. Implications for LSP Hierarchy with GMPLS TE The path computation for LO ODU connection request is based on the topology of ODU layer, including OCh layer visibility. The OTN path computation can be divided into two layers as described in section 4. One layer is OCh/OTUk/ODUk, the other is LO ODU. [RFC4206] defines the mechanisms to accomplish creating the hierarchy of LSPs. The LSP management of multiple layers in OTN can follow the procedures defined in [RFC4206] and related MLN drafts. As discussed in section 4, the route path computation for OCh is in the scope of WSON [WSON-Frame]. Therefore, this document only considers ODU layer for LO ODU connection request since the OCh layer is being discussed in WSON scope [WSON-Frame]. 5.2. Implications for GMPLS Signaling The signaling function and Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are described in [RFC3471] and [RFC 3473]. For OTN-specific control, [RFC4328] defines signaling extensions to support G.709 Optical Transport Networks Control. zhang Expires April 2010 [Page 19] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 However, with the evolution of OTN, there are some new features introduced in ITU-T, for example, ODU0, ODU2e, ODU4 and ODUflex. Therefore, it is obvious that [RFC4328] can not support these new features of OTN from control plane perspective, and it should be updated or replaced to support the evolution of OTN. 5.2.1. Identifying OTN signals [RFC4328] defines the LSP Encoding Type, the Switching Type and the Generalized Protocol Identifier (Generalized-PID) constituting the common part of the Generalized Label Request. And the G.709 Traffic Parameters are also defined in [RFC4328]. But some new features for the evolving OTN has been introduced since [RFC4328] released. This new features are summarized as follows: (1) New signal types of digital wrapper layer a) Optical Channel Transport Unit (OTUk) - OTU4 - OTU2e - OTU3e1 - OTU3e2 b) Optical Channel Data Unit (ODUk): - ODU0 - ODU2e - ODU3e1 - ODU3e2 - ODU4 - ODUflex (2) A new Tributary Slot (TS) granularity (i.e., 1.25 Gbps) (3) Signal type with variable bandwidth: zhang Expires April 2010 [Page 20] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 ODUflex has a variable bandwidth/bit rate BR and a bit rate tolerance T. Different bandwidth may need different numbers of tributary slots allocation when this kind of connection setup. Therefore, bit rate and bit rate tolerance should be carried in the Traffic Parameter in the signaling of connection setup request. (4) New multiplexing hierarchy (For example, ODU0 into ODU1 multiplexing (with 1,25Gbps TS granularity).) So [RFC4328] needs to be updated to support all the signal types and related mapping and multiplexing with all kinds of tributary slots. Moreover, the extensions should consider the scalability to match future evolvement of OTN. For item (1) and (3), new traffic parameters may need to be extended in signaling message; For item (2) and (4), new label should be defined to carry the exact label allocation information. 5.2.2. Tributary Port Number assignment TBD. 5.3. Implications for GMPLS Routing As discussed in section 4.2.2, path computation element should select a suitable route for LO ODU connection request and then allocate one or more Higher Order OPU tributary slots. In order to compute the suitable path (including tributary slots allocation) correctly, routing protocol should be extended to convey some information to represent ODU TE topology. GMPLS Routing [RFC4202] defines Interface Switching Capability Descriptor of TDM which can be used for ODU. However, some other issues should also be considered which are discussed below. 5.3.1. Requirement for conveying Interface Switching Capability specific information Interface Switching Capability Descriptors present a new constraint for LSP path computation. [RFC4203] defines the switching capability and related Maximum LSP Bandwidth and the Switching Capability specific information. When the Switching Capability field is TDM the Switching Capability specific information field includes Minimum LSP zhang Expires April 2010 [Page 21] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 Bandwidth, an indication whether the interface supports Standard or Arbitrary SONET/SDH, and padding. So routing protocol should be extended when TDM is ODU type to support representation of ODU switching information. As discussed in section 3.2.2.1.3, many types of ODUj can be multiplexed the same ODUk. For example, both ODU0 and ODU1 can be multiplexed into ODU2. One ODU link may support one or more types of ODU signals multiplexing. The routing protocol should be extended to carry this multiplexing capability. As discussed in section 3.2.2.1.4, one type of ODUj can be multiplexed to one ODUk by different tributary slots. For example, ODU1 can be multiplexed into ODU2 with either 2.5Gbps TS granularity or 1.25G TS granularity. The routing protocol should be extended to carry which TS granularity supported by the ODU interface. Moreover, Total bandwidth of the TE link, Unreserved Bandwidth of the TE link, Maximum LSP Bandwidth, Min LSP Bandwidth, etc., which are Switching Capability specific information for OTN should be carried by routing protocol extensions for allocation of tributary slots. 5.4. Implications for Auto-discovery As discussed in section 5.3, Path computation needs to know the interface switching capability of links. The switching capability of two ends of the link may be different, so the link capability of two ends should be discovered. [RFC4204] defines the link management protocol which is part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) links. [RFC4204] can be a good candidate to be extended to implement the auto-discovery of link capability for OTN networks. 5.4.1. Discovering the Granularity of the TS As discussed in section 3.2.2.1.1, the two ends of an ODU link may support different TS structure. In that case, the LO ODU must be mapped into specific combined Tributary Slots in the end of link with TS of 1.25Gbps. For example, if the local end can support 1.25Gbps and the remote end can support 2.5Gbps, and then the local end should imitate 2.5Gbps. In order to reserve TS resources correctly for a LO ODU connection, the control plane of the two ends MUST know which granularity the other end can support before creating the LO ODU connection. zhang Expires April 2010 [Page 22] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 Therefore, it is necessary for the two ends of a link to discover the granularity of the TS. 5.4.2. Discovering the Supported LO ODU Signal Types Many new ODU signal types are introduced by [Gsup43] and [G709-V3], such as ODU0, ODU4, ODU2e, ODU3e1, ODU3e2 and ODUflex. It is possible that equipment does not always support all the LO ODU signal types introduced by those new standards or drafts. If one end of an HO ODU link can not support a certain LO ODU signal type, the HO ODU link can not be selected to carry such type of LO ODU connection. Therefore, it is necessary for the two ends of an HO ODU link to discover which types of LO ODU can be supported by the HO ODU link. After discovering, the capability information can be flooded by IGP, so that the correct path for an ODU connection can be calculated. 5.5. Implications for PCE [PCE-APS] describes the requirements for GMPLS applications of PCE in order to establish GMPLS LSP. PCE needs to consider the GMPLS TE attributes appropriately once a PCC or another PCE requests a path computation. The TE attributes which can be contained in the path calculation request message from the PCC or the PCE defined in [PCECP] includes switching capability, encoding type, signal type, etc. As described in section 5.2.1, new signal type and new signal with variable bandwidth information need to be carried in the extended signaling message of path setup. For the same consideration, PCECP also has a desire to be extended to carry the new signal type and related variable bandwidth information when a PCC requests a path computation. 6. Security Considerations TBD. 7. IANA Considerations TBD. 8. Acknowledgments We would like to thank Maarten Vissers and Malcolm Betts for their review and useful comments. zhang Expires April 2010 [Page 23] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 9. References 9.1. Normative References [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, Jan 2006. [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4202] K. Kompella, Y. Rekhter, Ed., " Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4206] K. Kompella, Y. Rekhter, Ed., " Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 9.2. Informative References [ITUT-G709] ITU-T, "Interface for the Optical Transport Network (OTN)," G.709 Recommendation, March 2003. [ITUT-G872] ITU-T, "Architecture of optical transport networks", November 2001 (11 2001). [Gsup43] ITU-T, "Proposed revision of G.sup43 (for agreement),", December 2008. [G709-V3] ITU-T, "Draft revised G.709, version 3,", consented by ITU-T on Oct 2009. [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing and wavelength assignment approaches for wavelength- routed optical WDM networks", Optical Networks Magazine, January 2000. zhang Expires April 2010 [Page 24] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 [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. [PCE-APS] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai Zhang, "Requirements for GMPLS applications of PCE", draft-ietf-pce-gmpls-aps-req-01.txt, July 2009. 10. Author's Addresses Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972912 Email: zhangfatai@huawei.com Dan Li Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28973237 Email: danli@huawei.com Jianrui Han Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972913 Email: hanjianrui@huawei.com Han Li China Mobile Communications Corporation 53 A Xibianmennei Ave. Xuanwu District Beijing 100053 P.R. China zhang Expires April 2010 [Page 25] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 Phone: +86-10-66006688 Email: lihan@chinamobile.com Intellectual Property The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. zhang Expires April 2010 [Page 26] draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009 Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement 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 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. zhang Expires April 2010 [Page 27]