idnits 2.17.1 draft-ietf-ccamp-gmpls-g709-framework-09.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 10 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 25, 2012) is 4262 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 108, but not defined == Missing Reference: 'G872Am2' is mentioned on line 150, but not defined == Missing Reference: 'G.7042' is mentioned on line 607, but not defined == Missing Reference: 'RFC3209' is mentioned on line 625, but not defined == Unused Reference: 'RFC4201' is defined on line 924, but no explicit reference was found in the text == Unused Reference: 'G7042' is defined on line 977, but no explicit reference was found in the text == Unused Reference: 'HZang00' is defined on line 989, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4205 (Obsoleted by RFC 5307) Summary: 2 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, Ed. 2 Internet Draft Dan Li 3 Category: Informational Huawei 4 Han Li 5 CMCC 6 S.Belotti 7 Alcatel-Lucent 8 D. Ceccarelli 9 Ericsson 10 Expires: February 25, 2013 August 25, 2012 12 Framework for GMPLS and PCE Control of 13 G.709 Optical Transport Networks 15 draft-ietf-ccamp-gmpls-g709-framework-09.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with 20 the provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 25, 2013. 40 Abstract 42 This document provides a framework to allow the development of 43 protocol extensions to support Generalized Multi-Protocol Label 44 Switching (GMPLS) and Path Computation Element (PCE) control of 45 Optical Transport Networks (OTN) as specified in ITU-T Recommendation 46 G.709 as consented in October 2009. 48 Table of Contents 50 1. Introduction .................................................. 2 51 2. Terminology ................................................... 3 52 3. G.709 Optical Transport Network (OTN) ......................... 4 53 3.1. OTN Layer Network ........................................ 4 54 3.1.1. Client signal mapping ............................... 5 55 3.1.2. Multiplexing ODUj onto Links ........................ 6 56 3.1.2.1. Structure of MSI information ................... 8 57 4. Connection management in OTN .................................. 9 58 4.1. Connection management of the ODU ........................ 10 59 5. GMPLS/PCE Implications ....................................... 12 60 5.1. Implications for LSP Hierarchy with GMPLS TE ............ 12 61 5.2. Implications for GMPLS Signaling ........................ 13 62 5.3. Implications for GMPLS Routing .......................... 15 63 5.4. Implications for Link Management Protocol (LMP) ......... 17 64 5.5. Implications for Control Plane Backward Compatibility ... 18 65 5.6. Implications for Path Computation Elements .............. 19 66 6. Data Plane Backward Compatibility Considerations ............. 20 67 7. Security Considerations ...................................... 20 68 8. IANA Considerations .......................................... 21 69 9. Acknowledgments .............................................. 21 70 10. References .................................................. 21 71 10.1. Normative References ................................... 21 72 10.2. Informative References ................................. 22 73 11. Authors' Addresses .......................................... 23 74 12. Contributors ................................................ 24 75 APPENDIX A: ODU connection examples ............................. 25 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 91 [RFC3471] and [RFC3473], routing and OSPF extensions are described in 92 [RFC4202] and [RFC4203], and the Link Management Protocol (LMP) is 93 described in [RFC4204]. 95 The GMPLS protocol suite including provision [RFC4328] provides the 96 mechanisms for basic GMPLS control of OTN networks based on the 2001 97 revision of the G.709 specification [G709-V1]. Later revisions of the 98 G.709 specification, including [G709-V3], have included some new 99 features; for example, various multiplexing structures, two types of 100 TSs (i.e., 1.25Gbps and 2.5Gbps), and extension of the Optical Data 101 Unit (ODU) ODUj definition to include the ODUflex function. 103 This document reviews relevant aspects of OTN technology evolution 104 that affect the GMPLS control plane protocols and examines why and 105 how to update the mechanisms described in [RFC4328]. This document 106 additionally provides a framework for the GMPLS control of OTN 107 networks and includes a discussion of the implication for the use of 108 the Path Computation Element (PCE) [RFC4655]. 110 For the purposes of the control plane the OTN can be considered as 111 being comprised of ODU and wavelength (OCh) layers. This document 112 focuses on the control of the ODU layer, with control of the 113 wavelength layer considered out of the scope. Please refer to 114 [RFC6163] for further information about the wavelength layer. 116 2. Terminology 118 OTN: Optical Transport Network 120 ODU: Optical Channel Data Unit 122 OTU: Optical channel transport unit 124 OMS: Optical multiplex section 126 MSI: Multiplex Structure Identifier 128 TPN: Tributary Port Number 130 LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4, 131 flex.) represents the container transporting a client of the OTN that 132 is either directly mapped into an OTUk (k = j) or multiplexed into a 133 server HO ODUk (k > j) container. 135 HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, 4.) 136 represents the entity transporting a multiplex of LO ODUj tributary 137 signals in its OPUk area. 139 ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a 140 bit rate tolerance up to +/-100 ppm. 142 3. G.709 Optical Transport Network (OTN) 144 This section provides an informative overview of those aspects of the 145 OTN impacting control plane protocols. This overview is based on the 146 ITU-T Recommendations that contain the normative definition of the 147 OTN. Technical details regarding OTN architecture and interfaces are 148 provided in the relevant ITU-T Recommendations. 150 Specifically, [G872-2001] and [G872Am2] describe the functional 151 architecture of optical transport networks providing optical signal 152 transmission, multiplexing, routing, supervision, performance 153 assessment, and network survivability. [G709-V1] defines the 154 interfaces of the optical transport network to be used within and 155 between subnetworks of the optical network. With the evolution and 156 deployment of OTN technology many new features have been specified in 157 ITU-T recommendations, including for example, new ODU0, ODU2e, ODU4 158 and ODUflex containers as described in [G709-V3]. 160 3.1. OTN Layer Network 162 The simplified signal hierarchy of OTN is shown in Figure 1, which 163 illustrates the layers that are of interest to the control plane. 164 Other layers below OCh (e.g. Optical Transmission Section - OTS) are 165 not included in this Figure. The full signal hierarchy is provided in 166 [G709-V3]. 168 Client signal 169 | 170 ODUj 171 | 172 OTU/OCh 173 OMS 175 Figure 1 - Basic OTN signal hierarchy 177 Client signals are mapped into ODUj containers. These ODUj containers 178 are multiplexed onto the OTU/OCh. The individual OTU/OCh signals are 179 combined in the Optical Multiplex Section (OMS) using WDM 180 multiplexing, and this aggregated signal provides the link between 181 the nodes. 183 3.1.1. Client signal mapping 185 The client signals are mapped into a Low Order (LO) ODUj. Appendix A 186 gives more information about LO ODU. 188 The current values of j defined in [G709-V3] are: 0, 1, 2, 2e, 3, 4, 189 Flex. The approximate bit rates of these signals are defined in 190 [G709-V3] and are reproduced in Tables 1 and 2. 192 +-----------------------+-----------------------------------+ 193 | ODU Type | ODU nominal bit rate | 194 +-----------------------+-----------------------------------+ 195 | ODU0 | 1 244 160 kbits/s | 196 | ODU1 | 239/238 x 2 488 320 kbit/s | 197 | ODU2 | 239/237 x 9 953 280 kbit/s | 198 | ODU3 | 239/236 x 39 813 120 kbit/s | 199 | ODU4 | 239/227 x 99 532 800 kbit/s | 200 | ODU2e | 239/237 x 10 312 500 kbit/s | 201 | | | 202 | ODUflex for CBR | | 203 | Client signals | 239/238 x client signal bit rate | 204 | | | 205 | ODUflex for GFP-F | | 206 | Mapped client signal | Configured bit rate | 207 +-----------------------+-----------------------------------+ 209 Table 1 - ODU types and bit rates 211 NOTE - The nominal ODUk rates are approximately: 2 498 775.126 kbit/s 212 (ODU1), 10 037 273.924 kbit/s (ODU2), 40 319 218.983 kbit/s (ODU3), 213 104 794 445.815 kbit/s (ODU4) and 10 399 525.316 kbit/s (ODU2e). 215 +-----------------------+-----------------------------------+ 216 | ODU Type | ODU bit-rate tolerance | 217 +-----------------------+-----------------------------------+ 218 | ODU0 | +- 20 ppm | 219 | ODU1 | +- 20 ppm | 220 | ODU2 | +- 20 ppm | 221 | ODU3 | +- 20 ppm | 222 | ODU4 | +- 20 ppm | 223 | ODU2e | +- 100 ppm | 224 | | | 225 | ODUflex for CBR | | 226 | Client signals | +- 100 ppm | 227 | | | 228 | ODUflex for GFP-F | | 229 | Mapped client signal | +- 100 ppm | 230 +-----------------------+-----------------------------------+ 231 Table 2 - ODU types and tolerance 233 One of two options is for mapping client signals into ODUflex 234 depending on the client signal type: 236 - Circuit clients are proportionally wrapped. Thus the bit rate and 237 tolerance are defined by the client signal. 239 - Packet clients are mapped using the Generic Framing Procedure 240 (GFP). [G709-V3] recommends that the ODUflex(GFP) will fill an 241 integral number of tributary slots of the smallest HO ODUk path 242 over which the ODUflex(GFP) may be carried, and the tolerance 243 should be +/-100ppm. 245 3.1.2. Multiplexing ODUj onto Links 247 The links between the switching nodes are provided by one or more 248 wavelengths. Each wavelength carries one OCh, which carries one OTU, 249 which carries one ODU. Since all of these signals have a 1:1:1 250 relationship, we only refer to the OTU for clarity. The ODUjs are 251 mapped into the TS of the OPUk. Note that in the case where j=k the 252 ODUj is mapped into the OTU/OCh without multiplexing. 254 The initial versions of G.709 [G709-V1] only provided a single TS 255 granularity, nominally 2.5Gb/s. [G709-V3], approved in 2009, added an 256 additional TS granularity, nominally 1.25Gb/s. The number and type of 257 TSs provided by each of the currently identified OTUk is provided 258 below: 260 2.5Gb/s 1.25Gb/s Nominal Bit rate 261 OTU1 1 2 2.5Gb/s 262 OTU2 4 8 10Gb/s 263 OTU3 16 32 40Gb/s 264 OTU4 -- 80 100Gb/s 266 To maintain backwards compatibility while providing the ability to 267 interconnect nodes that support 1.25Gb/s TS at one end of a link and 268 2.5Gb/s TS at the other, the 'new' equipment will fall back to the 269 use of a 2.5Gb/s TS if connected to legacy equipment. This 270 information is carried in band by the payload type. 272 The actual bit rate of the TS in an OTUk depends on the value of k. 273 Thus the number of TS occupied by an ODUj may vary depending on the 274 values of j and k. For example an ODU2e uses 9 TS in an OTU3 but 275 only 8 in an OTU4. Examples of the number of TS used for various 276 cases are provided below: 278 - ODU0 into ODU1, ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS 279 granularity 280 o ODU0 occupies 1 of the 2, 8, 32 or 80 TS for ODU1, ODU2, ODU3 281 or ODU4 282 - ODU1 into ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS 283 granularity 284 o ODU1 occupies 2 of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4 286 - ODU1 into ODU2, ODU3 multiplexing with 2.5Gbps TS granularity 287 o ODU1 occupies 1 of the 4 or 16 TS for ODU2 or ODU3 289 - ODU2 into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity 290 o ODU2 occupies 8 of the 32 or 80 TS for ODU3 or ODU4 292 - ODU2 into ODU3 multiplexing with 2.5Gbps TS granularity 293 o ODU2 occupies 4 of the 16 TS for ODU3 295 - ODU3 into ODU4 multiplexing with 1.25Gbps TS granularity 296 o ODU3 occupies 31 of the 80 TS for ODU4 298 - ODUflex into ODU2, ODU3 or ODU4 multiplexing with 1.25Gbps TS 299 granularity 300 o ODUflex occupies n of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4 301 (n <= Total TS numbers of ODUk) 303 - ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity 304 o ODU2e occupies 9 of the 32 TS for ODU3 or 8 of the 80 TS for 305 ODU4 307 In general the mapping of an ODUj (including ODUflex) into the OTUk 308 TSs is determined locally, and it can also be explicitly controlled 309 by a specific entity (e.g., head end, NMS) through Explicit Label 310 Control [RFC3473]. 312 3.1.2.1. Structure of MSI information 314 When multiplexing an ODUj into a HO ODUk (k>j), G.709 specifies the 315 information that has to be transported in-band in order to allow for 316 correct demultiplexing. This information, known as Multiplex 317 Structure Information (MSI), is transported in the OPUk overhead and 318 is local to each link. In case of bidirectional paths the association 319 between TPN and TS must be the same in both directions. 321 The MSI information is organized as a set of entries, with one entry 322 for each HO ODUj TS. The information carried by each entry is: 324 - Payload Type: the type of the transported payload. 326 - Tributary Port Number (TPN): the port number of the ODUj 327 transported by the HO ODUk. The TPN is the same for all the TSs 328 assigned to the transport of the same ODUj instance. 330 For example, an ODU2 carried by a HO ODU3 is described by 4 entries 331 in the OPU3 overhead when the TS size is 2.5 Gbit/s, and by 8 entries 332 when the TS size is 1.25 Gbit/s. 334 On each node and on every link, two MSI values have to be provisioned: 336 - The TxMSI information inserted in OPU (e.g., OPU3) overhead by the 337 source of the HO ODUk trail. 339 - The expectedMSI information that is used to check the acceptedMSI 340 information. The acceptedMSI information is the MSI valued 341 received in-band, after a 3 frames integration. 343 The sink of the HO ODU trail checks the complete content of the 344 acceptedMSI information against the expectedMSI. 346 If the acceptedMSI is different from the expectedMSI, then the 347 traffic is dropped and a payload mismatch alarm is generated. 349 Provisioning of TPN can be performed either by network management 350 system or control plane. In the last case, control plane is also 351 responsible for negotiating the provisioned values on a link by link 352 base. 354 4. Connection management in OTN 356 OTN-based connection management is concerned with controlling the 357 connectivity of ODU paths and optical channels (OCh). This document 358 focuses on the connection management of ODU paths. The management of 359 OCh paths is described in [RFC6163]. 361 While [G872-2001] considered the ODU as a set of layers in the same 362 way as SDH has been modeled, recent ITU-T OTN architecture progress 363 [G872-Am2] includes an agreement to model the ODU as a single layer 364 network with the bit rate as a parameter of links and connections. 365 This allows the links and nodes to be viewed in a single topology as 366 a common set of resources that are available to provide ODUj 367 connections independent of the value of j. Note that when the bit 368 rate of ODUj is less than the server bit rate, ODUj connections are 369 supported by HO-ODU (which has a one-to-one relationship with the 370 OTU). 372 From an ITU-T perspective, the ODU connection topology is represented 373 by that of the OTU link layer, which has the same topology as that of 374 the OCh layer (independent of whether the OTU supports HO-ODU, where 375 multiplexing is utilized, or LO-ODU in the case of direct mapping). 376 Thus, the OTU and OCh layers should be visible in a single 377 topological representation of the network, and from a logical 378 perspective, the OTU and OCh may be considered as the same logical, 379 switchable entity. 381 Note that the OTU link layer topology may be provided via various 382 infrastructure alternatives, including point-to-point optical 383 connections, flexible optical connections fully in the optical domain, 384 flexible optical connections involving hybrid sub-lambda/lambda nodes 385 involving 3R, etc. 387 The document will be updated to maintain consistency with G.872 388 progress when it is consented for publication. 390 4.1. Connection management of the ODU 392 LO ODUj can be either mapped into the OTUk signal (j = k), or 393 multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is 394 mapped into an OCh. See Appendix A for more information. 396 From the perspective of control plane, there are two kinds of network 397 topology to be considered. 399 (1) ODU layer 401 In this case, the ODU links are presented between adjacent OTN nodes, 402 which is illustrated in Figure 2. In this layer there are ODU links 403 with a variety of TSs available, and nodes that are ODXCs. Lo ODU 404 connections can be setup based on the network topology. 406 Link #5 +--+---+--+ Link #4 407 +--------------------------| |--------------------------+ 408 | | ODXC | | 409 | +---------+ | 410 | Node E | 411 | | 412 +-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++ 413 | |Link #1 | |Link #2 | |Link #3 | | 414 | |--------| |--------| |--------| | 415 | ODXC | | ODXC | | ODXC | | ODXC | 416 +---------+ +---------+ +---------+ +---------+ 417 Node A Node B Node C Node D 419 Figure 2 - Example Topology for LO ODU connection management 421 If an ODUj connection is requested between Node C and Node E 422 routing/path computation must select a path that has the required 423 number of TS available and that offers the lowest cost. Signaling is 424 then invoked to set up the path and to provide the information (e.g., 425 selected TS) required by each transit node to allow the configuration 426 of the ODUj to OTUk mapping (j = k) or multiplexing (j < k), and 427 demapping (j = k) or demultiplexing (j < k). 429 (2) ODU layer with OCh switching capability 431 In this case, the OTN nodes interconnect with wavelength switched 432 node (e.g., ROADM, OXC) that are capable of OCh switching, which is 433 illustrated in Figure 3 and Figure 4. There are ODU layer and OCh 434 layer, so it is simply a MLN. OCh connections may be created on 435 demand, which is described in section 5.1. 437 In this case, an operator may choose to allow the underlined OCh 438 layer to be visible to the ODU routing/path computation process in 439 which case the topology would be as shown in Figure 4. In Figure 3 440 below, instead, a cloud representing OCH capable switching nodes is 441 represented. In Figure 3, the operator choice is to hide the real RWA 442 network topology. 444 Node E 445 Link #5 +--------+ Link #4 446 +------------------------| |------------------------+ 447 | ------ | 448 | // \\ | 449 | || || | 450 | | RWA domain | | 451 +-+-----+ +------ || || ------+ +-----+-+ 452 | | | \\ // | | | 453 | |Link #1 | -------- |Link #3 | | 454 | +--------+ | | +--------+ + 455 | ODXC | | ODXC +--------+ ODXC | | ODXC | 456 +-------+ +---------+Link #2 +---------+ +-------+ 457 Node A Node B Node C Node D 459 Figure 3 - RWA Hidden Topology for LO ODU connection management 461 Link #5 +---------+ Link #4 462 +------------------------| |-----------------------+ 463 | +----| ODXC |----+ | 464 | +-++ +---------+ ++-+ | 465 | Node f | | Node E | | Node g | 466 | +-++ ++-+ | 467 | | +--+ | | 468 +-+-----+ +----+----+--| |--+-----+---+ +-----+-+ 469 | |Link #1 | | +--+ | |Link #3 | | 470 | +--------+ | Node h | +--------+ | 471 | ODXC | | ODXC +--------+ ODXC | | ODXC | 472 +-------+ +---------+ Link #2+---------+ +-------+ 473 Node A Node B Node C Node D 475 Figure 4 - RWA Visible Topology for LO ODUj connection management 477 In Figure 4, the cloud of previous figure is substitute by the real 478 topology. The nodes f, g, h are nodes with OCH switching capability. 480 In the examples (i.e., Figure 3 and Figure 4), we have considered the 481 case in which LO-ODUj connections are supported by OCh connection, 482 and the case in which the supporting underlying connection can be 483 also made by a combination of HO-ODU/OCh connections. 485 In this case, the ODU routing/path selection process will request an 486 HO-ODU/OCh connection between node C and node E from the RWA domain. 487 The connection will appear at ODU level as a Forwarding Adjacency, 488 which will be used to create the ODU connection. 490 5. GMPLS/PCE Implications 492 The purpose of this section is to provide a set of requirements to be 493 evaluated for extensions of the current GMPLS protocol suite and the 494 PCE applications and protocols to encompass OTN enhancements and 495 connection management. 497 5.1. Implications for LSP Hierarchy with GMPLS TE 499 The path computation for ODU connection request is based on the 500 topology of ODU layer, including OCh layer visibility. 502 The OTN path computation can be divided into two layers. One layer is 503 OCh/OTUk, the other is ODUj. [RFC4206] and [RFC6107] define the 504 mechanisms to accomplish creating the hierarchy of LSPs. The LSP 505 management of multiple layers in OTN can follow the procedures 506 defined in [RFC4206], [RFC6107] and related MLN drafts. 508 As discussed in section 4, the route path computation for OCh is in 509 the scope of WSON [RFC6163]. Therefore, this document only considers 510 ODU layer for ODU connection request. 512 LSP hierarchy can also be applied within the ODU layers. One of the 513 typical scenarios for ODU layer hierarchy is to maintain 514 compatibility with introducing new [G709-V3] services (e.g., ODU0, 515 ODUflex) into a legacy network configuration (containing [G709-V1] or 516 [G709-V2] OTN equipment). In this scenario, it may be needed to 517 consider introducing hierarchical multiplexing capability in specific 518 network transition scenarios. One method for enabling multiplexing 519 hierarchy is by introducing dedicated boards in a few specific places 520 in the network and tunneling these new services through [G709-V1] or 521 [G709-V2] containers (ODU1, ODU2, ODU3), thus postponing the need to 522 upgrade every network element to [G709-V3] capabilities. 524 In such case, one ODUj connection can be nested into another ODUk 525 (j +----------+ 858 | TS1==|===========\--------+--TS1 | 859 | TS2==|=========\--\-------+--TS2 | 860 | TS3==|=======\--\--\------+--TS3 | 861 | TS4==|=====\--\--\--\-----+--TS4 | 862 | | \ \ \ \----+--TS5 | 863 | | \ \ \------+--TS6 | 864 | | \ \--------+--TS7 | 865 | | \----------+--TS8 | 866 +----------+ <------------ +----------+ 867 node A Resv node B 869 Figure 5 - Interworking between 1.25Gbps TS and 2.5Gbps TS 871 Take Figure 5 as an example. Assume that there is an ODU2 link 872 between node A and B, where node A only supports the 2.5Gbps TS while 873 node B supports the 1.25Gbps TS. In this case, the TS#i and TS#i+4 874 (where i<=4) of node B are combined together. When creating an ODU1 875 service in this ODU2 link, node B reserves the TS#i and TS#i+4 with 876 the granularity of 1.25Gbps. But in the label sent from B to A, it is 877 indicated that the TS#i with the granularity of 2.5Gbps is reserved. 879 In the contrary direction, when receiving a label from node A 880 indicating that the TS#i with the granularity of 2.5Gbps is reserved, 881 node B will reserved the TS#i and TS#i+4 with the granularity of 882 1.25Gbps in its data plane. 884 7. Security Considerations 886 The use of control plane protocols for signaling, routing, and path 887 computation opens an OTN to security threats through attacks on those 888 protocols. The data plane technology for an OTN does not introduce 889 any specific vulnerabilities, and so the control plane may be secured 890 using the mechanisms defined for the protocols discussed. 892 For further details of the specific security measures refer to the 893 documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], 895 [RFC4204], and [RFC5440]). [RFC5920] provides an overview of security 896 vulnerabilities and protection mechanisms for the GMPLS control plane. 898 8. IANA Considerations 900 This document makes not requests for IANA action. 902 9. Acknowledgments 904 We would like to thank Maarten Vissers and Lou Berger for their 905 review and useful comments. 907 10. References 909 10.1. Normative References 911 [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol 912 LabelSwitching (GMPLS) Signaling Extensions for G.709 913 Optical Transport Networks Control", RFC 4328, Jan 2006. 915 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 916 Switching (GMPLS) Signaling Functional Description", RFC 917 3471, January 2003. 919 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 920 Switching (GMPLS) Signaling Resource ReserVation 921 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 922 3473, January 2003. 924 [RFC4201] K. Kompella, Y. Rekhter, Ed., "Link Bundling in MPLS 925 Traffic Engineering (TE)", RFC 4201, October 2005. 927 [RFC4202] K. Kompella, Y. Rekhter, Ed., "Routing Extensions in 928 Support of Generalized Multi-Protocol Label Switching 929 (GMPLS)", RFC 4202, October 2005. 931 [RFC4203] K. Kompella, Y. Rekhter, Ed., "OSPF Extensions in Support 932 of Generalized Multi-Protocol Label Switching (GMPLS)", 933 RFC 4203, October 2005. 935 [RFC4205] K. Kompella, Y. Rekhter, Ed., "Intermediate System to 936 Intermediate System (IS-IS) Extensions in Support of 937 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 938 4205, October 2005. 940 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, 941 October 2005. 943 [RFC4206] K. Kompella, Y. Rekhter, Ed., " Label Switched Paths (LSP) 944 Hierarchy with Generalized Multi-Protocol Label Switching 945 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 947 [RFC6107] K. Shiomoto, A. Farrel, "Procedures for Dynamically 948 Signaled Hierarchical Label Switched Paths", RFC6107, 949 February 2011. 951 [RFC6001] Dimitri Papadimitriou et al, "Generalized Multi-Protocol 952 Label Switching (GMPLS) Protocol Extensions for Multi- 953 Layer and Multi-Region Networks (MLN/MRN)", RFC6001, 954 February 21, 2010. 956 [RFC5440] JP. Vasseur, JL. Le Roux, Ed.," Path Computation Element 957 (PCE) Communication Protocol (PCEP)", RFC 5440, March 958 2009. 960 [RFC6344] G. Bernstein et al, "Operating Virtual Concatenation 961 (VCAT) and the Link Capacity Adjustment Scheme (LCAS) 962 with Generalized Multi-Protocol Label Switching (GMPLS)", 963 RFC6344, August, 2011. 965 [G709-V3] ITU-T, "Interfaces for the Optical Transport Network 966 (OTN)", G.709 Recommendation and Amendment2, April 2011. 968 10.2. Informative References 970 [G709-V1] ITU-T, "Interface for the Optical Transport Network 971 (OTN)," G.709 Recommendation and Amendment1, November 972 2001. 974 [G709-V2] ITU-T, "Interface for the Optical Transport Network 975 (OTN)," G.709 Recommendation, March 2003. 977 [G7042] ITU-T, "Link capacity adjustment scheme (LCAS) for 978 virtual concatenated signals", G.7042/Y.1305, March 2006. 980 [G872-2001] ITU-T, "Architecture of optical transport networks", 981 G.872 Recommendation, November 2001. 983 [G872-Am2] ITU-T, "Architecture of optical transport networks", 984 G.872 Recommendation and Amendment 2, July 2010. 986 [G.7044] ITU-T, "Hitless adjustment of ODUflex", G.7044 (and 987 Amendment 1), February 2012. 989 [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing 990 and wavelength assignment approaches for wavelength- 991 routed optical WDM networks", Optical Networks Magazine, 992 January 2000. 994 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 995 and PCE Control of Wavelength Switched Optical Networks 996 (WSON)", RFC6163, April 2011. 998 [PCE-APS] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai 999 Zhang, "Requirements for GMPLS applications of PCE", 1000 draft-ietf-pce-gmpls-aps-req, Work in Progress. 1002 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1003 Networks", RFC5920, July 2010. 1005 11. Authors' Addresses 1007 Fatai Zhang (editor) 1008 Huawei Technologies 1009 F3-5-B R&D Center, Huawei Base 1010 Bantian, Longgang District 1011 Shenzhen 518129 P.R.China 1013 Phone: +86-755-28972912 1014 Email: zhangfatai@huawei.com 1016 Dan Li 1017 Huawei Technologies Co., Ltd. 1018 F3-5-B R&D Center, Huawei Base 1019 Bantian, Longgang District 1020 Shenzhen 518129 P.R.China 1022 Phone: +86-755-28973237 1023 Email: huawei.danli@huawei.com 1024 Han Li 1025 China Mobile Communications Corporation 1026 53 A Xibianmennei Ave. Xuanwu District 1027 Beijing 100053 P.R. China 1029 Phone: +86-10-66006688 1030 Email: lihan@chinamobile.com 1032 Sergio Belotti 1033 Alcatel-Lucent 1034 Optics CTO 1035 Via Trento 30 20059 Vimercate (Milano) Italy 1036 +39 039 6863033 1038 Email: sergio.belotti@alcatel-lucent.it 1040 Daniele Ceccarelli 1041 Ericsson 1042 Via A. Negrone 1/A 1043 Genova - Sestri Ponente 1044 Italy 1045 Email: daniele.ceccarelli@ericsson.com 1047 12. Contributors 1049 Jianrui Han 1050 Huawei Technologies Co., Ltd. 1051 F3-5-B R&D Center, Huawei Base 1052 Bantian, Longgang District 1053 Shenzhen 518129 P.R.China 1055 Phone: +86-755-28972913 1056 Email: hanjianrui@huawei.com 1058 Malcolm Betts 1059 Huawei Technologies Co., Ltd. 1061 Email: malcolm.betts@huawei.com 1062 Pietro Grandi 1063 Alcatel-Lucent 1064 Optics CTO 1065 Via Trento 30 20059 Vimercate (Milano) Italy 1066 +39 039 6864930 1068 Email: pietro_vittorio.grandi@alcatel-lucent.it 1070 Eve Varma 1071 Alcatel-Lucent 1072 1A-261, 600-700 Mountain Av 1073 PO Box 636 1074 Murray Hill, NJ 07974-0636 1075 USA 1076 Email: eve.varma@alcatel-lucent.com 1078 APPENDIX A: ODU connection examples 1080 This appendix provides a description of ODU terminology and 1081 connection examples. This section is not normative, and is just 1082 intended to facilitate understanding. 1084 In order to transmit a client signal, an ODU connection needs to be 1085 created first. From the perspective of [G709-V3] and [G872-Am2], some 1086 types of ODUs (i.e., ODU1, ODU2, ODU3, ODU4) may assume either a 1087 client or server role within the context of a particular networking 1088 domain: 1090 (1) An ODUj client that is mapped into an OTUk server. For example, 1091 if a STM-16 signal is encapsulated into ODU1, and then the ODU1 is 1092 mapped into OTU1, the ODU1 is a LO ODU (from a multiplexing 1093 perspective). 1095 (2) An ODUj client that is mapped into an ODUk (j < k) server 1096 occupying several TSs. For example, if ODU1 is multiplexed into ODU2, 1097 and ODU2 is mapped into OTU2, the ODU1 is a LO ODU and the ODU2 is a 1098 HO ODU (from a multiplexing perspective). 1100 Thus, a LO ODUj represents the container transporting a client of the 1101 OTN that is either directly mapped into an OTUk (k = j) or 1102 multiplexed into a server HO ODUk (k > j) container. Consequently, 1103 the HO ODUk represents the entity transporting a multiplex of LO ODUj 1104 tributary signals in its OPUk area. 1106 In the case of LO ODUj mapped into an OTUk (k = j) directly, Figure 6 1107 give an example of this kind of LO ODU connection. 1109 In Figure 6, The LO ODUj is switched at the intermediate ODXC node. 1110 OCh and OTUk are associated with each other. From the viewpoint of 1111 connection management, the management of OTUk is similar with OCh. LO 1112 ODUj and OCh/OTUk have client/server relationships. 1114 For example, one LO ODU1 connection can be setup between Node A and 1115 Node C. This LO ODU1 connection is to be supported by OCh/OTU1 1116 connections, which are to be set up between Node A and Node B and 1117 between Node B and Node C. LO ODU1 can be mapped into OTU1 at Node A, 1118 demapped from it in Node B, switched at Node B, and then mapped into 1119 the next OTU1 and demapped from this OTU1 at Node C. 1121 | LO ODUj | 1122 +------------------------------(b)---------------------------+ 1123 | | OCh/OTUk | | OCh/OTUk | | 1124 | +--------(a)---------+ +--------(a)---------+ | 1125 | | | | | | 1126 +------++-+ +--+---+--+ +-++------+ 1127 | |EO| |OE| |EO| |OE| | 1128 | +--+----------------+--+ +--+----------------+--+ | 1129 | ODXC | | ODXC | | ODXC | 1130 +---------+ +---------+ +---------+ 1131 Node A Node B Node C 1133 Figure 6 - Connection of LO ODUj (1) 1135 In the case of LO ODUj multiplexing into HO ODUk, Figure 7 gives an 1136 example of this kind of LO ODU connection. 1138 In Figure 7, OCh, OTUk, HO ODUk are associated with each other. The 1139 LO ODUj is multiplexed/de-multiplexed into/from the HO ODU at each 1140 ODXC node and switched at each ODXC node (i.e. trib port to line port, 1141 line card to line port, line port to trib port). From the viewpoint 1142 of connection management, the management of these HO ODUk and OTUk 1143 are similar to OCh. LO ODUj and OCh/OTUk/HO ODUk have client/server 1144 relationships. When a LO ODU connection is setup, it will be using 1145 the existing HO ODUk (/OTUk/OCh) connections which have been set up. 1146 Those HO ODUk connections provide LO ODU links, of which the LO ODU 1147 connection manager requests a link connection to support the LO ODU 1148 connection. 1150 For example, one HO ODU2 (/OTU2/OCh) connection can be setup between 1151 Node A and Node B, another HO ODU3 (/OTU3/OCh) connection can be 1152 setup between Node B and Node C. LO ODU1 can be generated at Node A, 1153 switched to one of the 10G line ports and multiplexed into a HO ODU2 1154 at Node A, demultiplexed from the HO ODU2 at Node B, switched at Node 1155 B to one of the 40G line ports and multiplexed into HO ODU3 at Node B, 1156 demultiplexed from HO ODU3 at Node C and switched to its LO ODU1 1157 terminating port at Node C. 1159 | LO ODUj | 1160 +----------------------------(b)-----------------------------+ 1161 | | OCh/OTUk/HO ODUk | | OCh/OTUk/HO ODUk | | 1162 | +--------(c)---------+ +---------(c)--------+ | 1163 | | | | | | 1164 +------++-+ +--+---+--+ +-++------+ 1165 | |EO| |OE| |EO| |OE| | 1166 | +--+----------------+--+ +--+----------------+--+ | 1167 | ODXC | | ODXC | | ODXC | 1168 +---------+ +---------+ +---------+ 1169 Node A Node B Node C 1171 Figure 7 - Connection of LO ODUj (2) 1173 Intellectual Property 1175 The IETF Trust takes no position regarding the validity or scope of 1176 any Intellectual Property Rights or other rights that might be 1177 claimed to pertain to the implementation or use of the technology 1178 described in any IETF Document or the extent to which any license 1179 under such rights might or might not be available; nor does it 1180 represent that it has made any independent effort to identify any 1181 such rights. 1183 Copies of Intellectual Property disclosures made to the IETF 1184 Secretariat and any assurances of licenses to be made available, or 1185 the result of an attempt made to obtain a general license or 1186 permission for the use of such proprietary rights by implementers or 1187 users of this specification can be obtained from the IETF on-line IPR 1188 repository at http://www.ietf.org/ipr 1190 The IETF invites any interested party to bring to its attention any 1191 copyrights, patents or patent applications, or other proprietary 1192 rights that may cover technology that may be required to implement 1193 any standard or specification contained in an IETF Document. Please 1194 address the information to the IETF at ietf-ipr@ietf.org. 1196 The definitive version of an IETF Document is that published by, or 1197 under the auspices of, the IETF. Versions of IETF Documents that are 1198 published by third parties, including those that are translated into 1199 other languages, should not be considered to be definitive versions 1200 of IETF Documents. The definitive version of these Legal Provisions 1201 is that published by, or under the auspices of, the IETF. Versions of 1202 these Legal Provisions that are published by third parties, including 1203 those that are translated into other languages, should not be 1204 considered to be definitive versions of these Legal Provisions. 1206 For the avoidance of doubt, each Contributor to the IETF Standards 1207 Process licenses each Contribution that he or she makes as part of 1208 the IETF Standards Process to the IETF Trust pursuant to the 1209 provisions of RFC 5378. No language to the contrary, or terms, 1210 conditions or rights that differ from or are inconsistent with the 1211 rights and licenses granted under RFC 5378, shall have any effect and 1212 shall be null and void, whether published or posted by such 1213 Contributor, or included with or in such Contribution. 1215 Disclaimer of Validity 1217 All IETF Documents and the information contained therein are provided 1218 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1219 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1220 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1221 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1222 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1223 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1224 FOR A PARTICULAR PURPOSE. 1226 Copyright Notice 1228 Copyright (c) 2010 IETF Trust and the persons identified as the 1229 document authors. All rights reserved. 1231 This document is subject to BCP 78 and the IETF Trust's Legal 1232 Provisions Relating to IETF Documents 1233 (http://trustee.ietf.org/license-info) in effect on the date of 1234 publication of this document. Please review these documents 1235 carefully, as they describe your rights and restrictions with respect 1236 to this document. Code Components extracted from this document must 1237 include Simplified BSD License text as described in Section 4.e of 1238 the Trust Legal Provisions and are provided without warranty as 1239 described in the Simplified BSD License.