idnits 2.17.1 draft-ietf-ccamp-gmpls-g709-framework-15.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 22, 2013) is 3831 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: March 22, 2014 September 22, 2013 12 Framework for GMPLS and PCE Control of 13 G.709 Optical Transport Networks 15 draft-ietf-ccamp-gmpls-g709-framework-15.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 March 22, 2014. 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 published in 2012. 48 Table of Contents 50 1. Introduction ................................................. 2 51 2. Terminology .................................................. 3 52 3. G.709 Optical Transport Network .............................. 4 53 3.1. OTN Layer Network ....................................... 4 54 3.1.1. Client signal mapping .............................. 5 55 3.1.2. Multiplexing ODUj onto Links ....................... 7 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 Label Switch Path (LSP) Hierarchy ...... 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 ............... 17 64 5.5. Implications for Control Plane Backward Compatibility ... 18 65 5.6. Implications for Path Computation Elements .............. 19 66 5.7. Implications for Management of GMPLS Networks ........... 20 67 6. Data Plane Backward Compatibility Considerations ............. 20 68 7. Security Considerations ..................................... 21 69 8. IANA Considerations .......................................... 21 70 9. Acknowledgments .............................................. 21 71 10. References .................................................. 21 72 10.1. Normative References ................................... 21 73 10.2. Informative References ................................ 23 74 11. Authors' Addresses .......................................... 24 75 12. Contributors ................................................ 25 77 1. Introduction 79 Optical Transport Networks (OTN) has become a mainstream layer 1 80 technology for the transport network. Operators want to introduce 81 control plane capabilities based on GMPLS to OTN, to realize the 82 benefits associated with a high-function control plane (e.g., 83 improved network resiliency, resource usage efficiency, etc.). 85 GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass time 86 division multiplexing (TDM) networks (e.g., Synchronous Optical 87 NETwork (SONET)/ Synchronous Digital Hierarchy (SDH), Plesiochronous 88 Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching 89 optical networks, and spatial switching (e.g., incoming port or fiber 90 to outgoing port or fiber). The GMPLS architecture is provided in 91 [RFC3945], signaling function and Resource ReserVation Protocol- 92 Traffic Engineering (RSVP-TE) extensions are described in [RFC3471] 93 and [RFC3473], routing and Open Shortest Path First (OSPF) extensions 94 are described in [RFC4202] and [RFC4203], and the Link Management 95 Protocol (LMP) is described in [RFC4204]. 97 The GMPLS signaling extensions defined in [RFC4328] provide the 98 mechanisms for basic GMPLS control of OTN based on the 2001 revision 99 of the G.709 specification. The 2012 revision of the G.709 100 specification, [G709-2012], includes new features, for example, 101 various multiplexing structures, two types of Tributary Slots (TSs) 102 (i.e., 1.25Gbps and 2.5Gbps), and extension of the Optical channel 103 Data Unit-j (ODUj) definition to include the ODUflex function. 105 This document reviews relevant aspects of OTN technology evolution 106 that affect the GMPLS control plane protocols and examines why and 107 how to update the mechanisms described in [RFC4328]. This document 108 additionally provides a framework for the GMPLS control of OTN and 109 includes a discussion of the implication for the use of the PCE 110 [RFC4655]. 112 For the purposes of the control plane the OTN can be considered as 113 being comprised of ODU and wavelength (Optical Channel (OCh)) layers. 114 This document focuses on the control of the ODU layer, with control 115 of the wavelength layer considered out of the scope. Please refer to 116 [RFC6163] for further information about the wavelength layer. 118 2. Terminology 120 OTN: Optical Transport Network 122 OPU: Optical channel Payload Unit 124 ODU: Optical channel Data Unit 126 OTU: Optical channel Transport Unit 128 OMS: Optical multiplex section 130 MSI: Multiplex Structure Identifier 132 TPN: Tributary Port Number 133 LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4, 134 flex.) represents the container transporting a client of the OTN that 135 is either directly mapped into an OTUk (k = j) or multiplexed into a 136 server HO ODUk (k > j) container. 138 HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, 4.) 139 represents the entity transporting a multiplex of LO ODUj tributary 140 signals in its OPUk area. 142 ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a 143 bit rate tolerance of +/-100 ppm (parts per million). 145 In general, throughout this document, 'ODUj' is used to refer to ODU 146 entities acting as LO ODU, and 'ODUk' is used to refer to ODU 147 entities being used as HO ODU. 149 3. G.709 Optical Transport Network 151 This section provides an informative overview of those aspects of the 152 OTN impacting control plane protocols. This overview is based on the 153 ITU-T Recommendations that contain the normative definition of the 154 OTN. Technical details regarding OTN architecture and interfaces are 155 provided in the relevant ITU-T Recommendations. 157 Specifically, [G872-2012] describes the functional architecture of 158 optical transport networks providing optical signal transmission, 159 multiplexing, routing, supervision, performance assessment, and 160 network survivability. The legacy OTN referenced by [RFC4328] defines 161 the interfaces of the optical transport network to be used within and 162 between subnetworks of the optical network. With the evolution and 163 deployment of OTN technology many new features have been specified in 164 ITU-T recommendations, including for example, new ODU0, ODU2e, ODU4 165 and ODUflex containers as described in [G709-2012]. 167 3.1. OTN Layer Network 169 The simplified signal hierarchy of OTN is shown in Figure 1, which 170 illustrates the layers that are of interest to the control plane. 171 Other layers below OCh (e.g. Optical Transmission Section (OTS)) are 172 not included in this Figure. The full signal hierarchy is provided in 173 [G709-2012]. 175 Client signal 176 | 177 ODUj 178 | 179 OTU/OCh 180 OMS 182 Figure 1 - Basic OTN signal hierarchy 184 Client signals are mapped into ODUj containers. These ODUj containers 185 are multiplexed onto the OTU/OCh. The individual OTU/OCh signals are 186 combined in the OMS using Wavelength Division Multiplexing (WDM), and 187 this aggregated signal provides the link between the nodes. 189 3.1.1. Client signal mapping 191 The client signals are mapped into a LO ODUj. The current values of j 192 defined in [G709-2012] are: 0, 1, 2, 2e, 3, 4, Flex. The approximate 193 bit rates of these signals are defined in [G709-2012] and are 194 reproduced in Tables 1 and 2. 196 Table 1 - ODU types and bit rates 197 +-----------------------+-----------------------------------+ 198 | ODU Type | ODU nominal bit rate | 199 +-----------------------+-----------------------------------+ 200 | ODU0 | 1,244,160 Kbps | 201 | ODU1 | 239/238 x 2,488,320 Kbps | 202 | ODU2 | 239/237 x 9,953,280 Kbps | 203 | ODU3 | 239/236 x 39,813,120 Kbps | 204 | ODU4 | 239/227 x 99,532,800 Kbps | 205 | ODU2e | 239/237 x 10,312,500 Kbps | 206 | | | 207 | ODUflex for | | 208 |Constant Bit Rate (CBR)| 239/238 x client signal bit rate | 209 | Client signals | | 210 | | | 211 | ODUflex for Generic | | 212 | Framing Procedure | Configured bit rate | 213 | - Framed (GFP-F) | | 214 | Mapped client signal | | 215 +-----------------------+-----------------------------------+ 216 NOTE - The nominal ODUk rates are approximately: 2,498,775.126 Kbps 217 (ODU1), 10,037,273.924 Kbps (ODU2), 40,319,218.983 Kbps (ODU3), 218 104,794,445.815 Kbps (ODU4) and 10,399,525.316 Kbps (ODU2e). 220 Table 2 - ODU types and tolerance 221 +-----------------------+-----------------------------------+ 222 | ODU Type | ODU bit-rate tolerance | 223 +-----------------------+-----------------------------------+ 224 | ODU0 | +/-20 ppm | 225 | ODU1 | +/-20 ppm | 226 | ODU2 | +/-20 ppm | 227 | ODU3 | +/-20 ppm | 228 | ODU4 | +/-20 ppm | 229 | ODU2e | +/-100 ppm | 230 | | | 231 | ODUflex for CBR | | 232 | Client signals | +/-100 ppm | 233 | | | 234 | ODUflex for GFP-F | | 235 | Mapped client signal | +/-100 ppm | 236 +-----------------------+-----------------------------------+ 238 One of two options is for mapping client signals into ODUflex 239 depending on the client signal type: 241 - Circuit clients are proportionally wrapped. Thus the bit rate is 242 defined by the client signal and the tolerance is fixed to +/-100 243 ppm. 245 - Packet clients are mapped using the Generic Framing Procedure 246 (GFP). [G709-2012] recommends that the ODUflex(GFP) will fill an 247 integral number of tributary slots of the smallest HO ODUk path 248 over which the ODUflex(GFP) may be carried, and the tolerance 249 should be +/-100 ppm. 251 Note that additional information on G.709 client mapping can be found 252 in [G7041]. 254 3.1.2. Multiplexing ODUj onto Links 256 The links between the switching nodes are provided by one or more 257 wavelengths. Each wavelength carries one OCh, which carries one OTU, 258 which carries one ODU. Since all of these signals have a 1:1:1 259 relationship, we only refer to the OTU for clarity. The ODUjs are 260 mapped into the TSs (Tributary Slots) of the OPUk. Note that in the 261 case where j=k the ODUj is mapped into the OTU/OCh without 262 multiplexing. 264 The initial versions of G.709 referenced by [RFC4328] only provided a 265 single TS granularity, nominally 2.5Gbps. [G709-2012] added an 266 additional TS granularity, nominally 1.25Gbps. The number and type of 267 TSs provided by each of the currently identified OTUk is provided 268 below: 270 Tributary Slot Granularity 271 2.5Gbps 1.25Gbps Nominal Bit rate 272 OTU1 1 2 2.5Gbps 273 OTU2 4 8 10Gbps 274 OTU3 16 32 40Gbps 275 OTU4 -- 80 100Gbps 277 To maintain backwards compatibility while providing the ability to 278 interconnect nodes that support 1.25Gbps TS at one end of a link and 279 2.5Gbps TS at the other, [G709-2012] requires 'new' equipment fall 280 back to the use of a 2.5Gbps TS when connected to legacy equipment. 281 This information is carried in band by the payload type. 283 The actual bit rate of the TS in an OTUk depends on the value of k. 284 Thus the number of TSs occupied by an ODUj may vary depending on the 285 values of j and k. For example an ODU2e uses 9 TSs in an OTU3 but 286 only 8 in an OTU4. Examples of the number of TSs used for various 287 cases are provided below (Referring to Table 7-9 of [G709-2012]): 289 - ODU0 into ODU1, ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS 290 granularity 291 o ODU0 occupies 1 of the 2, 8, 32 or 80 TSs for ODU1, ODU2, ODU3 292 or ODU4 294 - ODU1 into ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS 295 granularity 296 o ODU1 occupies 2 of the 8, 32 or 80 TSs for ODU2, ODU3 or ODU4 298 - ODU1 into ODU2, ODU3 multiplexing with 2.5Gbps TS granularity 299 o ODU1 occupies 1 of the 4 or 16 TSs for ODU2 or ODU3 301 - ODU2 into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity 302 o ODU2 occupies 8 of the 32 or 80 TSs for ODU3 or ODU4 304 - ODU2 into ODU3 multiplexing with 2.5Gbps TS granularity 305 o ODU2 occupies 4 of the 16 TSs for ODU3 307 - ODU3 into ODU4 multiplexing with 1.25Gbps TS granularity 308 o ODU3 occupies 31 of the 80 TSs for ODU4 310 - ODUflex into ODU2, ODU3 or ODU4 multiplexing with 1.25Gbps TS 311 granularity 312 o ODUflex occupies n of the 8, 32 or 80 TSs for ODU2, ODU3 or 313 ODU4 (n <= Total TS number of ODUk) 315 - ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity 316 o ODU2e occupies 9 of the 32 TSs for ODU3 or 8 of the 80 TSs for 317 ODU4 319 In general the mapping of an ODUj (including ODUflex) into a specific 320 OTUk TS is determined locally, and it can also be explicitly 321 controlled by a specific entity (e.g., head end, Network Management 322 System (NMS)) through Explicit Label Control [RFC3473]. 324 3.1.2.1. Structure of MSI information 326 When multiplexing an ODUj into a HO ODUk (k>j), G.709 specifies the 327 information that has to be transported in-band in order to allow for 328 correct demultiplexing. This information, known as MSI, is 329 transported in the OPUk overhead and is local to each link. In case 330 of bidirectional paths the association between TPN and TS must be the 331 same in both directions. 333 The MSI information is organized as a set of entries, with one entry 334 for each HO ODUj TS. The information carried by each entry is: 336 - Payload Type: the type of the transported payload. 338 - TPN: the port number of the ODUj transported by the HO ODUk. The 339 TPN is the same for all the TSs assigned to the transport of the 340 same ODUj instance. 342 For example, an ODU2 carried by a HO ODU3 is described by 4 entries 343 in the OPU3 overhead when the TS granularity is 2.5Gbps, and by 8 344 entries when the TS granularity is 1.25Gbps. 346 On each node and on every link, two MSI values have to be provisioned 347 (Referring to [G798-V4]): 349 - The Transmitted MSI (TxMSI) information inserted in OPU (e.g., 350 OPU3) overhead by the source of the HO ODUk trail. 352 - The expected MSI (ExMSI) information that is used to check the 353 accepted MSI (AcMSI) information. The AcMSI information is the MSI 354 valued received in-band, after a three-frame integration. 356 As described in [G798-V4], the sink of the HO ODU trail checks the 357 complete content of the AcMSI information against the ExMSI. If the 358 AcMSI is different from the ExMSI, then the traffic is dropped and a 359 payload mismatch alarm is generated. 361 Provisioning of TPN can be performed either by network management 362 system or control plane. In the last case, control plane is also 363 responsible for negotiating the provisioned values on a link by link 364 base. 366 4. Connection management in OTN 368 OTN-based connection management is concerned with controlling the 369 connectivity of ODU paths and OCh. This document focuses on the 370 connection management of ODU paths. The management of OCh paths is 371 described in [RFC6163]. 373 While [G872-2001] considered the ODU as a set of layers in the same 374 way as SDH has been modeled, recent ITU-T OTN architecture progress 375 [G872-2012] includes an agreement to model the ODU as a single layer 376 network with the bit rate as a parameter of links and connections. 377 This allows the links and nodes to be viewed in a single topology as 378 a common set of resources that are available to provide ODUj 379 connections independent of the value of j. Note that when the bit 380 rate of ODUj is less than the server bit rate, ODUj connections are 381 supported by HO ODU (which has a one-to-one relationship with the 382 OTU). 384 From an ITU-T perspective, the ODU connection topology is represented 385 by that of the OTU link layer, which has the same topology as that of 386 the OCh layer (independent of whether the OTU supports HO ODU, where 387 multiplexing is utilized, or LO ODU in the case of direct mapping). 389 Thus, the OTU and OCh layers should be visible in a single 390 topological representation of the network, and from a logical 391 perspective, the OTU and OCh may be considered as the same logical, 392 switchable entity. 394 Note that the OTU link layer topology may be provided via various 395 infrastructure alternatives, including point-to-point optical 396 connections, optical connections fully in the optical domain and 397 optical connections involving hybrid sub-lambda/lambda nodes 398 involving 3R, etc, see [RFC6163] for additional information. 400 4.1. Connection management of the ODU 402 LO ODUj can be either mapped into the OTUk signal (j = k), or 403 multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is 404 mapped into an OCh. 406 From the perspective of control plane, there are two kinds of network 407 topology to be considered. 409 (1) ODU layer 411 In this case, the ODU links are presented between adjacent OTN nodes, 412 as illustrated in Figure 2. In this layer there are ODU links with a 413 variety of TSs available, and nodes that are Optical Digital Cross 414 Connects (ODXCs). LO ODU connections can be setup based on the 415 network topology. 417 Link #5 +--+---+--+ Link #4 418 +--------------------------| |--------------------------+ 419 | | ODXC | | 420 | +---------+ | 421 | Node E | 422 | | 423 +-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++ 424 | |Link #1 | |Link #2 | |Link #3 | | 425 | |--------| |--------| |--------| | 426 | ODXC | | ODXC | | ODXC | | ODXC | 427 +---------+ +---------+ +---------+ +---------+ 428 Node A Node B Node C Node D 430 Figure 2 - Example Topology for LO ODU connection management 432 If an ODUj connection is requested between Node C and Node E 433 routing/path computation must select a path that has the required 434 number of TS available and that offers the lowest cost. Signaling is 435 then invoked to set up the path and to provide the information (e.g., 436 selected TSs) required by each transit node to allow the 437 configuration of the ODUj to OTUk mapping (j = k) or multiplexing (j 438 < k), and demapping (j = k) or demultiplexing (j < k). 440 (2) ODU layer with OCh switching capability 442 In this case, the OTN nodes interconnect with wavelength switched 443 node (e.g., Reconfiguration Optical Add/Drop Multiplexer (ROADM), 444 Optical Cross-Connect (OXC)) that are capable of OCh switching, which 445 is illustrated in Figure 3 and Figure 4. There are ODU layer and OCh 446 layer, so it is simply a Multi-Layer Networks (MLN) (see [RFC6001]). 447 OCh connections may be created on demand, which is described in 448 section 5.1. 450 In this case, an operator may choose to allow the underlying OCh 451 layer to be visible to the ODU routing/path computation process in 452 which case the topology would be as shown in Figure 4. In Figure 3 453 below, instead, a cloud representing OCh capable switching nodes is 454 represented. In Figure 3, the operator choice is to hide the real OCh 455 layer network topology. 457 Node E 458 Link #5 +--------+ Link #4 459 +------------------------| |------------------------+ 460 | ------ | 461 | // \\ | 462 | || || | 463 | | OCh domain | | 464 +-+-----+ +------ || || ------+ +-----+-+ 465 | | | \\ // | | | 466 | |Link #1 | -------- |Link #3 | | 467 | +--------+ | | +--------+ + 468 | ODXC | | ODXC +--------+ ODXC | | ODXC | 469 +-------+ +---------+Link #2 +---------+ +-------+ 470 Node A Node B Node C Node D 472 Figure 3 - OCh Hidden Topology for LO ODU connection management 473 Link #5 +---------+ Link #4 474 +------------------------| |-----------------------+ 475 | +----| ODXC |----+ | 476 | +-++ +---------+ ++-+ | 477 | Node f | | Node E | | Node g | 478 | +-++ ++-+ | 479 | | +--+ | | 480 +-+-----+ +----+----+--| |--+-----+---+ +-----+-+ 481 | |Link #1 | | +--+ | |Link #3 | | 482 | +--------+ | Node h | +--------+ | 483 | ODXC | | ODXC +--------+ ODXC | | ODXC | 484 +-------+ +---------+ Link #2+---------+ +-------+ 485 Node A Node B Node C Node D 487 Figure 4 - OCh Visible Topology for LO ODUj connection management 489 In Figure 4, the cloud of previous figure is substituted by the real 490 topology. The nodes f, g, h are nodes with OCh switching capability. 492 In the examples (i.e., Figure 3 and Figure 4), we have considered the 493 case in which LO ODUj connections are supported by OCh connection, 494 and the case in which the supporting underlying connection can be 495 also made by a combination of HO ODU/OCh connections. 497 In this case, the ODU routing/path selection process will request an 498 HO ODU/OCh connection between node C and node E from the OCh domain. 499 The connection will appear at ODU level as a Forwarding Adjacency, 500 which will be used to create the ODU connection. 502 5. GMPLS/PCE Implications 504 The purpose of this section is to provide a set of requirements to be 505 evaluated for extensions of the current GMPLS protocol suite and the 506 PCE applications and protocols to encompass OTN enhancements and 507 connection management. 509 5.1. Implications for Label Switch Path (LSP) Hierarchy 511 The path computation for ODU connection request is based on the 512 topology of ODU layer. 514 The OTN path computation can be divided into two layers. One layer is 515 OCh/OTUk, the other is ODUj. [RFC4206] and [RFC6107] define the 516 mechanisms to accomplish creating the hierarchy of LSPs. The LSP 517 management of multiple layers in OTN can follow the procedures 518 defined in [RFC4206], [RFC6001] and [RFC6107], etc. 520 As discussed in section 4, the route path computation for OCh is in 521 the scope of Wavelength Switched Optical Network (WSON) [RFC6163]. 522 Therefore, this document only considers ODU layer for ODU connection 523 request. 525 LSP hierarchy can also be applied within the ODU layers. One of the 526 typical scenarios for ODU layer hierarchy is to maintain 527 compatibility with introducing new [G709-2012] services (e.g., ODU0, 528 ODUflex) into a legacy network configuration (i.e., the legacy OTN 529 referenced by [RFC4328]). In this scenario, it may be needed to 530 consider introducing hierarchical multiplexing capability in specific 531 network transition scenarios. One method for enabling multiplexing 532 hierarchy is by introducing dedicated boards in a few specific places 533 in the network and tunneling these new services through the legacy 534 containers (ODU1, ODU2, ODU3), thus postponing the need to upgrade 535 every network element to [G709-2012] capabilities. 537 In such case, one ODUj connection can be nested into another ODUk 538 (j +----------+ 869 | TS1==|===========\--------+--TS1 | 870 | TS2==|=========\--\-------+--TS2 | 871 | TS3==|=======\--\--\------+--TS3 | 872 | TS4==|=====\--\--\--\-----+--TS4 | 873 | | \ \ \ \----+--TS5 | 874 | | \ \ \------+--TS6 | 875 | | \ \--------+--TS7 | 876 | | \----------+--TS8 | 877 +----------+ <------------ +----------+ 878 node A Resv node B 880 Figure 5 - Interworking between 1.25Gbps TS and 2.5Gbps TS 882 Take Figure 5 as an example. Assume that there is an ODU2 link 883 between node A and B, where node A only supports the 2.5Gbps TS while 884 node B supports the 1.25Gbps TS. In this case, the TS#i and TS#i+4 885 (where i<=4) of node B are combined together. When creating an ODU1 886 service in this ODU2 link, node B reserves the TS#i and TS#i+4 with 887 the granularity of 1.25Gbps. But in the label sent from B to A, it is 888 indicated that the TS#i with the granularity of 2.5Gbps is reserved. 890 In the opposite direction, when receiving a label from node A 891 indicating that the TS#i with the granularity of 2.5Gbps is reserved, 892 node B will reserved the TS#i and TS#i+4 with the granularity of 893 1.25Gbps in its data plane. 895 7. Security Considerations 897 The use of control plane protocols for signaling, routing and path 898 computation opens an OTN to security threats through attacks on those 899 protocols. Although, this is not greater than the risks presented by 900 the existing OTN control plane as defined by [RFC4203] and [RFC4328]. 901 Meanwhile, the Data Communication Network (DCN) for OTN GMPLS control 902 plane protocols is likely to be in the in-fiber overhead, which 903 together with access lists at the network edges, provides a 904 significant security feature. For further details of the specific 905 security measures refer to the documents that define the protocols 906 ([RFC3473], [RFC4203], [RFC5307], [RFC4204] and [RFC5440]). [RFC5920] 907 provides an overview of security vulnerabilities and protection 908 mechanisms for the GMPLS control plane. 910 8. IANA Considerations 912 This document makes not requests for IANA action. 914 9. Acknowledgments 916 We would like to thank Maarten Vissers and Lou Berger for their 917 review and useful comments. 919 10. References 921 10.1. Normative References 923 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 924 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 925 Tunnels", RFC 3209, December 2001. 927 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 928 Switching (GMPLS) Signaling Functional Description", RFC 929 3471, January 2003. 931 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 932 Switching (GMPLS) Signaling Resource ReserVation 933 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 934 3473, January 2003. 936 [RFC4201] K. Kompella, Y. Rekhter, Ed., "Link Bundling in MPLS 937 Traffic Engineering (TE)", RFC 4201, October 2005. 939 [RFC4202] K. Kompella, Y. Rekhter, Ed., "Routing Extensions in 940 Support of Generalized Multi-Protocol Label Switching 941 (GMPLS)", RFC 4202, October 2005. 943 [RFC4203] K. Kompella, Y. Rekhter, Ed., "OSPF Extensions in Support 944 of Generalized Multi-Protocol Label Switching (GMPLS)", 945 RFC 4203, October 2005. 947 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 948 4204, October 2005. 950 [RFC4206] K. Kompella, Y. Rekhter, Ed., "Label Switched Paths (LSP) 951 Hierarchy with Generalized Multi-Protocol Label Switching 952 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 953 2005. 955 [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol 956 LabelSwitching (GMPLS) Signaling Extensions for G.709 957 Optical Transport Networks Control", RFC 4328, Jan 2006. 959 [RFC5307] K. Kompella, Y. Rekhter, Ed., "IS-IS Extensions in 960 Support of Generalized Multi-Protocol Label Switching 961 (GMPLS)", RFC 5307, October 2008. 963 [RFC5440] JP. Vasseur, JL. Le Roux, Ed.," Path Computation Element 964 (PCE) Communication Protocol (PCEP)", RFC 5440, March 965 2009. 967 [RFC6001] Dimitri Papadimitriou et al, "Generalized Multi-Protocol 968 Label Switching (GMPLS) Protocol Extensions for Multi- 969 Layer and Multi-Region Networks (MLN/MRN)", RFC6001, 970 February 21, 2010. 972 [RFC6107] K. Shiomoto, A. Farrel, "Procedures for Dynamically 973 Signaled Hierarchical Label Switched Paths", RFC6107, 974 February 2011. 976 [RFC6344] G. Bernstein et al, "Operating Virtual Concatenation 977 (VCAT) and the Link Capacity Adjustment Scheme (LCAS) 978 with Generalized Multi-Protocol Label Switching (GMPLS)", 979 RFC6344, August, 2011. 981 [G709-2012] ITU-T, "Interface for the Optical Transport Network 982 (OTN)", G.709/Y.1331 Recommendation, February 2012. 984 10.2. Informative References 986 [G798-V4] ITU-T, "Characteristics of optical transport network 987 hierarchy equipment functional blocks", G.798 988 Recommendation, October 2010. 990 [G7042] ITU-T, "Link capacity adjustment scheme (LCAS) for 991 virtual concatenated signals", G.7042/Y.1305, March 2006. 993 [G872-2001] ITU-T, "Architecture of optical transport networks", 994 G.872 Recommendation, November 2001. 996 [G872-2012] ITU-T, "Architecture of optical transport networks", 997 G.872 Recommendation, October 2012. 999 [G7044] ITU-T, "Hitless adjustment of ODUflex", G.7044/Y.1347, 1000 October 2011. 1002 [G7041] ITU-T, "Generic framing procedure", G.7041/Y.1303, April 1003 2011. 1005 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 1006 (GMPLS) Architecture", RFC 3945, October 2004. 1008 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path 1009 Computation Element (PCE)-Based Architecture", 1010 RFC 4655, August 2006. 1012 [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 1013 and PCE Control of Wavelength Switched Optical Networks 1014 (WSON)", RFC6163, April 2011. 1016 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1017 Networks", RFC5920, July 2010. 1019 [RFC7025] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai 1020 Zhang, "Requirements for GMPLS applications of PCE", 1021 RFC7025, September 2013. 1023 [TDM-OAM] A. Kern, A. Takacs, "GMPLS RSVP-TE Extensions for 1024 SONET/SDH and OTN OAM Configuration", draft-ietf-ccamp- 1025 rsvp-te-sdh-otn-oam-ext, Work in Progress. 1027 11. Authors' Addresses 1029 Fatai Zhang (editor) 1030 Huawei Technologies 1031 F3-5-B R&D Center, Huawei Base 1032 Bantian, Longgang District 1033 Shenzhen 518129 P.R.China 1035 Phone: +86-755-28972912 1036 Email: zhangfatai@huawei.com 1038 Dan Li 1039 Huawei Technologies Co., Ltd. 1040 F3-5-B R&D Center, Huawei Base 1041 Bantian, Longgang District 1042 Shenzhen 518129 P.R.China 1044 Phone: +86-755-28973237 1045 Email: huawei.danli@huawei.com 1047 Han Li 1048 China Mobile Communications Corporation 1049 53 A Xibianmennei Ave. Xuanwu District 1050 Beijing 100053 P.R. China 1052 Phone: +86-10-66006688 1053 Email: lihan@chinamobile.com 1055 Sergio Belotti 1056 Alcatel-Lucent 1057 Optics CTO 1058 Via Trento 30 20059 Vimercate (Milano) Italy 1059 +39 039 6863033 1061 Email: sergio.belotti@alcatel-lucent.it 1063 Daniele Ceccarelli 1064 Ericsson 1065 Via A. Negrone 1/A 1066 Genova - Sestri Ponente 1067 Italy 1069 Email: daniele.ceccarelli@ericsson.com 1071 12. Contributors 1073 Jianrui Han 1074 Huawei Technologies Co., Ltd. 1075 F3-5-B R&D Center, Huawei Base 1076 Bantian, Longgang District 1077 Shenzhen 518129 P.R.China 1079 Phone: +86-755-28972913 1080 Email: hanjianrui@huawei.com 1082 Malcolm Betts 1084 Email: malcolm.betts@rogers.com 1086 Pietro Grandi 1087 Alcatel-Lucent 1088 Optics CTO 1089 Via Trento 30 20059 Vimercate (Milano) Italy 1090 +39 039 6864930 1092 Email: pietro_vittorio.grandi@alcatel-lucent.it 1094 Eve Varma 1095 Alcatel-Lucent 1096 1A-261, 600-700 Mountain Av 1097 PO Box 636 1098 Murray Hill, NJ 07974-0636 1099 USA 1100 Email: eve.varma@alcatel-lucent.com 1102 Intellectual Property 1104 The IETF Trust takes no position regarding the validity or scope of 1105 any Intellectual Property Rights or other rights that might be 1106 claimed to pertain to the implementation or use of the technology 1107 described in any IETF Document or the extent to which any license 1108 under such rights might or might not be available; nor does it 1109 represent that it has made any independent effort to identify any 1110 such rights. 1112 Copies of Intellectual Property disclosures made to the IETF 1113 Secretariat and any assurances of licenses to be made available, or 1114 the result of an attempt made to obtain a general license or 1115 permission for the use of such proprietary rights by implementers or 1116 users of this specification can be obtained from the IETF on-line IPR 1117 repository at http://www.ietf.org/ipr 1119 The IETF invites any interested party to bring to its attention any 1120 copyrights, patents or patent applications, or other proprietary 1121 rights that may cover technology that may be required to implement 1122 any standard or specification contained in an IETF Document. Please 1123 address the information to the IETF at ietf-ipr@ietf.org. 1125 The definitive version of an IETF Document is that published by, or 1126 under the auspices of, the IETF. Versions of IETF Documents that are 1127 published by third parties, including those that are translated into 1128 other languages, should not be considered to be definitive versions 1129 of IETF Documents. The definitive version of these Legal Provisions 1130 is that published by, or under the auspices of, the IETF. Versions of 1131 these Legal Provisions that are published by third parties, including 1132 those that are translated into other languages, should not be 1133 considered to be definitive versions of these Legal Provisions. 1135 For the avoidance of doubt, each Contributor to the IETF Standards 1136 Process licenses each Contribution that he or she makes as part of 1137 the IETF Standards Process to the IETF Trust pursuant to the 1138 provisions of RFC 5378. No language to the contrary, or terms, 1139 conditions or rights that differ from or are inconsistent with the 1140 rights and licenses granted under RFC 5378, shall have any effect and 1141 shall be null and void, whether published or posted by such 1142 Contributor, or included with or in such Contribution. 1144 Disclaimer of Validity 1146 All IETF Documents and the information contained therein are provided 1147 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1148 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1149 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1150 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1151 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1152 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1153 FOR A PARTICULAR PURPOSE. 1155 Copyright Notice 1157 Copyright (c) 2013 IETF Trust and the persons identified as the 1158 document authors. All rights reserved. 1160 This document is subject to BCP 78 and the IETF Trust's Legal 1161 Provisions Relating to IETF Documents 1162 (http://trustee.ietf.org/license-info) in effect on the date of 1163 publication of this document. Please review these documents 1164 carefully, as they describe your rights and restrictions with respect 1165 to this document. Code Components extracted from this document must 1166 include Simplified BSD License text as described in Section 4.e of 1167 the Trust Legal Provisions and are provided without warranty as 1168 described in the Simplified BSD License.