Network Working Group Fatai Zhang, Ed. Internet Draft Dan Li Category: Informational Huawei Han Li CMCC S.Belotti Alcatel-Lucent D. Ceccarelli Ericsson Expires: March 9, 2012 September 9, 2011 Framework for GMPLS and PCE Control of G.709 Optical Transport Networks draft-ietf-ccamp-gmpls-g709-framework-05.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 March 9, 2012. Abstract This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Zhang Expires March 2012 [Page 1] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 Optical Transport Networks (OTN) as specified in ITU-T Recommendation G.709 as consented in October 2009. Table of Contents 1. Introduction .................................................. 2 2. Terminology ................................................... 3 3. G.709 Optical Transport Network (OTN) ......................... 4 3.1. OTN Layer Network ........................................ 4 3.1.1. Client signal mapping ............................... 5 3.1.2. Multiplexing ODUj onto Links ........................ 7 3.1.2.1. Structure of MSI information ................... 8 4. Connection management in OTN .................................. 9 4.1. Connection management of the ODU ........................ 10 5. GMPLS/PCE Implications ....................................... 12 5.1. Implications for LSP Hierarchy with GMPLS TE ............ 12 5.2. Implications for GMPLS Signaling ........................ 13 5.3. Implications for GMPLS Routing .......................... 16 5.4. Implications for Link Management Protocol (LMP) ......... 18 5.5. Implications for Path Computation Elements .............. 19 6. Data Plane Backward Compatibility Considerations ............. 20 7. Security Considerations ...................................... 20 8. IANA Considerations .......................................... 21 9. Acknowledgments .............................................. 21 10. References .................................................. 21 10.1. Normative References ................................... 21 10.2. Informative References ................................. 22 11. Authors' Addresses .......................................... 23 12. Contributors ................................................ 24 APPENDIX A: ODU connection examples ............................. 25 1. Introduction OTN has become a mainstream layer 1 technology for the transport network. Operators want to introduce control plane capabilities based on Generalized Multi-Protocol Label Switching (GMPLS) to OTN networks, to realize the benefits associated with a high-function control plane (e.g., improved network resiliency, resource usage efficiency, etc.). GMPLS extends MPLS to encompass time division multiplexing (TDM) networks (e.g., SONET/SDH, PDH, and G.709 sub-lambda), lambda switching optical networks, and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The GMPLS architecture is provided in [RFC3945], signaling function and Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are described in Zhang Expires March 2012 [Page 2] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 [RFC3471] and [RFC3473], routing and OSPF extensions are described in [RFC4202] and [RFC4203], and the Link Management Protocol (LMP) is described in [RFC4204]. The GMPLS protocol suite including provision [RFC4328] provides the mechanisms for basic GMPLS control of OTN networks based on the 2001 revision of the G.709 specification [G709-V1]. Later revisions of the G.709 specification, including [G709-V3], have included some new features; for example, various multiplexing structures, two types of TSs (i.e., 1.25Gbps and 2.5Gbps), and extension of the Optical Data Unit (ODU) ODUj definition to include the ODUflex function. This document reviews relevant aspects of OTN technology evolution that affect the GMPLS control plane protocols and examines why and how to update the mechanisms described in [RFC4328]. This document additionally provides a framework for the GMPLS control of OTN networks and includes a discussion of the implication for the use of the Path Computation Element (PCE) [RFC4655]. For the purposes of the control plane the OTN can be considered as being comprised of ODU and wavelength (OCh) layers. This document focuses on the control of the ODU layer, with control of the wavelength layer considered out of the scope. Please refer to [RFC6163] for further information about the wavelength layer. 2. Terminology OTN: Optical Transport Network ODU: Optical Channel Data Unit OTU: Optical channel transport unit OMS: Optical multiplex section MSI: Multiplex Structure Identifier TPN: Tributary Port Number LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4, flex.) represents the container transporting a client of the OTN that is either directly mapped into an OTUk (k = j) or multiplexed into a server HO ODUk (k > j) container. Zhang Expires March 2012 [Page 3] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, 4.) represents the entity transporting a multiplex of LO ODUj tributary signals in its OPUk area. ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a bit rate tolerance up to +/-100 ppm. 3. G.709 Optical Transport Network (OTN) This section provides an informative overview of those aspects of the OTN impacting control plane protocols. This overview is based on the ITU-T Recommendations that contain the normative definition of the OTN. Technical details regarding OTN architecture and interfaces are provided in the relevant ITU-T Recommendations. Specifically, [G872-2001] and [G872Am2] describe the functional architecture of optical transport networks providing optical signal transmission, multiplexing, routing, supervision, performance assessment, and network survivability. [G709-V1] 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 OTN technology many new features have been specified in ITU-T recommendations, including for example, new ODU0, ODU2e, ODU4 and ODUflex containers as described in [G709-V3]. 3.1. OTN Layer Network The simplified signal hierarchy of OTN is shown in Figure 1, which illustrates the layers that are of interest to the control plane. Other layers below OCh (e.g. Optical Transmission Section - OTS) are not included in this Figure. The full signal hierarchy is provided in [G709-V3]. Client signal | ODUj | OTU/OCh OMS Figure 1 - Basic OTN signal hierarchy Zhang Expires March 2012 [Page 4] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 Client signals are mapped into ODUj containers. These ODUj containers are multiplexed onto the OTU/OCh. The individual OTU/OCh signals are combined in the Optical Multiplex Section (OMS) using WDM multiplexing, and this aggregated signal provides the link between the nodes. 3.1.1. Client signal mapping The client signals are mapped into a Low Order (LO) ODUj. Appendix A gives more information about LO ODU. The current values of j defined in [G709-V3] are: 0, 1, 2, 2e, 3, 4, Flex. The approximate bit rates of these signals are defined in [G709-V3] and are reproduced in Tables 1 and 2. +-----------------------+-----------------------------------+ | ODU Type | ODU nominal bit rate | +-----------------------+-----------------------------------+ | ODU0 | 1 244 160 kbits/s | | ODU1 | 239/238 x 2 488 320 kbit/s | | ODU2 | 239/237 x 9 953 280 kbit/s | | ODU3 | 239/236 x 39 813 120 kbit/s | | ODU4 | 239/227 x 99 532 800 kbit/s | | ODU2e | 239/237 x 10 312 500 kbit/s | | | | | ODUflex for CBR | | | Client signals | 239/238 x client signal bit rate | | | | | ODUflex for GFP-F | | | Mapped client signal | Configured bit rate | +-----------------------+-----------------------------------+ Table 1 - ODU types and bit rates NOTE - The nominal ODUk rates are approximately: 2 498 775.126 kbit/s (ODU1), 10 037 273.924 kbit/s (ODU2), 40 319 218.983 kbit/s (ODU3), 104 794 445.815 kbit/s (ODU4) and 10 399 525.316 kbit/s (ODU2e). Zhang Expires March 2012 [Page 5] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 +-----------------------+-----------------------------------+ | ODU Type | ODU bit-rate tolerance | +-----------------------+-----------------------------------+ | ODU0 | +- 20 ppm | | ODU1 | +- 20 ppm | | ODU2 | +- 20 ppm | | ODU3 | +- 20 ppm | | ODU4 | +- 20 ppm | | ODU2e | +- 100 ppm | | | | | ODUflex for CBR | | | Client signals | +- 100 ppm | | | | | ODUflex for GFP-F | | | Mapped client signal | +- 100 ppm | +-----------------------+-----------------------------------+ Table 2 - ODU types and tolerance One of two options is for mapping client signals into ODUflex depending on the client signal type: - Circuit clients are proportionally wrapped. Thus the bit rate and tolerance are defined by the client signal. - Packet clients are mapped using the Generic Framing Procedure (GFP). [G709-V3] recommends that the bit rate should be set to an integer multiplier of the High Order (HO) Optical Channel Physical Unit (OPU) OPUk TS rate, the tolerance should be +/-100ppm, and the bit rate should be determined by the node that performs the mapping. [Editors' Note: As outcome of ITU SG15/q11 expert meeting held in Vimercate in September 2010 it was decided that a resizable ODUflex(GFP) occupies the same number of TS on every link of the path (independently of the High Order (HO) OPUk TS rate). Please see WD07 and the meeting report of this meeting for more information. The authors will update the above text related to Packet client mapping as soon as new version of G.709 will be updated accordingly with expert meeting decision reported here.] Zhang Expires March 2012 [Page 6] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 3.1.2. Multiplexing ODUj onto Links The links between the switching nodes are provided by one or more wavelengths. Each wavelength carries one OCh, which carries one OTU, which carries one ODU. Since all of these signals have a 1:1:1 relationship, we only refer to the OTU for clarity. The ODUjs are mapped into the TS of the OPUk. Note that in the case where j=k the ODUj is mapped into the OTU/OCh without multiplexing. The initial versions of G.709 [G709-V1] only provided a single TS granularity, nominally 2.5Gb/s. [G709-V3], approved in 2009, added an additional TS granularity, nominally 1.25Gb/s. The number and type of TSs provided by each of the currently identified OTUk is provided below: 2.5Gb/s 1.25Gb/s Nominal Bit rate OTU1 1 2 2.5Gb/s OTU2 4 8 10Gb/s OTU3 16 32 40Gb/s OTU4 -- 80 100Gb/s To maintain backwards compatibility while providing the ability to interconnect nodes that support 1.25Gb/s TS at one end of a link and 2.5Gb/s TS at the other, the 'new' equipment will fall back to the use of a 2.5Gb/s TS if connected to legacy equipment. This information is carried in band by the payload type. The actual bit rate of the TS in an OTUk depends on the value of k. Thus the number of TS occupied by an ODUj may vary depending on the values of j and k. For example an ODU2e uses 9 TS in an OTU3 but only 8 in an OTU4. Examples of the number of TS used for various cases are provided below: - ODU0 into ODU1, ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS granularity o ODU0 occupies 1 of the 2, 8, 32 or 80 TS for ODU1, ODU2, ODU3 or ODU4 - ODU1 into ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS granularity o ODU1 occupies 2 of the 8, 32 or 80 TS for ODU2, ODU3 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 Zhang Expires March 2012 [Page 7] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 - ODU2 into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity o ODU2 occupies 8 of the 32 or 80 TS for ODU3 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 31 of the 80 TS for ODU4 - ODUflex into ODU2, ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity o ODUflex occupies n of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4 (n <= Total TS numbers of ODUk) - ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity o ODU2e occupies 9 of the 32 TS for ODU3 or 8 of the 80 TS for ODU4 In general the mapping of an ODUj (including ODUflex) into the OTUk TSs is determined locally, and it can also be explicitly controlled by a specific entity (e.g., head end, NMS) through Explicit Label Control [RFC3473]. 3.1.2.1. Structure of MSI information When multiplexing an ODUj into a HO ODUk (k>j), G.709 specifies the information that has to be transported in-band in order to allow for correct demultiplexing. This information, known as Multiplex Structure Information (MSI), is transported in the OPUk overhead and is local to each link. In case of bidirectional paths the association between TPN and TS MUST be the same in both directions. The MSI information is organized as a set of entries, with one entry for each HO ODUj TS. The information carried by each entry is: Payload Type: the type of the transported payload. Tributary Port Number (TPN): the port number of the ODUj transported by the HO ODUk. The TPN is the same for all the TSs assigned to the transport of the same ODUj instance. Zhang Expires March 2012 [Page 8] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 For example, an ODU2 carried by a HO ODU3 is described by 4 entries in the OPU3 overhead when the TS size is 2.5 Gbit/s, and by 8 entries when the TS size is 1.25 Gbit/s. On each node and on every link, two MSI values have to be provisioned: The TxMSI information inserted in OPU (e.g., OPU3) overhead by the source of the HO ODUk trail. The expectedMSI information that is used to check the acceptedMSI information. The acceptedMSI information is the MSI valued received in-band, after a 3 frames integration. The sink of the HO ODU trail checks the complete content of the acceptedMSI information (against the expectedMSI. If the acceptedMSI is different from the expectedMSI, then the traffic is dropped and a payload mismatch alarm is generated. Provisioning of TPN can be performed either by network management system or control plane. In the last case, control plane is also responsible for negotiating the provisioned values on a link by link base. 4. Connection management in OTN OTN-based connection management is concerned with controlling the connectivity of ODU paths and optical channels (OCh). This document focuses on the connection management of ODU paths. The management of OCh paths is described in [RFC6163]. While [G872-2001] considered the ODU as a set of layers in the same way as SDH has been modeled, recent ITU-T OTN architecture progress [G872-Am2] includes an agreement to model the ODU as a single layer network with the bit rate as a parameter of links and connections. This allows the links and nodes to be viewed in a single topology as a common set of resources that are available to provide ODUj connections independent of the value of j. Note that when the bit rate of ODUj is less than the server bit rate, ODUj connections are supported by HO-ODU (which has a one-to-one relationship with the OTU). From an ITU-T perspective, the ODU connection topology is represented by that of the OTU link layer, which has the same topology as that of the OCh layer (independent of whether the OTU supports HO-ODU, where multiplexing is utilized, or LO-ODU in the case of direct mapping). Thus, the OTU and OCh layers should be visible in a single Zhang Expires March 2012 [Page 9] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 topological representation of the network, and from a logical perspective, the OTU and OCh may be considered as the same logical, switchable entity. Note that the OTU link layer topology may be provided via various infrastructure alternatives, including point-to-point optical connections, flexible optical connections fully in the optical domain, flexible optical connections involving hybrid sub-lambda/lambda nodes involving 3R, etc. The document will be updated to maintain consistency with G.872 progress when it is consented for publication. 4.1. Connection management of the ODU LO ODUj can be either mapped into the OTUk signal (j = k), or multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is mapped into an OCh. See Appendix A for more information. From the perspective of control plane, there are two kinds of network topology to be considered. (1) ODU layer In this case, the ODU links are presented between adjacent OTN nodes, which is illustrated in Figure 2. In this layer there are ODU links with a variety of TSs available, and nodes that are ODXCs. Lo ODU connections can be setup based on the network topology. Link #5 +--+---+--+ Link #4 +--------------------------| |--------------------------+ | | ODXC | | | +---------+ | | Node E | | | +-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++ | |Link #1 | |Link #2 | |Link #3 | | | |--------| |--------| |--------| | | ODXC | | ODXC | | ODXC | | ODXC | +---------+ +---------+ +---------+ +---------+ Node A Node B Node C Node D Figure 2 - Example Topology for LO ODU connection management Zhang Expires March 2012 [Page 10] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 If an ODUj connection is requested between Node C and Node E routing/path computation must select a path that has the required number of TS available and that offers the lowest cost. Signaling is then invoked to set up the path and to provide the information (e.g., selected TS) required by each transit node to allow the configuration of the ODUj to OTUk mapping (j = k) or multiplexing (j < k), and demapping (j = k) or demultiplexing (j < k). (2) ODU layer with OCh switching capability In this case, the OTN nodes interconnect with wavelength switched node (e.g., ROADM,OXC) that are capable of OCh switching, which is illustrated in Figure 3 and Figure 4. There are ODU layer and OCh layer, so it is simply a MLN. OCh connections may be created on demand, which is described in section 5.1. In this case, an operator may choose to allow the underlined OCh layer to be visible to the ODU routing/path computation process in which case the topology would be as shown in Figure 4. In Figure 3 below, instead, a cloud representing OCH capable switching nodes is represented. In Figure 3, the operator choice is to hide the real RWA network topology. Node E Link #5 +--------+ Link #4 +------------------------| |------------------------+ | ------ | | // \\ | | || || | | | RWA domain | | +-+-----+ +----+- || || ------+ +-----+-+ | | | \\ // | | | | |Link #1 | -------- |Link #3 | | | +--------+ | | +--------+ + | ODXC | | ODXC +--------+ ODXC | | ODXC | +-------+ +---------+Link #2 +---------+ +-------+ Node A Node B Node C Node D Figure 3 - RWA Hidden Topology for LO ODU connection management Zhang Expires March 2012 [Page 11] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 Link #5 +---------+ Link #4 +------------------------| |-----------------------+ | +----| ODXC |----+ | | +-++ +---------+ ++-+ | | Node f | | Node E | | Node g | | +-++ ++-+ | | | +--+ | | +-+-----+ +----+----+--| |--+-----+---+ +-----+-+ | |Link #1 | | +--+ | |Link #3 | | | +--------+ | Node h | +--------+ + | ODXC | | ODXC +--------+ ODXC | | ODXC | +-------+ +---------+ Link #2+---------+ +-------+ Node A Node B Node C Node D Figure 4 - RWA Visible Topology for LO ODUj connection management In Figure 4, the cloud of previous figure is substitute by the real topology. The nodes f, g, h are nodes with OCH switching capability. In the examples (i.e., Figure 3 and Figure 4), we have considered the case in which LO-ODUj connections are supported by OCh connection, and the case in which the supporting underlying connection can be also made by a combination of HO-ODU/OCh connections. In this case, the ODU routing/path selection process will request an HO-ODU/OCh connection between node C and node E from the RWA domain. The connection will appear at ODU level as a Forwarding Adjacency, which will be used to create the ODU connection. 5. GMPLS/PCE Implications The purpose of this section is to provide a set of requirements to be evaluated for extensions of the current GMPLS protocol suite and the PCE applications and protocols to encompass OTN enhancements and connection management. 5.1. Implications for LSP Hierarchy with GMPLS TE The path computation for 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. One layer is OCh/OTUk, the other is ODUj. [RFC4206] and [RFC6107] define the Zhang Expires March 2012 [Page 12] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 mechanisms to accomplish creating the hierarchy of LSPs. The LSP management of multiple layers in OTN can follow the procedures defined in [RFC4206], [RFC6107] and related MLN drafts. As discussed in section 4, the route path computation for OCh is in the scope of WSON [RFC6163]. Therefore, this document only considers ODU layer for ODU connection request. LSP hierarchy can also be applied within the ODU layers. One of the typical scenarios for ODU layer hierarchy is to maintain compatibility with introducing new [G709-V3] services (e.g., ODU0, ODUflex) into a legacy network configuration (containing [G709-V1] or [G709-V2] OTN equipment). In this scenario, it may be needed to consider introducing hierarchical multiplexing capability in specific network transition scenarios. One method for enabling multiplexing hierarchy is by introducing dedicated boards in a few specific places in the network and tunneling these new services through [G709-V1] or [G709-V2] containers (ODU1, ODU2, ODU3), thus postponing the need to upgrade every network element to [G709-V3] capabilities. In such case, one ODUj connection can be nested into another ODUk (j +----------+ | TS1==|===========\--------+--TS1 | | TS2==|=========\--\-------+--TS2 | | TS3==|=======\--\--\------+--TS3 | | TS4==|=====\--\--\--\-----+--TS4 | | | \ \ \ \----+--TS5 | | | \ \ \------+--TS6 | | | \ \--------+--TS7 | | | \----------+--TS8 | +----------+ <------------ +----------+ node A Resv node B Figure 5 - Interworking between 1.25Gbps TS and 2.5Gbps TS In the contrary direction, when receiving a label from node A indicating that the TS#i with the granularity of 2.5Gbps is reserved, node B will reserved the TS#i and TS#i+4 with the granularity of 1.25Gbps in its control plane. 7. Security Considerations The use of control plane protocols for signaling, routing, and path computation opens an OTN to security threats through attacks on those protocols. The data plane technology for an OTN does not introduce any specific vulnerabilities, and so the control plane may be secured using the mechanisms defined for the protocols discussed. For further details of the specific security measures refer to the documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], Zhang Expires March 2012 [Page 20] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 [RFC4204], and [RFC5440]). [GMPLS-SEC] provides an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane. 8. IANA Considerations This document makes not requests for IANA action. 9. Acknowledgments We would like to thank Maarten Vissers for his review and useful comments. 10. References 10.1. Normative References [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol LabelSwitching (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. [RFC4201] K. Kompella, Y. Rekhter, Ed., "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. [RFC4202] K. Kompella, Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4203] K. Kompella, Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC4205] K. Kompella, Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005. Zhang Expires March 2012 [Page 21] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, 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. [RFC6107] K. Shiomoto, A. Farrel, "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC6107, February 2011. [RFC6001] Dimitri Papadimitriou et al, "Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi- Layer and Multi-Region Networks (MLN/MRN)", RFC6001, February 21, 2010. [RFC5440] JP. Vasseur, JL. Le Roux, Ed.," Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC6344] G. Bernstein et al, "Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)", RFC6344, August, 2011. [G709-V3] ITU-T, "Interfaces for the Optical Transport Network (OTN)", G.709 Recommendation, December 2009. 10.2. Informative References [G709-V1] ITU-T, "Interface for the Optical Transport Network (OTN)," G.709 Recommendation and Amendment1, November 2001. [G709-V2] ITU-T, "Interface for the Optical Transport Network (OTN)," G.709 Recommendation, March 2003. [G7042] ITU-T G.7042/Y.1305, "Link capacity adjustment scheme (LCAS) for virtual concatenated signals", March 2006. [G872-2001] ITU-T, "Architecture of optical transport networks", November 2001 (11 2001). [G872-Am2] Draft Amendment 2, ITU-T, "Architecture of optical transport networks". Zhang Expires March 2012 [Page 22] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 [G.7044] TD 382 (WP3/15), 31 May - 11 June 2010, Q15 Plenary Meeting in Geneva, Initial draft G.7044 "Hitless Adjustment of ODUflex (HAO)". [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. [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)", RFC6163, April 2011. [PCE-APS] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai Zhang, "Requirements for GMPLS applications of PCE", draft-ietf-pce-gmpls-aps-req-04.txt, May 30,2011. [GMPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, October 2009. 11. Authors' Addresses Fatai Zhang (editor) 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: huawei.danli@huawei.com Han Li China Mobile Communications Corporation 53 A Xibianmennei Ave. Xuanwu District Zhang Expires March 2012 [Page 23] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 Beijing 100053 P.R. China Phone: +86-10-66006688 Email: lihan@chinamobile.com Sergio Belotti Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate (Milano) Italy +39 039 6863033 Email: sergio.belotti@alcatel-lucent.it Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: daniele.ceccarelli@ericsson.com 12. Contributors 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 Malcolm Betts Huawei Technologies Co., Ltd. Email: malcolm.betts@huawei.com Pietro Grandi Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate (Milano) Italy +39 039 6864930 Zhang Expires March 2012 [Page 24] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 Email: pietro_vittorio.grandi@alcatel-lucent.it Eve Varma Alcatel-Lucent 1A-261, 600-700 Mountain Av PO Box 636 Murray Hill, NJ 07974-0636 USA Email: eve.varma@alcatel-lucent.com APPENDIX A: ODU connection examples This appendix provides a description of ODU terminology and connection examples. This section is not normative, and is just intended to facilitate understanding. In order to transmit a client signal, an ODU connection must first be created. From the perspective of [G709-V3] and [G872-Am2], some types of ODUs (i.e., ODU1, ODU2, ODU3, ODU4) may assume either a client or server role within the context of a particular networking domain: (1) An ODUj client that is mapped into an OTUk server. For example, if a STM-16 signal is encapsulated into ODU1, and then the ODU1 is mapped into OTU1, the ODU1 is a LO ODU (from a multiplexing perspective). (2) An ODUj client that is mapped into an ODUk (j < k) server occupying several TSs. For example, if ODU1 is multiplexed into ODU2, and ODU2 is mapped into OTU2, the ODU1 is a LO ODU and the ODU2 is a HO ODU (from a multiplexing perspective). Thus, a LO ODUj represents the container transporting a client of the OTN that is either directly mapped into an OTUk (k = j) or multiplexed into a server HO ODUk (k > j) container. Consequently, the HO ODUk represents the entity transporting a multiplex of LO ODUj tributary signals in its OPUk area. In the case of LO ODUj mapped into an OTUk (k = j) directly, Figure 6 give an example of this kind of LO ODU connection. In Figure 6, The LO ODUj is switched at the intermediate ODXC node. OCh and OTUk are associated with each other. From the viewpoint of Zhang Expires March 2012 [Page 25] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 connection management, the management of OTUk is similar with OCh. LO ODUj and OCh/OTUk have client/server relationships. For example, one LO ODU1 connection can be setup between Node A and Node C. 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. | LO ODUj | +------------------------------(b)---------------------------+ | | OCh/OTUk | | OCh/OTUk | | | +--------(a)---------+ +--------(a)---------+ | | | | | | | +------++-+ +--+---+--+ +-++------+ | |EO| |OE| |EO| |OE| | | +--+----------------+--+ +--+----------------+--+ | | ODXC | | ODXC | | ODXC | +---------+ +---------+ +---------+ Node A Node B Node C Figure 6 - Connection of LO ODUj (1) In the case of LO ODUj multiplexing into HO ODUk, Figure 7 gives an example of this kind of LO ODU connection. In Figure 7, 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, the management of these HO ODUk and OTUk are similar to OCh. LO ODUj and OCh/OTUk/HO ODUk have client/server relationships. When a LO ODU connection is setup, it will be using the existing HO ODUk (/OTUk/OCh) connections which have been set up. 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. 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. 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, Zhang Expires March 2012 [Page 26] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 demultiplexed from HO ODU3 at Node C and switched to its LO ODU1 terminating port at Node C. | LO ODUj | +----------------------------(b)-----------------------------+ | | OCh/OTUk/HO ODUk | | OCh/OTUk/HO ODUk | | | +--------(c)---------+ +---------(c)--------+ | | | | | | | +------++-+ +--+---+--+ +-++------+ | |EO| |OE| |EO| |OE| | | +--+----------------+--+ +--+----------------+--+ | | ODXC | | ODXC | | ODXC | +---------+ +---------+ +---------+ Node A Node B Node C Figure 7 - Connection of LO ODUj (2) 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 Zhang Expires March 2012 [Page 27] draft-ietf-ccamp-gmpls-g709-framework-05.txt September 2011 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. 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. Copyright Notice Copyright (c) 2010 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 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. Zhang Expires March 2012 [Page 28]