idnits 2.17.1 draft-zhang-ccamp-gmpls-g709-framework-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 392: '...alues of the TPN MUST be either agreed...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 393 has weird spacing: '...U trail eithe...' -- The document date (February 27, 2010) is 5170 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3945' is mentioned on line 89, but not defined == Missing Reference: 'RFC4655' is mentioned on line 109, but not defined == Missing Reference: 'WSON-Frame' is mentioned on line 553, but not defined == Missing Reference: 'RFC4201' is mentioned on line 339, but not defined == Unused Reference: 'HZang00' is defined on line 820, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4205 (Obsoleted by RFC 5307) == Outdated reference: A later version (-09) exists of draft-ietf-pce-gmpls-aps-req-01 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Fatai Zhang 2 Internet Draft Dan Li 3 Category: Informational Huawei 4 Han Li 5 CMCC 6 S.Belotti 7 Alcatel-Lucent 8 Expires: August 26, 2010 February 27, 2010 10 Framework for GMPLS and PCE Control of 11 G.709 Optical Transport Networks 13 draft-zhang-ccamp-gmpls-g709-framework-02.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on June 16, 2010. 38 Abstract 40 This document provides a framework to allow the development of 41 protocol extensions to support Generalized Multi-Protocol Label 42 Switching (GMPLS) and Path Computation Element (PCE) control of 43 Optical Transport Networks (OTN) as specified in ITU-T Recommendation 44 G.709 as consented in October 2009. 46 Table of Contents 48 1. Introduction................................................2 49 2. Terminology.................................................3 50 3. G.709 Optical Transport Network (OTN)........................4 51 3.1. OTN Layer Network.......................................4 52 4. Connection management in OTN................................10 53 4.1. Connection management of the ODU.......................10 54 5. GMPLS/PCE Implications......................................13 55 5.1. Implications for LSP Hierarchy with GMPLS TE...........13 56 5.2. Implications for GMPLS Signaling.......................13 57 5.2.1. Identifying OTN signals...........................13 58 5.2.2. Tributary Port Number.............................14 59 5.3. Implications for GMPLS Routing.........................15 60 5.3.1. Requirement for conveying Interface Switching Capability 61 specific information.....................................15 62 5.4. Implications for Link Management Protocol (LMP).........16 63 5.4.1. Correlating the Granularity of the TS.............16 64 5.4.2. Correlating the Supported LO ODU Signal Types......16 65 5.5. Implications for Path Computation Elements.............17 66 6. Security Considerations.....................................17 67 7. IANA Considerations........................................17 68 8. Acknowledgments............................................17 69 9. References.................................................18 70 9.1. Normative References...................................18 71 9.2. Informative References.................................19 72 10. Authors' Addresses........................................19 73 11. Contributors..............................................20 74 APPENDIX A: Description of LO ODU terminology and ODU connection 75 examples......................................................21 77 1. Introduction 79 OTN has become a mainstream layer 1 technology for the transport 80 network. Operators want to introduce control plane capabilities based 81 on Generalized Multi-Protocol Label Switching (GMPLS) to OTN networks, 82 to realize the benefits associated with a high-function control plane 83 (e.g., improved network resiliency, resource usage efficiency, etc.). 85 GMPLS extends MPLS to encompass time division multiplexing (TDM) 86 networks (e.g., SONET/SDH, PDH, and G.709 sub-lambda), lambda 87 switching optical networks, and spatial switching (e.g., incoming 88 port or fiber to outgoing port or fiber). The GMPLS architecture is 89 provided in [RFC3945], signaling function and Resource ReserVation 90 Protocol-Traffic Engineering (RSVP-TE) extensions are described in 92 [RFC3471] and [RFC3473], routing and OSPF extensions are described in 93 [RFC4202] and [RFC4203], and the Link Management Protocol (LMP) is 94 described in [RFC4204]. 96 The GMPLS protocol suite including provision [RFC4328] provides the 97 mechanisms for basic GMPLS control of OTN networks based on the 2003 98 revision of the G.709 specification [G709-V1]. Later revisions of the 99 G.709 specification [G709-V3] have included some new features; for 100 example, various multiplexing structures, two types of Tributary 101 Slots (i.e., 1.25Gbps and 2.5Gbps), and extension of the Optical Data 102 Unit (ODU) ODUj definition to include the ODUflex function. 104 This document reviews relevant aspects of OTN technology evolution 105 that affect the GMPLS control plane protocols and examines why and 106 how to update the mechanisms described in [RFC4328]. This document 107 additionally provides a framework for the GMPLS control of OTN 108 networks and includes a discussion of the implication for the use of 109 the Path Computation Element (PCE) [RFC4655]. 111 For the purposes of the control plane the OTN can be considered as 112 being comprised of sub-wavelength (ODU) and wavelength (OCh) layers. 113 This document focuses on the control of the sub-wavelength layer, 114 with control of the wavelength layer considered out of the scope. 115 Please refer to [WSON-Frame] for further information about the 116 wavelength layer. 118 [Note: It is intended to align this draft with G.709 (consented in 119 10/2009), G.872 and G.8080 (planned for consent in 6/2010)] 121 2. Terminology 123 OTN: Optical Transport Network 125 ODU: Optical Channel Data Unit 127 OTU: Optical channel transport unit 129 OMS: Optical multiplex section 131 MSI: Multiplex Structure Identifier 133 TPN: Tributary Port Number 135 LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4, 136 Flex.) represents the container transporting a client of the OTN that 137 is either directly mapped into an OTUk (k = j) or multiplexed into a 138 server HO ODUk (k > j)container. 140 HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, 4.) 141 represents the entity transporting a multiplex of LO ODUj tributary 142 signals in its OPUk area. 144 ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a 145 bit rate tolerance up to 100 ppm. 147 3. G.709 Optical Transport Network (OTN) 149 This section provides an informative overview of those aspects of the 150 OTN impacting control plane protocols. This overview is based on the 151 ITU-T Recommendations that contain the normative definition of the 152 OTN. Technical details regarding OTN architecture and interfaces are 153 provided in the relevant ITU-T Recommendations. 155 Specifically, [ITU-T-G.872] describes the functional architecture of 156 optical transport networks providing optical signal transmission, 157 multiplexing, routing, supervision, performance assessment, and 158 network survivability. [G709-V1] defines the interfaces of the 159 optical transport network to be used within and between subnetworks 160 of the optical network. With the evolution and deployment of OTN 161 technology many new features have been specified in ITU-T 162 recommendations, including for example, new ODU0, ODU2e, ODU4 and 163 ODUflex containers as described in [G709-V3]. 165 3.1. OTN Layer Network 167 The simplified signal hierarchy of OTN is shown in Figure 1, which 168 illustrates the layers that are of interest to the control plane. 169 Other layers below OCh (e.g. Optical Transmission Section - OTS) are 170 not included in this Figure. The full signal hierarchy is provided in 171 [G709-V3]. 173 Client signal 174 | 175 ODUj 176 | 177 OTU/OCh 178 OMS 180 Figure 1 Basic OTN signal hierarchy 182 Client signals are mapped into ODUj containers. These ODUj containers 183 are multiplexed onto the OTU/OCh. The individual OTU/OCh signals are 184 combined in the Optical Multiplex Section (OMS) using WDM 185 multiplexing, and this aggregated signal provides the link between 186 the nodes. 188 3.1.1 Client signal mapping 190 The client signals are mapped into a Low Order (LO) ODUj. Appendix A 191 gives more information about LO ODU. 193 The current values of j defined in [G709-V3] are: 0, 1, 2, 2e, 3, 4, 194 Flex. The approximate bit rates of these signals are defined in 195 [G709-V3] and are reproduced in Tables 1 and 2. 197 +-----------------------+-----------------------------------+ 198 | ODU Type | ODU nominal bit rate | 199 +-----------------------+-----------------------------------+ 200 | ODU0 | 1 244 160 kbits/s | 201 | ODU1 | 239/238 x 2 488 320 kbit/s | 202 | ODU2 | 239/237 x 9 953 280 kbit/s | 203 | ODU3 | 239/236 x 39 813 120 kbit/s | 204 | ODU4 | 239/227 x 99 532 800 kbit/s | 205 | ODU2e | 239/237 x 10 312 500 kbit/s | 206 | | | 207 | ODUflex for CBR | | 208 | Client signals | 239/238 x client signal bit rate | 209 | | | 210 | ODUflex for GFP-F | | 211 | Mapped client signal | Configured bit rate | 212 +-----------------------+-----------------------------------+ 214 Table 1 ODU types and bit rates 216 NOTE - The nominal ODUk rates are approximately: 2 498 775.126 kbit/s 217 (ODU1), 10 037 273.924 kbit/s (ODU2), 40 319 218.983 kbit/s (ODU3), 218 104 794 445.815 kbit/s (ODU4) and 10 399 525.316 kbit/s (ODU2e). 220 +-------------------+--------------------------------------+ 221 | ODU Type | ODU bit-rate tolerance | 222 +-------------------+--------------------------------------+ 223 | ODU0 | +- 20 ppm | 224 | ODU1 | +- 20 ppm | 225 | ODU2 | +- 20 ppm | 226 | ODU3 | +- 20 ppm | 227 | ODU4 | +- 20 ppm | 228 | ODU2e | +- 100 ppm | 229 | | | 230 | ODUflex for CBR | | 231 | Client signals | client signal bit rate tolerance, | 232 | | with a maximum of+-100 ppm | 233 | | | 234 | ODUflex for GFP-F | | 235 | Mapped client | +- 20 ppm | 236 | signal | | 237 +-------------------+--------------------------------------+ 238 Table 2 ODU types and tolerance 240 One of two options are for mapping client signals into ODUflex 241 depending on the client signal type: 242 - Circuit clients are proportionally wrapped. Thus the bit rate and 243 tolerance are defined by the client signal. 245 - Packet clients are mapped using the Generic Framing Procedure 246 (GFP). [G709-V3] recommends that the bit rate should be set to an 247 integer multiplier of the High Order (HO) Optical Channel Physical 248 Unit (OPU) OPUk Tributary Slot (TS) rate, the tolerance should be +/- 249 20ppm, and the bit rate should be determined by the node that 250 performs the mapping. 252 3.1.1.1 ODUj types and parameters 254 When ODUj connections are setup, two types of information should be 255 conveyed in a connection request: 257 (a)End to end: 258 Client payload type (e.g. STM64; Ethernet etc.) 260 Bit rate and tolerance: Note for j = 0, 1, 2, 2e, 3, 4 this 261 information may be carried as an enumerated type. For the ODUflex 262 the actual bit rate and tolerance must be provided. 264 (b)Hop by hop: 265 TS assignment and port number carried by the Multiplex Structure 266 Identifier (MSI) bytes as described in section 3.1.2. 268 3.1.2 Multiplexing ODUj onto Links 270 The links between the switching nodes are provided by one or more 271 wavelengths. Each wavelength carries one OCh, which carries one OTU, 272 which carries one OPU. Since all of these signals have a 1:1:1 273 relationship, we only refer to the OTU for clarity. The ODUjs are 274 mapped into the Tributary Slots (TS) of the OTUk. Note that in the 275 case where j=k the ODUj is mapped into the OTU/OCh without 276 multiplexing. 278 The initial versions of G.709 [G709-V1] only provided a single TS 279 granularity, nominally 2.5Gb/s. Amendment 3 [G709-V3], approved in 280 2009, added an additional TS granularity, nominally 1.25Gb/s. The 281 number and type of TSs provided by each of the currently identified 282 OTUk is provided below: 284 2.5Gb/s 1.25Gb/s Nominal Bit rate 285 OTU1 1 2 2.5Gb/s 286 OTU2 4 8 10Gb/s 287 OTU3 16 32 40Gb/s 288 OTU4 -- 80 100Gb/s 290 To maintain backwards compatibility while providing the ability to 291 interconnect nodes that support 1.25Gb/s TS at one end of a link and 292 2.5Gb/s TS at the other, the 'new' equipment will fall back to the 293 use of a 2.5Gb/s TS if connected to legacy equipment. This 294 information is carried in band by the payload type. 296 The actual bit rate of the TS in an OTUk depends on the value of k. 297 Thus the number of TS occupied by an ODUj may vary depending on the 298 values of j and k. For example an ODU2e uses 9 TS in an OTU3 but 299 only 8 in an OTU4. Examples of the number of TS used for various 300 cases are provided below: 302 - ODU0 into ODU1, ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS 303 granularity 304 o ODU0 occupies 1 of the 2, 8, 32 or 80 TS for ODU1, ODU2, ODU3 or 305 ODU4 307 - ODU1 into ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS 308 granularity 309 o ODU1 occupies 2 of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4 311 - ODU1 into ODU2, ODU3 multiplexing with 2.5Gbps TS granularity 312 o ODU1 occupies 1 of the 4 or 16 TS for ODU2 or ODU3 314 - ODU2 into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity 315 o ODU2 occupies 8 of the 32 or 80 TS for ODU3 or ODU4 317 - ODU2 into ODU3 multiplexing with 2.5Gbps TS granularity 318 o ODU2 occupies 4 of the 16 TS for ODU3 320 - ODU3 into ODU4 multiplexing with 1.25Gbps TS granularity 321 o ODU3 occupies 31 of the 80 TS for ODU4 323 - ODUflex into ODU2, ODU3 or ODU4 multiplexing with 1.25Gbps TS 324 granularity 325 o ODUflex occupies n of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4 326 (n <= Total TS numbers of ODUk) 328 - ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity 329 o ODU2e occupies 9 of the 32 TS for ODU3 or 8 of the 80 TS for 330 ODU4 332 In general the mapping of an ODUj (including ODUflex) into the OTUk 333 TSs is determined locally, and it can also be explicitly controlled 334 by a specific entity (e.g., head end, NMS) through Explicit Label 335 Control [RFC3473]. 337 3.1.2.1 Link Parameters 339 Per [RFC4201], each OTU can be treated as a component link of a link 340 bundle. The available capacity between nodes is the sum of the 341 available capacity on the OTUs that interconnect the nodes. This 342 total capacity is represented as the capacity of a link bundle. 344 Note that there will typically be more than one OTU between a pair of 345 nodes so that the available capacity will typically be distributed 346 across multiple OTUs. Thus, in order to be able to determine the 347 maximum payload that can be carried on a bundled link, the link state 348 advertisement must also provide the largest number of TSes available 349 on any one component OTU. 351 In order to compute the lowest cost path for a ODUj connection 352 request the critical parameters that need to be provided (for the 353 purposes of routing) are: 355 - Number of TS 357 - Maximum number of TS available for a LSP (i.e., Maximum LSP 358 Bandwidth) 360 - Bit rate of the TS. (Note: This may be efficiently encoded as a 361 two integers representing the value of k and the granularity.) 363 3.1.2.2 Tributary Port Number Assignment 365 When multiplexing an ODUj into a HO ODUk (k>j), G.709 specifies the 366 information that has to be transported in-band in order to allow for 367 correct demultiplexing. This information, known as Multiplex 368 Structure Information (MSI), is transported in the OPUk overhead and 369 is organized as a set of entries, with one entry for each HO ODUj 370 tributary slot. The information carried by each entry is: 372 Payload Type: the type of the transported payload 374 Tributary Port Number (TPN): the port number of the ODUj transported 375 by the HO ODUk. The TPN is the same for all the tributary slots 376 assigned to the transport of the same ODUj instance. 378 For example, an ODU2 carried by a HO ODU3 is described by 4 entries 379 in the OPU3 overhead when the Tributary Slot (TS) size is 2.5 Gbit/s, 380 and by 8 entries when the TS size is 1.25 Gbit/s. 382 The MSI information inserted in OPU3 overhead by the source of the HO 383 ODUk trail is checked by the sink of the HO ODUk trail. G.709 384 default behavior requires that the multiplexing structure of the HO 385 ODUk be provided by means of pre-provisioned MSI information, termed 386 expectedMSI. The sink of the HO ODU trail checks the complete 387 content of the MSI information (including the TPN) that was received 388 in-band, termed acceptedMSI, against the expectedMSI. If the 389 acceptedMSI is different from the expectedMSI, then the traffic is 390 dropped and a payload mismatch alarm is generated. 392 Note that the values of the TPN MUST be either agreed between the 393 source and the sink of the HO ODU trail either via control plane 394 signaling or provisioning by the management plane. 396 4. Connection management in OTN 398 As [ITU-T-G.872] described, OTN-based transport network equipment is 399 concerned with control of connectivity of ODU paths and optical 400 channels and not with control of connectivity of the client layer. 401 This document focuses on the connection management of ODU paths. The 402 management of OCh paths is described in [WSON-FRAME]. 404 Current [ITU-T-G.872] considers the ODU as a set of layers in the 405 same way as SDH has been modeled. However, recent progress within 406 the ITU-T on OTN architecture includes an agreement to update this 407 Recommendation to model the ODU as a single layer network with the 408 bit rate as a parameter of links and connections. This will allow the 409 links and nodes to be viewed in a single topology as a common set of 410 resources that are available to provide ODUj connections independent 411 of the value of j. Note that when the bit rate of ODUj is less than 412 the server bit rate, ODUj connections are supported by HO-ODU (which 413 has a one-to-one relationship with the OTU). 415 From an ITU-T perspective, the service layer is represented by the LO 416 ODU and the connection topology is represented by that of the server 417 layer; i.e., the OTU [corresponding to HO-ODU in case of multiplexing 418 or to LO-ODU in case of direct mapping] which has the same topology 419 as that of the OCh layer. The server layer topology is based on that 420 of the OTU, and could be provided by a point-to-point optical 421 connection, flexible optical connection that is fully in the optical 422 domain, flexible optical connection involving hybrid sub- 423 lambda/lambda nodes involving 3R, etc. 425 The HO-ODU/OTU and OCh layers should be visible in a single 426 topological representation of the network, and from a logical 427 perspective, the HO ODU/OTU and OCh may be considered as the same 428 logical, switchable entity. 430 The remainder of this document assumes that the revision of G.872 431 will be made. The document will be updated to keep it in line with 432 the new revision of G.872 when it is consented for publication. 434 4.1. Connection management of the ODU 436 LO ODUj can be either mapped into the OTUk signal (j = k), or 437 multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is 438 mapped into an OCh. See Appendix A for more information. 440 From the perspective of control plane, there are two kinds of network 441 topology to be considered. 443 (1) ODU layer 445 In this case, the ODU links are presented between adjacent OTN nodes, 446 which is illustrated in Figure 2. In this layer there are ODU links 447 with a variety of TSes available, and nodes that are ODXCs. Lo ODU 448 connections can be setup based on the network topology. 450 Link #5 +--+---+--+ Link #4 451 +--------------------------| |--------------------------+ 452 | | ODXC | | 453 | +---------+ | 454 | Node E | 455 | | 456 +-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++ 457 | |Link #1 | |Link #2 | |Link #3 | | 458 | |--------| |--------| |--------| | 459 | ODXC | | ODXC | | ODXC | | ODXC | 460 +---------+ +---------+ +---------+ +---------+ 461 Node A Node B Node C Node D 463 Figure 2 Example Topology for connection LO ODU connection management 465 If an ODUj connection is requested between Node C and Node E 466 routing/path computation must select a path that has the required 467 number of TS available and that offers the lowest cost. Signaling is 468 then invoked to set up the path and to provide the information (e.g., 469 selected TS) required by each transit node to allow the configuration 470 of the ODUj to OTUk mapping (j = k) or multiplexing (j < k), and 471 demapping (j = k) or demultiplexing (j < k). 473 (2)ODU layer with OCh switching capability 475 In this case, the OTN nodes interconnect with wavelength switched 476 node (e.g., ROADM,OXC) that are capable of OCh switching, which is 477 illustrated in Figure 3 and Figure 4. There are ODU layer and OCh 478 layer, so it is simply a MLN. OCh connections may be created on 479 demand, which is described in section 5.1. 481 In this case, an operator may choose to allow the underlined OCh 482 layer to be visible to the ODU routing/path computation process in 483 which case the topology would be as shown in Figure 4. In Figure 3 484 below, instead, a cloud representing OCH capable switching nodes is 485 represented. In Figure 3, the operator choice is to hide the real RWA 486 network topology. 488 Node E 490 Link #5 +---------+ Link #4 491 +--------------------------| |-------------------------+ 492 | ------ | 493 | // \\ | 494 | || || | 495 | | RWA domain | | 496 +-+-------+ +----+- || || ------+ +-------+-+ 497 | | | \\ // | | | 498 | |Link #1 | -------- |Link #3 | | 499 | +--------+ | | +--------+ + 500 | ODXC | | ODXC +--------+ ODXC | | ODXC | 501 +---------+ +---------+Link #2 +---------+ +---------+ 502 Node A Node B Node C Node D 504 Figure 3 RWA Hidden Topology for connection LO ODU connection management 506 Link #5 +---------+ Link #4 507 +--------------------------| |-------------------------+ 508 | +----+ ODXC |----+ | 509 | +-++ +---------+ ++-+ | 510 | Node f + + Node E + + Node g | 511 | +-++ ++-+ | 512 | | +--+ | | 513 +-+-------+ +----+----+--| +--+-----+---+ +-------+-+ 514 | |Link #1 | | +--+ | |Link #3 | | 515 | +--------+ | Node h | +--------+ + 516 | ODXC | | ODXC +--------+ ODXC | | ODXC | 517 +---------+ +---------+ Link #2+---------+ +---------+ 518 Node A Node B Node C Node D 520 Figure 4 RWA Visible Topology for LO ODUj connection management 522 In Figure 4, the cloud of previous figure is substitute by the real 523 topology. The nodes f,g,h are nodes with OCH switching capability. 525 In the examples (i.e., Figure 3 and Figure 4), we have considered the 526 case in which LO-ODUj connections are supported by OCh connection, 527 and the case in which the supporting underlying connection can be 528 also made by a combination of HO-ODU/OCh connections. 530 In this case, the ODU routing/path selection process will request an 531 HO-ODU/OCh connection between node C to node E from the RWA domain. 532 The connection will appear at ODU level as a Forwarding Adjacency, 533 which will be used to create the ODU connection. 535 5. GMPLS/PCE Implications 537 The purpose of this section is to provide a framework for extensions 538 of the current GMPLS protocol suite and the PCE applications and 539 protocols to encompass OTN enhancements and connection management. 541 5.1. Implications for LSP Hierarchy with GMPLS TE 543 The path computation for LO ODU connection request is based on the 544 topology of ODU layer, including OCh layer visibility. 546 The OTN path computation can be divided into two layers. One layer is 547 OCh/OTUk, the other is LO ODUj. [RFC4206] defines the mechanisms to 548 accomplish creating the hierarchy of LSPs. The LSP management of 549 multiple layers in OTN can follow the procedures defined in [RFC4206] 550 and related MLN drafts. 552 As discussed in section 4, the route path computation for OCh is in 553 the scope of WSON [WSON-Frame]. Therefore, this document only 554 considers ODU layer for LO ODU connection request. 556 5.2. Implications for GMPLS Signaling 558 The signaling function and Resource reSerVation Protocol-Traffic 559 Engineering (RSVP-TE) extensions are described in [RFC3471] and [RFC 560 3473]. For OTN-specific control, [RFC4328] defines signaling 561 extensions to support G.709 Optical Transport Networks Control as 562 defined in [G709-V1]. 564 As described in Section 2, [G709-V3] introduced some new features 565 that include the ODU0, ODU2e, ODU4 and ODUflex containers. The 566 mechanisms defined in [RFC4328] do not support such new OTN features, 567 and protocol extensions will be necessary to allow them to be 568 controlled by a GMPLS control plane. 570 5.2.1. Identifying OTN signals 572 [RFC4328] defines the LSP Encoding Type, the Switching Type and the 573 Generalized Protocol Identifier (Generalized-PID) constituting the 574 common part of the Generalized Label Request. The G.709 Traffic 575 Parameters are also defined in [RFC4328]. The following new signal 576 types have been added since [RFC4328] was published: 578 (1)New signal types of sub-lambda layer 580 Optical Channel Data Unit (ODUj): 582 ODU0 584 ODU2e 586 ODU4 588 ODUflex 590 (2)A new Tributary Slot (TS) granularity (i.e., 1.25 Gbps) 592 (3)Signal type with variable bandwidth: 594 ODUflex has a variable bandwidth/bit rate BR and a bit rate 595 tolerance T. As described above the (node local) mapping process 596 must be aware of the bit rate and tolerance of the ODUj being 597 multiplexed in order to select the correct number of TS and the 598 fixed/variable stuffing bytes. Therefore, bit rate and bit rate 599 tolerance should be carried in the Traffic Parameter in the 600 signaling of connection setup request. 602 (4)Extended multiplexing hierarchy (For example, ODU0 into OTU2 603 multiplexing (with 1,25Gbps TS granularity).) 605 So the encoding provided in [RFC4328] needs to be extended to support 606 all the signal types and related mapping and multiplexing with all 607 kinds of tributary slots. Moreover, the extensions should consider 608 the extensibility to match future evolvement of OTN. 610 For item (1) and (3), new traffic parameters may need to be extended 611 in signaling message; 613 For item (2) and (4), new label should be defined to carry the exact 614 TS allocation information related to the extended multiplexing 615 hierarchy. 617 5.2.2. Tributary Port Number 619 The tributary port number may be assigned locally by the node at the 620 (traffic) ingress end of the link and in this case as described above 621 must be conveyed to the far end of the link as a "transparent" 622 parameter i.e. the control plane does not need to understand this 623 information. The TPN may also be assigned by the control plane as a 624 part of path computation. 626 5.3. Implications for GMPLS Routing 628 The path computation process should select a suitable route for a 629 ODUj connection request. In order to compute the lowest cost path it 630 must evaluate the number (and availability) of tributary slots on 631 each candidate link. The routing protocol should be extended to 632 convey some information to represent ODU TE topology. As described 633 above the number of tributary slots (on a link bundle), the bandwidth 634 of the TS and the maximum number that are available to convey a 635 single ODUj must be provided. 637 GMPLS Routing [RFC4202] defines Interface Switching Capability 638 Descriptor of TDM which can be used for ODU. However, some other 639 issues should also be considered which are discussed below. 641 5.3.1. Requirement for conveying Interface Switching Capability specific 642 information 644 Interface Switching Capability Descriptors present a new constraint 645 for LSP path computation. [RFC4203] defines the switching capability 646 and related Maximum LSP Bandwidth and the Switching Capability 647 specific information. When the Switching Capability field is TDM the 648 Switching Capability specific information field includes Minimum LSP 649 Bandwidth, an indication whether the interface supports Standard or 650 Arbitrary SONET/SDH, and padding. So routing protocol should be 651 extended when TDM is ODU type to support representation of ODU 652 switching information. 654 As discussed in section 3.1.2, many different types of ODUj can be 655 multiplexed into the same OTUk. For example, both ODU0 and ODU1 may 656 be multiplexed into ODU2. An OTU link may support one or more types 657 of ODUj signals. The routing protocol should be extended to carry 658 this multiplexing capability. Furthermore, one type of ODUj can be 659 multiplexed to an OTUk using different tributary slot granularity. 660 For example, ODU1 can be multiplexed into ODU2 with either 2.5Gbps TS 661 granularity or 1.25G TS granularity. The routing protocol should be 662 extended to carry which TS granularity supported by the ODU interface. 664 Moreover, the bit rate (i.e., bandwidth) of TS can be determined by 665 the TS granularity and link type of the TE link. For example, the 666 bandwidth of a 1.25G TS without NJO (Negative Justification 667 Opportunity) in an OTU2 is about 1.249409620 Gbps, while the 668 bandwidth of a 1.25G TS without NJO in an OTU3 is about 1.254703729 669 Gbps. So The routing protocol should be extended to carry the TE link 670 type (OTUk/HO ODUk). 672 In OTN networks, it is simpler to use the number of Tributary Slots 673 for the bandwidth accounting. For example, Total bandwidth of the TE 674 link, Unreserved Bandwidth of the TE link and the Maximum LSP 675 Bandwidth can be accounted through the number of Tributary Slots 676 (e.g., the total number of the Tributary Slots of the TE link, the 677 unreserved Tributary Slots of the TE link, Maximum Tributary Slots 678 for an LSP). Thus, the routing protocol should be extended to carry 679 the Tributary Slots information related to bandwidth of the TE link. 681 5.4. Implications for Link Management Protocol (LMP) 683 As discussed in section 5.3, Path computation needs to know the 684 interface switching capability of links. The switching capability of 685 two ends of the link may be different, so the link capability of two 686 ends should be correlated. 688 The Link Management Protocol (LMP) [RFC4204] provides a control plane 689 protocol for exchanging and correlating link capabilities. 691 It is not necessary to use LMP to correlate link-end capabilities if 692 the information is available from another source such as management 693 configuration or automatic discovery/negotiation within the data 694 plane. 696 Note that LO ODU type information can be, in principle, discovered by 697 routing. Since in certain case, routing is not present (e.g. UNI case) 698 we need to extend link management protocol capabilities to cover this 699 aspect. In case of routing presence, the discovering procedure by LMP 700 could also be optional. 702 5.4.1. Correlating the Granularity of the TS 704 As discussed in section 3.1.2, the two ends of a link may support 705 different TS granularity. In order to allow interconnection the node 706 with 1.25Gb/s granularity must fall back to 2.5Gb/s granularity. 708 Therefore, it is necessary for the two ends of a link to correlate 709 the granularity of the TS. This ensures that both ends of the link 710 advertise consistent capabilities (for routing) and ensures that 711 viable connections are established. 713 5.4.2. Correlating the Supported LO ODU Signal Types 715 Many new ODU signal types have been introduced [G709-V3], such as 716 ODU0, ODU4, ODU2e and ODUflex. It is possible that equipment does not 717 support all the LO ODU signal types introduced by those new standards 718 or drafts. If one end of a link can not support a certain LO ODU 719 signal type, the link cannot be selected to carry such type of LO ODU 720 connection. 722 Therefore, it is necessary for the two ends of an HO ODU link to 723 correlate which types of LO ODU can be supported by the link. After 724 correlating, the capability information can be flooded by IGP, so 725 that the correct path for an ODU connection can be calculated. 727 5.5. Implications for Path Computation Elements 729 [PCE-APS] describes the requirements for GMPLS applications of PCE in 730 order to establish GMPLS LSP. PCE needs to consider the GMPLS TE 731 attributes appropriately once a PCC or another PCE requests a path 732 computation. The TE attributes which can be contained in the path 733 calculation request message from the PCC or the PCE defined in 734 [RFC5440] includes switching capability, encoding type, signal type, 735 etc. 737 As described in section 5.2.1, new signal types and new signals with 738 variable bandwidth information need to be carried in the extended 739 signaling message of path setup. For the same consideration, PCECP 740 also has a desire to be extended to carry the new signal type and 741 related variable bandwidth information when a PCC requests a path 742 computation. 744 6. Security Considerations 746 The use of control plane protocols for signaling, routing, and path 747 computation opens an OTN to security threats through attacks on those 748 protocols. The data plane technology for an OTN does not introduce 749 any specific vulnerabilities, and so the control plane may be secured 750 using the mechanisms defined for the protocols discussed. 752 For further details of the specific security measures refer to the 753 documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], 754 [RFC4204], and [RFC5440]). [GMPLS-SEC] provides an overview of 755 security vulnerabilities and protection mechanisms for the GMPLS 756 control plane. 758 7. IANA Considerations 760 This document makes not requests for IANA action. 762 8. Acknowledgments 764 We would like to thank Maarten Vissers for his review and useful 765 comments. 767 9. References 769 9.1. Normative References 771 [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label 772 Switching (GMPLS) Signaling Extensions for G.709 Optical 773 Transport Networks Control", RFC 4328, Jan 2006. 775 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 776 Switching (GMPLS) Signaling Functional Description", 777 RFC 3471, January 2003. 779 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 780 Switching (GMPLS) Signaling Resource ReserVation 781 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 782 3473, January 2003. 784 [RFC4202] K. Kompella, Y. Rekhter, Ed., "Routing Extensions in 785 Support of Generalized Multi-Protocol Label Switching 786 (GMPLS)", RFC 4202, October 2005. 788 [RFC4203] K. Kompella, Y. Rekhter, Ed., "OSPF Extensions in Support 789 of Generalized Multi-Protocol Label Switching (GMPLS)", 790 RFC 4203, October 2005. 792 [RFC4205] K. Kompella, Y. Rekhter, Ed., "Intermediate System to 793 Intermediate System (IS-IS) Extensions in Support of 794 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 795 4205, October 2005. 797 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 798 4204, October 2005. 800 [RFC4206] K. Kompella, Y. Rekhter, Ed., " Label Switched Paths 801 (LSP) Hierarchy with Generalized Multi-Protocol Label 802 Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, 803 October 2005. 805 [RFC5440] JP. Vasseur, JL. Le Roux, Ed.," Path Computation Element 806 (PCE) Communication Protocol (PCEP)", RFC 5440, March 807 2009. 809 [G709-V3] ITU-T, "Interfaces for the Optical Transport Network 810 (OTN)", G.709 Recommendation, December 2009. 812 9.2. Informative References 814 [G709-V1] ITU-T, "Interface for the Optical Transport Network 815 (OTN)," G.709 Recommendation, March 2003. 817 [ITU-T-G.872] ITU-T, "Architecture of optical transport networks", 818 November 2001 (11 2001). 820 [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing 821 and wavelength assignment approaches for wavelength- 822 routed optical WDM networks", Optical Networks Magazine, 823 January 2000. 825 [WSON-FRAME] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 826 and PCE Control of Wavelength Switched Optical Networks 827 (WSON)", draft-ietf-ccamp-rwa-wson-framework, work in 828 progress. 830 [PCE-APS] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai 831 Zhang, "Requirements for GMPLS applications of PCE", 832 draft-ietf-pce-gmpls-aps-req-01.txt, July 2009. 834 [GMPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS 835 Networks", Work in Progress, October 2009. 837 10. Authors' Addresses 839 Fatai Zhang 840 Huawei Technologies 841 F3-5-B R&D Center, Huawei Base 842 Bantian, Longgang District 843 Shenzhen 518129 P.R.China 845 Phone: +86-755-28972912 846 Email: zhangfatai@huawei.com 848 Dan Li 849 Huawei Technologies Co., Ltd. 850 F3-5-B R&D Center, Huawei Base 851 Bantian, Longgang District 852 Shenzhen 518129 P.R.China 854 Phone: +86-755-28973237 855 Email: danli@huawei.com 856 Han Li 857 China Mobile Communications Corporation 858 53 A Xibianmennei Ave. Xuanwu District 859 Beijing 100053 P.R. China 861 Phone: +86-10-66006688 862 Email: lihan@chinamobile.com 864 Sergio Belotti 865 Alcatel-Lucent 866 Optics CTO 867 Via Trento 30 20059 Vimercate (Milano) Italy 868 +39 039 6863033 870 Email: sergio.belotti@alcatel-lucent.it 872 11. Contributors 874 Jianrui Han 875 Huawei Technologies Co., Ltd. 876 F3-5-B R&D Center, Huawei Base 877 Bantian, Longgang District 878 Shenzhen 518129 P.R.China 880 Phone: +86-755-28972913 881 Email: hanjianrui@huawei.com 883 Malcolm Betts 884 Huawei Technologies Co., Ltd. 886 Email: malcolm.betts@huawei.com 888 Pietro Grandi 889 Alcatel-Lucent 890 Optics CTO 891 Via Trento 30 20059 Vimercate (Milano) Italy 892 +39 039 6864930 894 Email: pietro_vittorio.grandi@alcatel-lucent.it 896 Eve Varma 897 Alcatel-Lucent 898 1A-261, 600-700 Mountain Av 899 PO Box 636 900 Murray Hill, NJ 07974-0636 901 USA 902 Email: eve.varma@alcatel-lucent.com 904 APPENDIX A: Description of LO ODU terminology and ODU connection 905 examples. 907 This appendix provides a description of LO ODU terminology and ODU 908 connection examples. This section is not normative which is just a 909 reference in order to facilitate quicker understanding of text. 911 In order to transmit client signal, the LO ODU connection must be 912 created first. From the perspective of [G709-V3], there are two types 913 of LO ODU: 915 (1) A LO ODUj mapped into an OTUk. In this case, the server layer of 916 this LO ODU is an OTUk. For example, if a STM-16 signal is 917 encapsulated into ODU1, and then ODU1 is mapped into OTU1, the ODU1 918 is a LO ODU. 920 (2) A LO ODUj multiplexed into a HO ODUk (j < k) occupying several 921 TSs. In this case, the server layer of this LO ODU is a HO ODUk. For 922 example, if ODU1 is multiplexed into ODU2, and ODU2 is mapped into 923 OTU2, the ODU1 is LO ODU and ODU2 is HO ODU. 925 The LO ODUj represents the container transporting a client of the OTN 926 that is either directly mapped into an OTUk (k = j) or multiplexed 927 into a server HO ODUk (k > j)container. Consequently, the HO ODUk 928 represents the entity transporting a multiplex of LO ODUj tributary 929 signals in its OPUk area. 931 In the case of LO ODUj mapped into an OTUk (k = j) directly, Figure 5 932 give an example of this kind of LO ODU connection. 934 In Figure 5, The LO ODUj is switched at the intermediate ODXC node. 935 OCh and OTUk are associated with each other. From the viewpoint of 936 connection management, the management of OTUk is similar with OCh. LO 937 ODUj and OCh/OTUk have client/server relationships. 939 For example, one LO ODU1 connection can be setup between Node A and 940 Node C. This LO ODU1 connection is to be supported by OCh/OTU1 941 connections, which are to be set up between Node A and Node B and 942 between Node B and Node C. LO ODU1 can be mapped into OTU1 at Node A, 943 demapped from it in Node B, switched at Node B, and then mapped into 944 the next OTU1 and demapped from this OTU1 at Node C. 946 | LO ODUj | 947 +------------------------------(b)---------------------------+ 948 | | OCh/OTUk | | OCh/OTUk | | 949 | +--------(a)---------+ +--------(a)---------+ | 950 | | | | | | 951 +------++-+ +--+---+--+ +-++------+ 952 | |EO| |OE| |EO| |OE| | 953 | +--+----------------+--+ +--+----------------+--+ | 954 | ODXC | | ODXC | | ODXC | 955 +---------+ +---------+ +---------+ 956 Node A Node B Node C 958 Figure 5 Connection of LO ODUj (1) 960 In the case of LO ODUj multiplexing into HO ODUk, Figure 6 gives an 961 example of this kind of LO ODU connection. 963 In Figure 6, OCh, OTUk, HO ODUk are associated with each other. The 964 LO ODUj is multiplexed/de-multiplexed into/from the HO ODU at each 965 ODXC node and switched at each ODXC node (i.e. trib port to line port, 966 line card to line port, line port to trib port). From the viewpoint 967 of connection management, the management of these HO ODUk and OTUk 968 are similar to OCh. LO ODUj and OCh/OTUk/HO ODUk have client/server 969 relationships. when a LO ODU connection is setup, it will be using 970 the existing HO ODUk (/OTUk/OCh) connections which have been set up. 971 Those HO ODUk connections provide LO ODU links, of which the LO ODU 972 connection manager requests a link connection to support the LO ODU 973 connection. 975 For example, one HO ODU2 (/OTU2/OCh) connection can be setup between 976 Node A and Node B, another HO ODU3 (/OTU3/OCh) connection can be 977 setup between Node B and Node C. LO ODU1 can be generated at Node A, 978 switched to one of the 10G line ports and multiplexed into a HO ODU2 979 at Node A, demultiplexed from the HO ODU2 at Node B, switched at Node 980 B to one of the 40G line ports and multiplexed into HO ODU3 at Node B, 981 demultiplexed from HO ODU3 at Node C and switched to its LO ODU1 982 terminating port at Node C. 984 | LO ODUj | 985 +----------------------------(b)-----------------------------+ 986 | | OCh/OTUk/HO ODUk | | OCh/OTUk/HO ODUk | | 987 | +--------(c)---------+ +---------(c)--------+ | 988 | | | | | | 989 +------++-+ +--+---+--+ +-++------+ 990 | |EO| |OE| |EO| |OE| | 991 | +--+----------------+--+ +--+----------------+--+ | 992 | ODXC | | ODXC | | ODXC | 993 +---------+ +---------+ +---------+ 994 Node A Node B Node C 996 Figure 6 Connection of LO ODUj (2) 998 Intellectual Property 1000 The IETF Trust takes no position regarding the validity or scope of 1001 any Intellectual Property Rights or other rights that might be 1002 claimed to pertain to the implementation or use of the technology 1003 described in any IETF Document or the extent to which any license 1004 under such rights might or might not be available; nor does it 1005 represent that it has made any independent effort to identify any 1006 such rights. 1008 Copies of Intellectual Property disclosures made to the IETF 1009 Secretariat and any assurances of licenses to be made available, or 1010 the result of an attempt made to obtain a general license or 1011 permission for the use of such proprietary rights by implementers or 1012 users of this specification can be obtained from the IETF on-line IPR 1013 repository at http://www.ietf.org/ipr 1015 The IETF invites any interested party to bring to its attention any 1016 copyrights, patents or patent applications, or other proprietary 1017 rights that may cover technology that may be required to implement 1018 any standard or specification contained in an IETF Document. Please 1019 address the information to the IETF at ietf-ipr@ietf.org. 1021 The definitive version of an IETF Document is that published by, or 1022 under the auspices of, the IETF. Versions of IETF Documents that are 1023 published by third parties, including those that are translated into 1024 other languages, should not be considered to be definitive versions 1025 of IETF Documents. The definitive version of these Legal Provisions 1026 is that published by, or under the auspices of, the IETF. Versions of 1027 these Legal Provisions that are published by third parties, including 1028 those that are translated into other languages, should not be 1029 considered to be definitive versions of these Legal Provisions. 1031 For the avoidance of doubt, each Contributor to the IETF Standards 1032 Process licenses each Contribution that he or she makes as part of 1033 the IETF Standards Process to the IETF Trust pursuant to the 1034 provisions of RFC 5378. No language to the contrary, or terms, 1035 conditions or rights that differ from or are inconsistent with the 1036 rights and licenses granted under RFC 5378, shall have any effect and 1037 shall be null and void, whether published or posted by such 1038 Contributor, or included with or in such Contribution. 1040 Disclaimer of Validity 1042 All IETF Documents and the information contained therein are provided 1043 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1044 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1045 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1046 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1047 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1048 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1049 FOR A PARTICULAR PURPOSE. 1051 Copyright Notice 1053 Copyright (c) 2010 IETF Trust and the persons identified as the 1054 document authors. All rights reserved. 1056 This document is subject to BCP 78 and the IETF Trust's Legal 1057 Provisions Relating to IETF Documents 1058 (http://trustee.ietf.org/license-info) in effect on the date of 1059 publication of this document. Please review these documents 1060 carefully, as they describe your rights and restrictions with 1061 respect to this document.