idnits 2.17.1 draft-ietf-ccamp-gmpls-g709-framework-00.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 (April 22, 2010) is 5117 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 552, but not defined == Missing Reference: 'RFC4201' is mentioned on line 339, but not defined == Unused Reference: 'HZang00' is defined on line 819, 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: October 22, 2010 April 22, 2010 10 Framework for GMPLS and PCE Control of 11 G.709 Optical Transport Networks 13 draft-ietf-ccamp-gmpls-g709-framework-00.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 October 22, 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 61 Capability 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 489 Link #5 +---------+ Link #4 490 +--------------------------| |-------------------------+ 491 | ------ | 492 | // \\ | 493 | || || | 494 | | RWA domain | | 495 +-+-------+ +----+- || || ------+ +-------+-+ 496 | | | \\ // | | | 497 | |Link #1 | -------- |Link #3 | | 498 | +--------+ | | +--------+ + 499 | ODXC | | ODXC +--------+ ODXC | | ODXC | 500 +---------+ +---------+Link #2 +---------+ +---------+ 501 Node A Node B Node C Node D 503 Figure 3 RWA Hidden Topology for connection LO ODU connection management 505 Link #5 +---------+ Link #4 506 +--------------------------| |-------------------------+ 507 | +----+ ODXC |----+ | 508 | +-++ +---------+ ++-+ | 509 | Node f + + Node E + + Node g | 510 | +-++ ++-+ | 511 | | +--+ | | 512 +-+-------+ +----+----+--| +--+-----+---+ +-------+-+ 513 | |Link #1 | | +--+ | |Link #3 | | 514 | +--------+ | Node h | +--------+ + 515 | ODXC | | ODXC +--------+ ODXC | | ODXC | 516 +---------+ +---------+ Link #2+---------+ +---------+ 517 Node A Node B Node C Node D 519 Figure 4 RWA Visible Topology for LO ODUj connection management 521 In Figure 4, the cloud of previous figure is substitute by the real 522 topology. The nodes f,g,h are nodes with OCH switching capability. 524 In the examples (i.e., Figure 3 and Figure 4), we have considered the 525 case in which LO-ODUj connections are supported by OCh connection, 526 and the case in which the supporting underlying connection can be 527 also made by a combination of HO-ODU/OCh connections. 529 In this case, the ODU routing/path selection process will request an 530 HO-ODU/OCh connection between node C to node E from the RWA domain. 531 The connection will appear at ODU level as a Forwarding Adjacency, 532 which will be used to create the ODU connection. 534 5. GMPLS/PCE Implications 536 The purpose of this section is to provide a framework for extensions 537 of the current GMPLS protocol suite and the PCE applications and 538 protocols to encompass OTN enhancements and connection management. 540 5.1. Implications for LSP Hierarchy with GMPLS TE 542 The path computation for LO ODU connection request is based on the 543 topology of ODU layer, including OCh layer visibility. 545 The OTN path computation can be divided into two layers. One layer is 546 OCh/OTUk, the other is LO ODUj. [RFC4206] defines the mechanisms to 547 accomplish creating the hierarchy of LSPs. The LSP management of 548 multiple layers in OTN can follow the procedures defined in [RFC4206] 549 and related MLN drafts. 551 As discussed in section 4, the route path computation for OCh is in 552 the scope of WSON [WSON-Frame]. Therefore, this document only 553 considers ODU layer for LO ODU connection request. 555 5.2. Implications for GMPLS Signaling 557 The signaling function and Resource reSerVation Protocol-Traffic 558 Engineering (RSVP-TE) extensions are described in [RFC3471] and [RFC 559 3473]. For OTN-specific control, [RFC4328] defines signaling 560 extensions to support G.709 Optical Transport Networks Control as 561 defined in [G709-V1]. 563 As described in Section 2, [G709-V3] introduced some new features 564 that include the ODU0, ODU2e, ODU4 and ODUflex containers. The 565 mechanisms defined in [RFC4328] do not support such new OTN features, 566 and protocol extensions will be necessary to allow them to be 567 controlled by a GMPLS control plane. 569 5.2.1. Identifying OTN signals 571 [RFC4328] defines the LSP Encoding Type, the Switching Type and the 572 Generalized Protocol Identifier (Generalized-PID) constituting the 573 common part of the Generalized Label Request. The G.709 Traffic 574 Parameters are also defined in [RFC4328]. The following new signal 575 types have been added since [RFC4328] was published: 577 (1)New signal types of sub-lambda layer 579 Optical Channel Data Unit (ODUj): 581 ODU0 583 ODU2e 585 ODU4 587 ODUflex 589 (2)A new Tributary Slot (TS) granularity (i.e., 1.25 Gbps) 591 (3)Signal type with variable bandwidth: 593 ODUflex has a variable bandwidth/bit rate BR and a bit rate 594 tolerance T. As described above the (node local) mapping process 595 must be aware of the bit rate and tolerance of the ODUj being 596 multiplexed in order to select the correct number of TS and the 597 fixed/variable stuffing bytes. Therefore, bit rate and bit rate 598 tolerance should be carried in the Traffic Parameter in the 599 signaling of connection setup request. 601 (4)Extended multiplexing hierarchy (For example, ODU0 into OTU2 602 multiplexing (with 1,25Gbps TS granularity).) 604 So the encoding provided in [RFC4328] needs to be extended to support 605 all the signal types and related mapping and multiplexing with all 606 kinds of tributary slots. Moreover, the extensions should consider 607 the extensibility to match future evolvement of OTN. 609 For item (1) and (3), new traffic parameters may need to be extended 610 in signaling message; 612 For item (2) and (4), new label should be defined to carry the exact 613 TS allocation information related to the extended multiplexing 614 hierarchy. 616 5.2.2. Tributary Port Number 618 The tributary port number may be assigned locally by the node at the 619 (traffic) ingress end of the link and in this case as described above 620 must be conveyed to the far end of the link as a "transparent" 621 parameter i.e. the control plane does not need to understand this 622 information. The TPN may also be assigned by the control plane as a 623 part of path computation. 625 5.3. Implications for GMPLS Routing 627 The path computation process should select a suitable route for a 628 ODUj connection request. In order to compute the lowest cost path it 629 must evaluate the number (and availability) of tributary slots on 630 each candidate link. The routing protocol should be extended to 631 convey some information to represent ODU TE topology. As described 632 above the number of tributary slots (on a link bundle), the bandwidth 633 of the TS and the maximum number that are available to convey a 634 single ODUj must be provided. 636 GMPLS Routing [RFC4202] defines Interface Switching Capability 637 Descriptor of TDM which can be used for ODU. However, some other 638 issues should also be considered which are discussed below. 640 5.3.1. Requirement for conveying Interface Switching Capability specific 641 information 643 Interface Switching Capability Descriptors present a new constraint 644 for LSP path computation. [RFC4203] defines the switching capability 645 and related Maximum LSP Bandwidth and the Switching Capability 646 specific information. When the Switching Capability field is TDM the 647 Switching Capability specific information field includes Minimum LSP 648 Bandwidth, an indication whether the interface supports Standard or 649 Arbitrary SONET/SDH, and padding. So routing protocol should be 650 extended when TDM is ODU type to support representation of ODU 651 switching information. 653 As discussed in section 3.1.2, many different types of ODUj can be 654 multiplexed into the same OTUk. For example, both ODU0 and ODU1 may 655 be multiplexed into ODU2. An OTU link may support one or more types 656 of ODUj signals. The routing protocol should be extended to carry 657 this multiplexing capability. Furthermore, one type of ODUj can be 658 multiplexed to an OTUk using different tributary slot granularity. 659 For example, ODU1 can be multiplexed into ODU2 with either 2.5Gbps TS 660 granularity or 1.25G TS granularity. The routing protocol should be 661 extended to carry which TS granularity supported by the ODU interface. 663 Moreover, the bit rate (i.e., bandwidth) of TS can be determined by 664 the TS granularity and link type of the TE link. For example, the 665 bandwidth of a 1.25G TS without NJO (Negative Justification 666 Opportunity) in an OTU2 is about 1.249409620 Gbps, while the 667 bandwidth of a 1.25G TS without NJO in an OTU3 is about 1.254703729 668 Gbps. So The routing protocol should be extended to carry the TE link 669 type (OTUk/HO ODUk). 671 In OTN networks, it is simpler to use the number of Tributary Slots 672 for the bandwidth accounting. For example, Total bandwidth of the TE 673 link, Unreserved Bandwidth of the TE link and the Maximum LSP 674 Bandwidth can be accounted through the number of Tributary Slots 675 (e.g., the total number of the Tributary Slots of the TE link, the 676 unreserved Tributary Slots of the TE link, Maximum Tributary Slots 677 for an LSP). Thus, the routing protocol should be extended to carry 678 the Tributary Slots information related to bandwidth of the TE link. 680 5.4. Implications for Link Management Protocol (LMP) 682 As discussed in section 5.3, Path computation needs to know the 683 interface switching capability of links. The switching capability of 684 two ends of the link may be different, so the link capability of two 685 ends should be correlated. 687 The Link Management Protocol (LMP) [RFC4204] provides a control plane 688 protocol for exchanging and correlating link capabilities. 690 It is not necessary to use LMP to correlate link-end capabilities if 691 the information is available from another source such as management 692 configuration or automatic discovery/negotiation within the data 693 plane. 695 Note that LO ODU type information can be, in principle, discovered by 696 routing. Since in certain case, routing is not present (e.g. UNI case) 697 we need to extend link management protocol capabilities to cover this 698 aspect. In case of routing presence, the discovering procedure by LMP 699 could also be optional. 701 5.4.1. Correlating the Granularity of the TS 703 As discussed in section 3.1.2, the two ends of a link may support 704 different TS granularity. In order to allow interconnection the node 705 with 1.25Gb/s granularity must fall back to 2.5Gb/s granularity. 707 Therefore, it is necessary for the two ends of a link to correlate 708 the granularity of the TS. This ensures that both ends of the link 709 advertise consistent capabilities (for routing) and ensures that 710 viable connections are established. 712 5.4.2. Correlating the Supported LO ODU Signal Types 714 Many new ODU signal types have been introduced [G709-V3], such as 715 ODU0, ODU4, ODU2e and ODUflex. It is possible that equipment does not 716 support all the LO ODU signal types introduced by those new standards 717 or drafts. If one end of a link can not support a certain LO ODU 718 signal type, the link cannot be selected to carry such type of LO ODU 719 connection. 721 Therefore, it is necessary for the two ends of an HO ODU link to 722 correlate which types of LO ODU can be supported by the link. After 723 correlating, the capability information can be flooded by IGP, so 724 that the correct path for an ODU connection can be calculated. 726 5.5. Implications for Path Computation Elements 728 [PCE-APS] describes the requirements for GMPLS applications of PCE in 729 order to establish GMPLS LSP. PCE needs to consider the GMPLS TE 730 attributes appropriately once a PCC or another PCE requests a path 731 computation. The TE attributes which can be contained in the path 732 calculation request message from the PCC or the PCE defined in 733 [RFC5440] includes switching capability, encoding type, signal type, 734 etc. 736 As described in section 5.2.1, new signal types and new signals with 737 variable bandwidth information need to be carried in the extended 738 signaling message of path setup. For the same consideration, PCECP 739 also has a desire to be extended to carry the new signal type and 740 related variable bandwidth information when a PCC requests a path 741 computation. 743 6. Security Considerations 745 The use of control plane protocols for signaling, routing, and path 746 computation opens an OTN to security threats through attacks on those 747 protocols. The data plane technology for an OTN does not introduce 748 any specific vulnerabilities, and so the control plane may be secured 749 using the mechanisms defined for the protocols discussed. 751 For further details of the specific security measures refer to the 752 documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], 753 [RFC4204], and [RFC5440]). [GMPLS-SEC] provides an overview of 754 security vulnerabilities and protection mechanisms for the GMPLS 755 control plane. 757 7. IANA Considerations 759 This document makes not requests for IANA action. 761 8. Acknowledgments 763 We would like to thank Maarten Vissers for his review and useful 764 comments. 766 9. References 768 9.1. Normative References 770 [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label 771 Switching (GMPLS) Signaling Extensions for G.709 Optical 772 Transport Networks Control", RFC 4328, Jan 2006. 774 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 775 Switching (GMPLS) Signaling Functional Description", 776 RFC 3471, January 2003. 778 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 779 Switching (GMPLS) Signaling Resource ReserVation 780 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 781 3473, January 2003. 783 [RFC4202] K. Kompella, Y. Rekhter, Ed., "Routing Extensions in 784 Support of Generalized Multi-Protocol Label Switching 785 (GMPLS)", RFC 4202, October 2005. 787 [RFC4203] K. Kompella, Y. Rekhter, Ed., "OSPF Extensions in Support 788 of Generalized Multi-Protocol Label Switching (GMPLS)", 789 RFC 4203, October 2005. 791 [RFC4205] K. Kompella, Y. Rekhter, Ed., "Intermediate System to 792 Intermediate System (IS-IS) Extensions in Support of 793 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 794 4205, October 2005. 796 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 797 4204, October 2005. 799 [RFC4206] K. Kompella, Y. Rekhter, Ed., " Label Switched Paths 800 (LSP) Hierarchy with Generalized Multi-Protocol Label 801 Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, 802 October 2005. 804 [RFC5440] JP. Vasseur, JL. Le Roux, Ed.," Path Computation Element 805 (PCE) Communication Protocol (PCEP)", RFC 5440, March 806 2009. 808 [G709-V3] ITU-T, "Interfaces for the Optical Transport Network 809 (OTN)", G.709 Recommendation, December 2009. 811 9.2. Informative References 813 [G709-V1] ITU-T, "Interface for the Optical Transport Network 814 (OTN)," G.709 Recommendation, March 2003. 816 [ITU-T-G.872] ITU-T, "Architecture of optical transport networks", 817 November 2001 (11 2001). 819 [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing 820 and wavelength assignment approaches for wavelength- 821 routed optical WDM networks", Optical Networks Magazine, 822 January 2000. 824 [WSON-FRAME] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 825 and PCE Control of Wavelength Switched Optical Networks 826 (WSON)", draft-ietf-ccamp-rwa-wson-framework, work in 827 progress. 829 [PCE-APS] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai 830 Zhang, "Requirements for GMPLS applications of PCE", 831 draft-ietf-pce-gmpls-aps-req-01.txt, July 2009. 833 [GMPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS 834 Networks", Work in Progress, October 2009. 836 10. Authors' Addresses 838 Fatai Zhang 839 Huawei Technologies 840 F3-5-B R&D Center, Huawei Base 841 Bantian, Longgang District 842 Shenzhen 518129 P.R.China 844 Phone: +86-755-28972912 845 Email: zhangfatai@huawei.com 847 Dan Li 848 Huawei Technologies Co., Ltd. 849 F3-5-B R&D Center, Huawei Base 850 Bantian, Longgang District 851 Shenzhen 518129 P.R.China 853 Phone: +86-755-28973237 854 Email: danli@huawei.com 855 Han Li 856 China Mobile Communications Corporation 857 53 A Xibianmennei Ave. Xuanwu District 858 Beijing 100053 P.R. China 860 Phone: +86-10-66006688 861 Email: lihan@chinamobile.com 863 Sergio Belotti 864 Alcatel-Lucent 865 Optics CTO 866 Via Trento 30 20059 Vimercate (Milano) Italy 867 +39 039 6863033 869 Email: sergio.belotti@alcatel-lucent.it 871 11. Contributors 873 Jianrui Han 874 Huawei Technologies Co., Ltd. 875 F3-5-B R&D Center, Huawei Base 876 Bantian, Longgang District 877 Shenzhen 518129 P.R.China 879 Phone: +86-755-28972913 880 Email: hanjianrui@huawei.com 882 Malcolm Betts 883 Huawei Technologies Co., Ltd. 885 Email: malcolm.betts@huawei.com 887 Pietro Grandi 888 Alcatel-Lucent 889 Optics CTO 890 Via Trento 30 20059 Vimercate (Milano) Italy 891 +39 039 6864930 893 Email: pietro_vittorio.grandi@alcatel-lucent.it 895 Eve Varma 896 Alcatel-Lucent 897 1A-261, 600-700 Mountain Av 898 PO Box 636 899 Murray Hill, NJ 07974-0636 900 USA 901 Email: eve.varma@alcatel-lucent.com 903 APPENDIX A: Description of LO ODU terminology and ODU connection 904 examples. 906 This appendix provides a description of LO ODU terminology and ODU 907 connection examples. This section is not normative which is just a 908 reference in order to facilitate quicker understanding of text. 910 In order to transmit client signal, the LO ODU connection must be 911 created first. From the perspective of [G709-V3], there are two types 912 of LO ODU: 914 (1) A LO ODUj mapped into an OTUk. In this case, the server layer of 915 this LO ODU is an OTUk. For example, if a STM-16 signal is 916 encapsulated into ODU1, and then ODU1 is mapped into OTU1, the ODU1 917 is a LO ODU. 919 (2) A LO ODUj multiplexed into a HO ODUk (j < k) occupying several 920 TSs. In this case, the server layer of this LO ODU is a HO ODUk. For 921 example, if ODU1 is multiplexed into ODU2, and ODU2 is mapped into 922 OTU2, the ODU1 is LO ODU and ODU2 is HO ODU. 924 The LO ODUj represents the container transporting a client of the OTN 925 that is either directly mapped into an OTUk (k = j) or multiplexed 926 into a server HO ODUk (k > j)container. Consequently, the HO ODUk 927 represents the entity transporting a multiplex of LO ODUj tributary 928 signals in its OPUk area. 930 In the case of LO ODUj mapped into an OTUk (k = j) directly, Figure 5 931 give an example of this kind of LO ODU connection. 933 In Figure 5, The LO ODUj is switched at the intermediate ODXC node. 934 OCh and OTUk are associated with each other. From the viewpoint of 935 connection management, the management of OTUk is similar with OCh. LO 936 ODUj and OCh/OTUk have client/server relationships. 938 For example, one LO ODU1 connection can be setup between Node A and 939 Node C. This LO ODU1 connection is to be supported by OCh/OTU1 940 connections, which are to be set up between Node A and Node B and 941 between Node B and Node C. LO ODU1 can be mapped into OTU1 at Node A, 942 demapped from it in Node B, switched at Node B, and then mapped into 943 the next OTU1 and demapped from this OTU1 at Node C. 945 | LO ODUj | 946 +------------------------------(b)---------------------------+ 947 | | OCh/OTUk | | OCh/OTUk | | 948 | +--------(a)---------+ +--------(a)---------+ | 949 | | | | | | 950 +------++-+ +--+---+--+ +-++------+ 951 | |EO| |OE| |EO| |OE| | 952 | +--+----------------+--+ +--+----------------+--+ | 953 | ODXC | | ODXC | | ODXC | 954 +---------+ +---------+ +---------+ 955 Node A Node B Node C 957 Figure 5 Connection of LO ODUj (1) 959 In the case of LO ODUj multiplexing into HO ODUk, Figure 6 gives an 960 example of this kind of LO ODU connection. 962 In Figure 6, OCh, OTUk, HO ODUk are associated with each other. The 963 LO ODUj is multiplexed/de-multiplexed into/from the HO ODU at each 964 ODXC node and switched at each ODXC node (i.e. trib port to line port, 965 line card to line port, line port to trib port). From the viewpoint 966 of connection management, the management of these HO ODUk and OTUk 967 are similar to OCh. LO ODUj and OCh/OTUk/HO ODUk have client/server 968 relationships. when a LO ODU connection is setup, it will be using 969 the existing HO ODUk (/OTUk/OCh) connections which have been set up. 970 Those HO ODUk connections provide LO ODU links, of which the LO ODU 971 connection manager requests a link connection to support the LO ODU 972 connection. 974 For example, one HO ODU2 (/OTU2/OCh) connection can be setup between 975 Node A and Node B, another HO ODU3 (/OTU3/OCh) connection can be 976 setup between Node B and Node C. LO ODU1 can be generated at Node A, 977 switched to one of the 10G line ports and multiplexed into a HO ODU2 978 at Node A, demultiplexed from the HO ODU2 at Node B, switched at Node 979 B to one of the 40G line ports and multiplexed into HO ODU3 at Node B, 980 demultiplexed from HO ODU3 at Node C and switched to its LO ODU1 981 terminating port at Node C. 983 | LO ODUj | 984 +----------------------------(b)-----------------------------+ 985 | | OCh/OTUk/HO ODUk | | OCh/OTUk/HO ODUk | | 986 | +--------(c)---------+ +---------(c)--------+ | 987 | | | | | | 988 +------++-+ +--+---+--+ +-++------+ 989 | |EO| |OE| |EO| |OE| | 990 | +--+----------------+--+ +--+----------------+--+ | 991 | ODXC | | ODXC | | ODXC | 992 +---------+ +---------+ +---------+ 993 Node A Node B Node C 995 Figure 6 Connection of LO ODUj (2) 997 Intellectual Property 999 The IETF Trust takes no position regarding the validity or scope of 1000 any Intellectual Property Rights or other rights that might be 1001 claimed to pertain to the implementation or use of the technology 1002 described in any IETF Document or the extent to which any license 1003 under such rights might or might not be available; nor does it 1004 represent that it has made any independent effort to identify any 1005 such rights. 1007 Copies of Intellectual Property disclosures made to the IETF 1008 Secretariat and any assurances of licenses to be made available, or 1009 the result of an attempt made to obtain a general license or 1010 permission for the use of such proprietary rights by implementers or 1011 users of this specification can be obtained from the IETF on-line IPR 1012 repository at http://www.ietf.org/ipr 1014 The IETF invites any interested party to bring to its attention any 1015 copyrights, patents or patent applications, or other proprietary 1016 rights that may cover technology that may be required to implement 1017 any standard or specification contained in an IETF Document. Please 1018 address the information to the IETF at ietf-ipr@ietf.org. 1020 The definitive version of an IETF Document is that published by, or 1021 under the auspices of, the IETF. Versions of IETF Documents that are 1022 published by third parties, including those that are translated into 1023 other languages, should not be considered to be definitive versions 1024 of IETF Documents. The definitive version of these Legal Provisions 1025 is that published by, or under the auspices of, the IETF. Versions of 1026 these Legal Provisions that are published by third parties, including 1027 those that are translated into other languages, should not be 1028 considered to be definitive versions of these Legal Provisions. 1030 For the avoidance of doubt, each Contributor to the IETF Standards 1031 Process licenses each Contribution that he or she makes as part of 1032 the IETF Standards Process to the IETF Trust pursuant to the 1033 provisions of RFC 5378. No language to the contrary, or terms, 1034 conditions or rights that differ from or are inconsistent with the 1035 rights and licenses granted under RFC 5378, shall have any effect and 1036 shall be null and void, whether published or posted by such 1037 Contributor, or included with or in such Contribution. 1039 Disclaimer of Validity 1041 All IETF Documents and the information contained therein are provided 1042 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1043 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1044 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1045 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1046 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1047 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1048 FOR A PARTICULAR PURPOSE. 1050 Copyright Notice 1052 Copyright (c) 2010 IETF Trust and the persons identified as the 1053 document authors. All rights reserved. 1055 This document is subject to BCP 78 and the IETF Trust's Legal 1056 Provisions Relating to IETF Documents 1057 (http://trustee.ietf.org/license-info) in effect on the date of 1058 publication of this document. Please review these documents 1059 carefully, as they describe your rights and restrictions with respect 1060 to this document. Code Components extracted from this document must 1061 include Simplified BSD License text as described in Section 4.e of 1062 the Trust Legal Provisions and are provided without warranty as 1063 described in the Simplified BSD License.