idnits 2.17.1 draft-ietf-ccamp-otn-g709-info-model-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([G.709-2012]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 25, 2013) is 3930 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-ccamp-gmpls-g709-framework-13 == Outdated reference: A later version (-13) exists of draft-ietf-ccamp-gmpls-ospf-g709v3-07 == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-gmpls-signaling-g709v3-10 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group S. Belotti, Ed. 3 Internet-Draft P. Grandi 4 Intended status: Informational Alcatel-Lucent 5 Expires: December 27, 2013 D. Ceccarelli, Ed. 6 D. Caviglia 7 Ericsson 8 F. Zhang 9 D. Li 10 Huawei Technologies 11 June 25, 2013 13 Evaluation of existing GMPLS encoding against G.709v3 Optical Transport 14 Networks (OTN) 15 draft-ietf-ccamp-otn-g709-info-model-09 17 Abstract 19 ITU-T recommendation G.709 [G.709-2012] has introduced new fixed and 20 flexible Optical Data Unit (ODU) containers in Optical Transport 21 Networks (OTNs). 23 This document provides an evaluation of existing Generalized 24 Multiprotocol Label Switching (GMPLS) routing and signaling protocols 25 against the G.709 [G.709-2012] OTN networks. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 27, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. G.709 Mapping and Multiplexing Capabilities . . . . . . . . . 3 63 3. Tributary Slot Granularity . . . . . . . . . . . . . . . . . . 6 64 3.1. Data Plane Considerations . . . . . . . . . . . . . . . . 6 65 3.1.1. Payload Type and TS granularity relationship . . . . . 6 66 3.1.2. Fall-back procedure . . . . . . . . . . . . . . . . . 8 67 3.2. Control Plane considerations . . . . . . . . . . . . . . . 8 68 4. Tributary Port Number . . . . . . . . . . . . . . . . . . . . 12 69 5. Signal type . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 6. Bit rate and tolerance . . . . . . . . . . . . . . . . . . . . 14 71 7. Unreserved Resources . . . . . . . . . . . . . . . . . . . . . 14 72 8. Maximum LSP Bandwidth . . . . . . . . . . . . . . . . . . . . 14 73 9. Distinction between terminating and switching capability . . . 15 74 10. Priority Support . . . . . . . . . . . . . . . . . . . . . . . 17 75 11. Multi-stage multiplexing . . . . . . . . . . . . . . . . . . . 17 76 12. Generalized Label . . . . . . . . . . . . . . . . . . . . . . 18 77 13. Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 79 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 81 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 17.1. Normative References . . . . . . . . . . . . . . . . . . . 20 83 17.2. Informative References . . . . . . . . . . . . . . . . . . 20 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 GMPLS routing and signaling, as defined by [RFC4203], [RFC3473] and 89 [RFC4328], provides the mechanisms for basic GMPLS control of OTN 90 networks based on the 2001 revision of the G.709 specification. The 91 2012 revision of the G.709 specification, [G.709-2012], includes new 92 OTN features which are not supported by GMPLS. 94 This document provides an evaluation of exiting GMPLS signaling and 95 routing protocols against G.709 [G.709-2012] requirements. 96 Background information and a framework for the GMPLS protocol 97 extensions need to support [G.709-2012] is provided in [OTN-FWK]. 98 Specific routing and signaling extensions are defined in [OTN-OSPF] 99 and [OTN-RSVP]. 101 2. G.709 Mapping and Multiplexing Capabilities 103 The digital OTN layered structure is comprised of digital path layer 104 (ODU) and digital section layer (OTU). An OTU (Optical Transport 105 Unit) section layer supports one ODU path layer as client and 106 provides monitoring capability for the OCh. An ODU path layer may 107 transport a heterogeneous assembly of ODU clients. Some types of 108 ODUs (i.e., ODU1, ODU2, ODU3, ODU4) may assume either a client or 109 server role within the context of a particular networking domain. 110 ITU-T G.872 recommendation [G.872] provides two tables defining 111 mapping and multiplexing capabilities of OTNs, which are reported 112 below. 114 +--------------------+--------------------+ 115 | ODU client | OTU server | 116 +--------------------+--------------------+ 117 | ODU 0 | - | 118 +--------------------+--------------------+ 119 | ODU 1 | OTU 1 | 120 +--------------------+--------------------+ 121 | ODU 2 | OTU 2 | 122 +--------------------+--------------------+ 123 | ODU 2e | - | 124 +--------------------+--------------------+ 125 | ODU 3 | OTU 3 | 126 +--------------------+--------------------+ 127 | ODU 4 | OTU 4 | 128 +--------------------+--------------------+ 129 | ODU flex | - | 130 +--------------------+--------------------+ 132 Figure 1: OTN mapping capability 134 +=================================+=========================+ 135 | ODU client | ODU server | 136 +---------------------------------+-------------------------+ 137 | 1.25 Gbps client | | 138 +---------------------------------+ ODU 0 | 139 | - | | 140 +=================================+=========================+ 141 | 2.5 Gbps client | | 142 +---------------------------------+ ODU 1 | 143 | ODU 0 | | 144 +=================================+=========================+ 145 | 10 Gbps client | | 146 +---------------------------------+ ODU 2 | 147 | ODU0,ODU1,ODUflex | | 148 +=================================+=========================+ 149 | 10.3125 Gbps client | | 150 +---------------------------------+ ODU 2e | 151 | - | | 152 +=================================+=========================+ 153 | 40 Gbps client | | 154 +---------------------------------+ ODU 3 | 155 | ODU0,ODU1,ODU2,ODU2e,ODUflex | | 156 +=================================+=========================+ 157 | 100 Gbps client | | 158 +---------------------------------+ ODU 4 | 159 |ODU0,ODU1,ODU2,ODU2e,ODU3,ODUflex| | 160 +=================================+=========================+ 161 |CBR clients from greater than | | 162 |2.5 Gbit/s to 100 Gbit/s: or | | 163 |GFP-F mapped packet clients from | ODUflex | 164 |1.25 Gbit/s to 100 Gbit/s. | | 165 +---------------------------------+ | 166 | - | | 167 +=================================+=========================+ 169 Figure 2: OTN multiplexing capability 171 How an ODUk connection service is transported within an operator 172 network is governed by operator policy. For example, the ODUk 173 connection service might be transported over an ODUk path over an 174 OTUk section, with the path and section being at the same rate as 175 that of the connection service (see Table 1). In this case, an 176 entire lambda of capacity is consumed in transporting the ODUk 177 connection service. On the other hand, the operator might exploit 178 different multiplexing capabilities in the network to improve 179 infrastructure efficiencies within any given networking domain. In 180 this case, ODUk multiplexing may be performed prior to transport over 181 various rate ODU servers (as per Table 2) over associated OTU 182 sections. 184 From the perspective of multiplexing relationships, a given ODUk may 185 play different roles as it traverses various networking domains. 187 As detailed in [OTN-FWK], client ODUk connection services can be 188 transported over: 190 o Case A) one or more wavelength sub-networks connected by optical 191 links or 193 o Case B) one or more ODU links (having sub-lambda and/or lambda 194 bandwidth granularity) 196 o Case C) a mix of ODU links and wavelength sub-networks. 198 This document considers the TE information needed for ODU path 199 computation and parameters needed to be signaled for LSP setup. 201 The following sections list and analyze, for each type of data that 202 needs to be advertised and signaled, what is already there in GMPLS 203 and what is missing. 205 3. Tributary Slot Granularity 207 ITU-T recommendation defines two types of Tributary Slot (TS) 208 granularity. This TS granularity is defined per layer, meaning that 209 both ends of a link can select proper TS granularity differently for 210 each supported layer, based on the rules below: 212 - If both ends of a link are new cards supporting both 1.25Gbps TS 213 and 2.5Gbps TS, then the link will work with 1.25Gbps TS. 215 - If one end is a new card supporting both the 1.25Gbps and 216 2.5Gbps TS granularities, and the other end is an old card 217 supporting just the 2.5Gbps TS granularity, the link will work 218 with 2.5Gbps TS granularity. 220 3.1. Data Plane Considerations 222 3.1.1. Payload Type and TS granularity relationship 224 As defined in G.709-2012 an ODUk container consist of an Optical 225 Payload Unit (OPUk) plus a specific ODUk Overhead (OH). OPUk OH 226 information is added to the OPUk information payload to create an 227 OPUk. It includes information to support the adaptation of client 228 signals. Within the OPUk overhead there is the payload structure 229 identifier (PSI) that includes the payload type (PT). The payload 230 type (PT) is used to indicate the composition of the OPUk signal. 231 When an ODUj signal is multiplexed into an ODUk, the ODUj signal is 232 first extended with frame alignment overhead and then mapped into an 233 Optical channel Data Tributary Unit (ODTU). Two different types of 234 ODTU are defined: 236 - ODTUjk ((j,k) = {(0,1), (1,2), (1,3), (2,3)}; ODTU01, ODTU12, 237 ODTU13 and ODTU23) in which an ODUj signal is mapped via the 238 Asynchronous Mapping Procedure (AMP), defined in clause 19.5 of 239 G.709-2012. 241 - ODTUk.ts ((k,ts) = (2,1..8), (3,1..32), (4,1..80)) in which a 242 lower order ODU (ODU0, ODU1, ODU2, ODU2e, ODU3, ODUflex) signal is 243 mapped via the Generic Mapping Procedure (GMP), defined in clause 244 19.6 of G.709-2012. 246 G.709-2012 introduces also a logical entity, called Optical Data 247 Tributary Unit Group (ODTUGk), characterizing the multiplexing of the 248 various ODTU. The ODTUGk is then mapped into OPUK. ODTUjk and 249 ODTUk.ts signals are directly time-division multiplexed into the 250 tributary slots of an HO OPUk. 252 When PT is assuming value 0x20 or 0x21,together with OPUk type (K= 253 1,2,3,4), it is used to discriminate two different ODU multiplex 254 structure ODTUGx : 256 - Value 0x20: supporting ODTUjk only, 258 - Value 0x21: supporting ODTUk.ts or ODTUk.ts and ODTUjk. 260 The distinction is needed for OPUk with K =2 or 3, since OPU2 and 261 OPU3 are able to support both the different ODU multiplex structures. 262 For OPU4 and OPU1, only one type of ODTUG is supported: ODTUG4 with 263 PT=0x21 and ODTUG1 with PT=0x20. (see table Figure 6).The 264 relationship between PT and TS granularity, is in the fact that the 265 two different ODTUGk discriminated by PT and OPUk are characterized 266 by two different TS granularities of the related OPUk, the former at 267 2.5Gbps, the latter at 1.25Gbps. 269 In order to complete the picture, in the PSI OH there is also the 270 Multiplex Structure Identifier (MSI) that provides the information on 271 which tributary slots the different ODTUjk or ODTUk.ts are mapped 272 into the related OPUk. The following figure shows how the client 273 traffic is multiplexed till the OPUk layer. 275 +--------+ +------------+ 276 +----+ | !------| ODTUjk |-----Client 277 | | | ODTUGk | +-----.------+ 278 | |-----| PT=0x21| . 279 | | | | +-----.------+ 280 | | | |------| ODTUk.TS |-----Client 281 |OPUk| +--------+ +------------+ 282 | | 283 | | +--------+ +------------+ 284 | | | |------| ODTUjk |-----Client 285 | |-----| | +-----.------+ 286 +----+ | ODTUGk | . 287 | PT=0x20| +-----.------+ 288 | |------| ODTUjk |-----Client 289 +--------+ +------------+ 291 Figure 3: OTN client multiplexing 293 3.1.2. Fall-back procedure 295 ITU-T G.798 [G.798] describes the so called PT=0x21-to-PT=0x20 296 interworking process that explains how two nodes with interfaces with 297 different PayloadType, and hence different TS granularity (1.25Gbps 298 vs. 2.5Gbps), can be coordinated so to permit the equipment with 1.25 299 TS granularity to adapt his TS allocation accordingly to the 300 different TS granularity (2.5Gbps) of a neighbor. 302 Therefore, in order to let the NE change TS granularity accordingly 303 to the neighbor requirements, the AUTOpayloadtype [G.798] needs to be 304 set. When both the neighbors (link or trail) have been configured as 305 structured, the payload type received in the overhead is compared to 306 the transmitted PT. If they are different and the transmitted 307 PT=0x21, the node must fallback to PT=0x20. In this case the 308 fallback process makes the system self-consistent and the only reason 309 for signaling the TS granularity is to provide the correct label 310 (i.e. label for PT=0x21 has twice the TS number of PT=0x20). On the 311 other side, if the AUTOpayloadtype is not configured, the RSVP-TE 312 consequent actions in case of TS mismatch need to be defined. 314 3.2. Control Plane considerations 316 When setting up an ODUj over an ODUk, it is possible to identify two 317 types of TS granularity, the server and the client one. The server 318 TS granularity is used to map an end to end ODUj onto a server ODUk 319 LSP or links. This parameter cannot be influenced in any way from 320 the ODUj LSP: ODUj LSP will be mapped on tributary slots available on 321 the different links/ODUk LSPs. When setting up an ODUj at a given 322 rate, the fact that it is carried over a path composed by links/ 323 Forwarding Adjacencies(FAs) structured with 1.25Gbps or 2.5Gbps TS 324 granularity is completely transparent to the end to end ODUj. 326 The client TS granularity information is one of the parameters needed 327 to correctly select the adaptation towards the client layers at the 328 end nodes and this is the only thing that the ODUj has to guarantee. 330 In figure 4 an example of client and server TS granularity 331 utilization in a scenario with mixed [RFC4328] OTN and [G.709-2012] 332 OTN interfaces is shown. 334 ODU1-LSP 335 ......................................... 336 TSG-C| |TSG-C 337 1.25| ODU2-H-LSP |1.25 338 +------------X--------------------------+ 339 | TSG-S| |TSG-S 340 | 2.5| |2.5 341 | | ODU3-H-LSP | 342 | |------------X-------------| 343 | | | 344 +--+--+ +--+--+ +---+-+ 345 | | | | +-+ +-+ | | 346 | A +------+ B +-----+ +***+ +-----+ Z | 347 | V.3 | OTU2 | V.1 |OTU3 +-+ +-+ OTU3| V.3 | 348 +-----+ +-----+ +-----+ 350 ... Service LSP 351 --- H-LSP 353 Figure 4: Client-Server TS granularity example 355 In this scenario, an ODU3 LSP is setup from node B to Z. Node B has 356 an old interface able to support 2.5Gbps TS granularity, hence only 357 client TS granularity equal to 2.5Gbps can be exported to ODU3 H-LSP 358 possible clients. An ODU2 LSP is setup from node A to node Z with 359 client TS granularity 1.25Gbps signaled and exported towards clients. 360 The ODU2 LSP is carried by ODU3 H-LSP from B to Z. Due to the 361 limitations of old node B interface, the ODU2 LSP is mapped with 362 2.5Gbps TS granularity over the ODU3 H-LSP. Then an ODU1 LSP is 363 setup from A to Z, carried by the ODU2 H-LSP and mapped over it using 364 a 1.25Gbps TS granularity. 366 What is shown in the example is that the TS granularity processing is 367 a per layer issue: even if the ODU3 H-LSP is created with TS 368 granularity client at 2.5Gbps, the ODU2 H-LSP must guarantee a 369 1.25Gbps TS granularity client. ODU3 H-LSP is eligible from ODU2 LSP 370 perspective since from the routing it is known that this ODU3 371 interface at node Z, supports an ODU2 termination exporting a TS 372 granularity 1.25Gbps/2.5Gbps. 374 The TS granularity information is needed in the routing protocol as 375 the ingress node (A in the previous example) needs to know if the 376 interfaces at the last hop can support the required TS granularity. 377 In case they cannot, A will compute an alternate path from itself to 378 Z (see figure 4). 380 Moreover, also TS granularity information needs to be signaled. 381 Consider as example the setup of an ODU3 forwarding adjacency that is 382 going to carry an ODU0, hence the support of 1.25Gbps TS is needed. 383 The information related to the TS granularity has to be carried in 384 the signaling to permit node C (see figure 5) choose the right one 385 among the different interfaces (with different TS granularitys) 386 towards D. In case the full ERO is provided in the signaling with 387 explicit interface declaration, there is no need for C to choose the 388 right interface towards D as it has been already decided by the 389 ingress node or by the PCE. 391 ODU3 392 <----------------------> 394 ODU0 395 <--------------------------------------> 396 | | 397 +--------+ +--------+ +--------+ +--------+ 398 | | | | | | 1.25 | | 399 | Node | | Node | | Node +------+ Node | 400 | A +------+ B +------+ C | ODU3 | D | 401 | | ODU3 | | ODU3 | +------+ | 402 +--------+ 1.25 +--------+ 2.5 +--------+ 2.5 +--------+ 404 Figure 5: TS granularity in signaling 406 In case an ODUk FA_LSP needs to be set up nesting another ODUj (as 407 depicted in figure 5), there might be the need to know the hierarchy 408 of nested LSPs in addition to TS granularity, to permit the 409 penultimate hop (i.e. C) choosing the correct interface towards the 410 egress node or any intermediate node (i.e. B) choosing the right 411 path when performing ERO expansion. This is not needed in case we 412 allow bundling only component links with homogeneous hierarchies. In 413 case of specific implementation not specifying in the ERO the last 414 hop interface, crank-back can be a solution. 416 In a multi-stage multiplexing environment any layer can have a 417 different TS granularity structure, e.g. in a multiplexing hierarchy 418 such as ODU0->ODU2->ODU3, the ODU3 can be structured at TS 419 granularity=2.5Gbps in order to support an ODU2 connection, but this 420 ODU2 connection can be a tunnel for ODU0, and hence structured with 421 1.25Gbps TS granularity. Therefore any multiplexing level has to 422 advertise its TS granularity capabilities in order to allow a correct 423 path computation by the end nodes (both of the ODUk trail and of the 424 H-LSP/FA). 426 The following table shows the different mapping possibilities 427 depending on the TS granularity types. The client types are shown in 428 the left column, while the different OPUk server and related TS 429 granularities are listed in the top row. The table also shows the 430 relationship between the TS granularity and the payload type. 432 +------------------------------------------------+ 433 | 2.5G TS || 1.25G TS | 434 | OPU2 | OPU3 || OPU1 | OPU2 | OPU3 | OPU4 | 435 +-------+------------------------------------------------+ 436 | | - | - || AMP | GMP | GMP | GMP | 437 | ODU0 | | ||PT=0x20|PT=0x21|PT=0x21|PT=0x21| 438 +-------+------------------------------------------------+ 439 | | AMP | AMP || - | AMP | AMP | GMP | 440 | ODU1 |PT=0x20|PT=0x20|| |PT=0x21|PT=0x21|PT=0x21| 441 +-------+------------------------------------------------+ 442 | | - | AMP || - | - | AMP | GMP | 443 | ODU2 | |PT=0x20|| | |PT=0x21|PT=0x21| 444 +-------+------------------------------------------------+ 445 | | - | - || - | - | GMP | GMP | 446 | ODU2e | | || | |PT=0x21|PT=0x21| 447 +-------+------------------------------------------------+ 448 | | - | - || - | - | - | GMP | 449 | ODU3 | | || | | |PT=0x21| 450 +-------+------------------------------------------------+ 451 | | - | - || - | GMP | GMP | GMP | 452 | ODUfl | | || |PT=0x21|PT=0x21|PT=0x21| 453 +-------+------------------------------------------------+ 455 Figure 6: ODUj into OPUk mapping types (Source: Table 7-10 [G.709- 456 2012]) 458 Specific information could be defined in order to carry the 459 multiplexing hierarchy and adaptation information (i.e. TS 460 granularity/PT, AMP/GMP) to enable precise path selection. In this 461 way, when the penultimate node (or the intermediate node performing 462 ERO expansion) receives such object, together with the Traffic 463 Parameters Object, it is possible to choose the correct interface 464 towards the egress node. 466 In conclusion both routing and signaling needs to be extended to 467 appropriately represent the TS granularity/PT information. Routing 468 needs to represent a link's TS granularity and PT capabilities as 469 well as the supported multiplexing hierarchy. Signaling needs to 470 represent the TS granularity/PT and multiplexing hierarchy encoding. 472 4. Tributary Port Number 474 [RFC4328] supports only the deprecated auto-MSI mode which assumes 475 that the Tributary Port Number is automatically assigned in the 476 transmit direction and not checked in the receive direction. 478 As described in [G.709-2012] and [G.798], the OPUk overhead in an 479 OTUk frame contains n (n = the total number of TSs of the ODUk) MSI 480 (Multiplex Structure Identifier) bytes (in the form of multi-frame), 481 each of which is used to indicate the association between tributary 482 port number and tributary slot of the ODUk. 484 The association between TPN and TS has to be configured by the 485 control plane and checked by the data plane on each side of the link. 486 (Please refer to [OTN-FWK] for further details). As a consequence, 487 the RSVP-TE signaling needs to be extended to support the TPN 488 assignment function. 490 5. Signal type 492 From a routing perspective, [RFC4203] allows advertising [RFC4328] 493 interfaces (single TS type) without the capability of providing 494 precise information about bandwidth specific allocation. For 495 example, in case of link bundling, dividing the unreserved bandwidth 496 by the MAX LSP bandwidth it is not possible to know the exact number 497 of LSPs at MAX LSP bandwidth size that can be set up. (see example 498 fig. 3) 500 The lack of spatial allocation heavily impacts the restoration 501 process, because the lack of information of free resources highly 502 increases the number of crank-backs affecting network convergence 503 time. 505 Moreover actual tools provided by [RFC4203] only allow advertising 506 signal types with fixed bandwidth and implicit hierarchy (e.g. SDH/ 507 SONET networks) or variable bandwidth with no hierarchy (e.g. packet 508 switching networks) but do not provide the means for advertising 509 networks with mixed approach (e.g. ODUflex CBR and ODUflex packet). 511 For example, advertising ODU0 as MIN LSP bandwidth and ODU4 as MAX 512 LSP bandwidth it is not possible to state whether the advertised link 513 supports ODU4 and ODUflex or ODU4, ODU3, ODU2, ODU1, ODU0 and 514 ODUflex. Such ambiguity is not present in SDH networks where the 515 hierarchy is implicit and flexible containers like ODUFlex do not 516 exist. The issue could be resolved by declaring 1 ISCD for each 517 signal type actually supported by the link. 519 Supposing for example to have an equivalent ODU2 unreserved bandwidth 520 in a TE-link (with bundling capability) distributed on 4 ODU1, it 521 would be advertised via the ISCD in this way: 523 MAX LSP Bw: ODU1 525 MIN LSP Bw: ODU1 527 - Maximum Reservable Bandwidth (of the bundle) set to ODU2 529 - Unreserved Bandwidth (of the bundle) set to ODU2 531 In conclusion, the OSPF-TE extensions defined in [RFC4203] require a 532 different ISCD per signal type in order to advertise each supported 533 container. This motivates attempting to look for a more optimized 534 solution, without proliferations of the number of ISCD advertised. 535 Per [RFC2328], OSPF messages are directly encapsulated in IP 536 datagrams and depend on IP fragmentation when transmitting packets 537 larger than the network MTU. [RFC2328] recommends that "IP 538 fragmentation should be avoided whenever possible." This 539 recommendation further constraints solutions as OSPF does not support 540 any generic mechanism to fragment OSPF LSAs. 542 With respect to link bundling [RFC4201], the utilization of the ISCD 543 as it is, would not allow precise advertising of spatial bandwidth 544 allocation information unless using only one component link per TE 545 link. 547 On the other hand, from a signaling point of view, [RFC4328] 548 describes GMPLS signaling extensions to support the control for pre- 549 G.709-2012 OTNs. However, [RFC4328] needs to be updated because it 550 does not provide the means to signal all the new signal types and 551 related mapping and multiplexing functionalities. 553 6. Bit rate and tolerance 555 In the current traffic parameters signaling, bit rate and tolerance 556 are implicitly defined by the signal type. ODUflex CBR and Packet 557 can have variable bit rates(please refer to [OTN-FWK] table 2); hence 558 signaling traffic parameters need to be upgraded. With respect to 559 the tolerance there is no need to upgrade GMPLS protocols as a fixed 560 value (+/-100 ppm or +/-20ppm depending on the signal type) is 561 defined for each signal type. 563 7. Unreserved Resources 565 Unreserved resources need to be advertised per priority and per 566 signal type in order to allow the correct functioning of the 567 restoration process. [RFC4203] only allows advertising unreserved 568 resources per priority, this leads not to know how many LSPs of a 569 specific signal type can be restored. As example it is possible to 570 consider the scenario depicted in the following figure. 572 +------+ component link 1 +------+ 573 | +------------------+ | 574 | | component link 2 | | 575 | N1 +------------------+ N2 | 576 | | component link 3 | | 577 | +------------------+ | 578 +------+ +---+--+ 580 Figure 7: Concurrent path computation 582 Consider the case where a TE link is composed of 3 ODU3 component 583 links with 32TSs available on the first one, 24TSs on the second, 584 24TSs on the third and supporting ODU2 and ODU3 signal types. The 585 node would advertise a TE link unreserved bandwidth equal to 80 TSs 586 and a MAX LSP bandwidth equal to 32 TSs. In case of restoration the 587 network could try to restore 2 ODU3 (64TSs) in such TE-link while 588 only a single ODU3 can be set up and a crank-back would be 589 originated. In more complex network scenarios the number of crank- 590 backs can be much higher. 592 8. Maximum LSP Bandwidth 594 Maximum LSP bandwidth is currently advertised in the common part of 595 the ISCD and advertised per priority, while in OTN networks it is 596 only required for ODUflex advertising. This leads to a significant 597 waste of bits inside each LSA. 599 9. Distinction between terminating and switching capability 601 The capability advertised by an interface needs further distinction 602 in order to separate termination and switching capabilities. Due to 603 internal constraints and/or limitations, the type of signal being 604 advertised by an interface could be just switched (i.e. forwarded to 605 switching matrix without multiplexing/demultiplexing actions), just 606 terminated (demultiplexed) or both. The following figures help 607 explaining the switching and terminating capabilities. 609 MATRIX LINE INTERFACE 610 +-----------------+ +-----------------+ 611 | +-------+ | ODU2 | | 612 ----->| ODU-2 |----|----------|--------\ | 613 | +-------+ | | +----+ | 614 | | | \__/ | 615 | | | \/ | 616 | +-------+ | ODU3 | | ODU3 | 617 ----->| ODU-3 |----|----------|------\ | | 618 | +-------+ | | \ | | 619 | | | \| | 620 | | | +----+ | 621 | | | \__/ | 622 | | | \/ | 623 | | | ---------> OTU-3 624 +-----------------+ +-----------------+ 626 Figure 8: Switching and Terminating capabilities 628 The figure in the example shows a line interface able to: 630 - Multiplex an ODU2 coming from the switching matrix into and ODU3 631 and map it into an OTU3 633 - Map an ODU3 coming from the switching matrix into an OTU3 635 In this case the interface bandwidth advertised is ODU2 with 636 switching capability and ODU3 with both switching and terminating 637 capabilities. 639 This piece of information needs to be advertised together with the 640 related unreserved bandwidth and signal type. As a consequence 641 signaling must have the possibility to setup an LSP allowing the 642 local selection of resources consistent with the limitations 643 considered during the path computation. 645 In figures 9 and 10 there are two examples of the need of 646 termination/switching capability differentiation. In both examples 647 all nodes only support single-stage capability. Figure 9 represents 648 a scenario in which a failure on link B-C forces node A to calculate 649 another ODU2 LSP path carrying ODU0 service along the nodes B-E-D. 650 As node D is a single stage capable node, it is able to extract ODU0 651 service only from ODU2 interface. Node A has to know that from E to 652 D exists an available OTU2 link from which node D can extract the 653 ODU0 service. This information is required in order to avoid that 654 the OTU3 link is considered in the path computation. 656 ODU0 transparently transported 657 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 658 | ODU2 LSP Carrying ODU0 service | 659 | |'''''''''''''''''''''''''''''''''''''''''''| | 660 | | | | 661 | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | 662 ODU0 | | Link | | Link | | Link | | ODU0 663 ---->| A |_________| B |_________| C |_________| D |----> 664 | | | | | | | | 665 +-----+ +--+--+ +-----+ ++--+-+ 666 | | | 667 OTU3| | | 668 Link| +-----+__________________| | 669 | | | OTU3 Link | 670 |____| E | | 671 | |_____________________| 672 +-----+ OTU2 Link 674 Figure 9: Switching and Terminating capabilities - Example 1 676 Figure 7 addresses the scenario in which the restoration of the ODU2 677 LSP (ABCD) is required. The two bundled component links between B 678 and E could be used, but the ODU2 over the OTU2 component link can 679 only be terminated and not switched. This implies that it cannot be 680 used to restore the ODU2 LSP (ABCD). However such ODU2 unreserved 681 bandwidth must be advertised since it can be used for a different 682 ODU2 LSP terminating on E, e.g. (FBE). Node A has to know that the 683 ODU2 capability on the OTU2 link can only be terminated and that the 684 restoration of (ABCD) can only be performed using the ODU2 bandwidth 685 available on the OTU3 link. 687 ODU0 transparently transported 688 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 689 | ODU2 LSP Carrying ODU0 service | 690 | |'''''''''''''''''''''''''''''''''''''''''''| | 691 | | | | 692 | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | 693 ODU0 | | Link | | Link | | Link | | ODU0 694 ---->| A |_________| B |_________| C |_________| D |----> 695 | | | | | | | | 696 +-----+ ++-+-++ +-----+ +--+--+ 697 | | | | 698 OTU2| | | | 699 +-----+ Link| | | OTU3 +-----+ | 700 | | | | | Link | | | 701 | F |_______| | |___________| E |___________| 702 | | |_____________| | OTU2 Link 703 +-----+ OTU2 Link +-----+ 705 Figure 10: Switching and Terminating capabilities - Example 2 707 10. Priority Support 709 The IETF foresees that up to eight priorities must be supported and 710 that all of them have to be advertised independently on the number of 711 priorities supported by the implementation. Considering that the 712 advertisement of all the different supported signal types will 713 originate large LSAs, it is advised to advertise only the information 714 related to the really supported priorities. 716 11. Multi-stage multiplexing 718 With reference to the [OTN-FWK], introduction of multi-stage 719 multiplexing implies the advertisement of cascaded adaptation 720 capabilities together with the matrix access constraints. The 721 structure defined by IETF for the advertisement of adaptation 722 capabilities is ISCD/IACD as in [RFC4202] and [RFC5339]. 723 Modifications to ISCD/IACD, if needed, have to be addressed in the 724 related encoding documents. 726 With respect to the routing, please note that in case of multi stage 727 multiplexing hierarchy (e.g. ODU1->ODU2->ODU3), not only the ODUk/ 728 OTUk bandwidth (ODU3) and service layer bandwidth (ODU1) are needed, 729 but also the intermediate one (ODU2). This is a typical case of 730 spatial allocation problem. 732 Suppose in this scenario to have the following advertisement: 734 Hierarchy: ODU1->ODU2->ODU3 736 Number of ODU1==5 738 The number of ODU1 suggests that it is possible to have an ODU2 FA, 739 but it depends on the spatial allocation of such ODU1s. 741 It is possible that 2 links are bundled together and 3 742 ODU1->ODU2->ODU3 are available on a component link and 2 on the other 743 one, in such a case no ODU2 FA could be set up. The advertisement of 744 the ODU2 is needed because in case of ODU1 spatial allocation (3+2), 745 the ODU2 available bandwidth would be 0 (no ODU2 FA can be created), 746 while in case of ODU1 spatial allocation (4+1) the ODU2 available 747 bandwidth would be 1 (1 ODU2 FA can be created). 749 12. Generalized Label 751 The ODUk label format defined in [RFC4328] could be updated to 752 support new signal types defined in [G.709-2012] but would hardly be 753 further enhanced to support possible new signal types. 755 Furthermore such label format may have scalability issues due to the 756 high number of labels needed when signaling large LSPs. For example, 757 when an ODU3 is mapped into an ODU4 with 1.25Gbps tributary slots, it 758 would require the utilization of thirty-one labels (31*4*8=992 bits) 759 to be allocated while an ODUflex into an ODU4 may need up to eighty 760 labels (80*4*8=2560 bits). 762 A new flexible and scalable ODUk label format needs to be defined. 764 13. Security Considerations 766 This document provides an evaluation of OTN requirements against 767 actual routing [RFC4202] and [RFC4203] and signaling mechanism 768 [RFC3471], [RFC3473] and [RFC4328]in GMPLS. 770 New types of information to be conveyed regard OTN containers and 771 hierarchies and from a security standpoint this memo does not 772 introduce further risks with respect to the information that can be 773 currently conveyed via GMPLS protocols. For a general discussion on 774 MPLS and GMPLS-related security issues, see the MPLS/GMPLS security 775 framework [RFC5920]. 777 14. IANA Considerations 779 This informational document does not make any requests for IANA 780 action. 782 15. Contributors 784 Jonathan Sadler, Tellabs 786 EMail: jonathan.sadler@tellabs.com 788 John Drake, Juniper 790 EMail: jdrake@juniper.net 792 Francesco Fondelli 794 Ericsson 796 Via Moruzzi 1 798 Pisa - 56100 800 Email: francesco.fondelli@ericsson.com 802 16. Acknowledgements 804 The authors would like to thank Lou Berger, Eve Varma and Sergio 805 Lanzone for their precious collaboration and review. 807 17. References 808 17.1. Normative References 810 [G.709-2012] 811 ITU-T, "Rec G.709, version 4", approved by ITU-T in 2012. 813 [G.798] ITU-T, "Revised version of G.798 Characteristics of 814 optical transport network hierarchy equipment functional 815 blocks", consented by ITU-T on December 2012. 817 [G.872] ITU-T, "Revised version of G.872: Architecture of optical 818 transport networks for consent", consented by ITU-T on 819 December 2012. 821 17.2. Informative References 823 [OTN-FWK] F.Zhang, D.Li, H.Li, S.Belotti, D.Ceccarelli, "Framework 824 for GMPLS and PCE Control of G.709 Optical Transport 825 Networks", work in 826 progress draft-ietf-ccamp-gmpls-g709-framework-13, June 827 2013. 829 [OTN-OSPF] 830 D.Ceccarelli,D.Caviglia,F.Zhang,D.Li,Y.Xu,P.Grandi,S.Belot 831 ti, "Traffic Engineering Extensions to OSPF for 832 Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN 833 Networks", work in 834 progress draft-ietf-ccamp-gmpls-ospf-g709v3-07, June 2013. 836 [OTN-RSVP] 837 F.Zhang, G.Zhang, S.Belotti, D.Ceccarelli, K.Pithewan, 838 "Generalized Multi-Protocol Label Switching (GMPLS) 839 Signaling Extensions for the evolving G.709 Optical 840 Transport Networks Control, work in progress 841 draft-ietf-ccamp-gmpls-signaling-g709v3-10", 842 November 2012. 844 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 846 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 847 (GMPLS) Signaling Functional Description", RFC 3471, 848 January 2003. 850 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 851 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 852 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 854 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 855 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 857 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 858 Support of Generalized Multi-Protocol Label Switching 859 (GMPLS)", RFC 4202, October 2005. 861 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 862 of Generalized Multi-Protocol Label Switching (GMPLS)", 863 RFC 4203, October 2005. 865 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 866 Switching (GMPLS) Signaling Extensions for G.709 Optical 867 Transport Networks Control", RFC 4328, January 2006. 869 [RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing 870 GMPLS Protocols against Multi-Layer and Multi-Region 871 Networks (MLN/MRN)", RFC 5339, September 2008. 873 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 874 Networks", RFC 5920, July 2010. 876 Authors' Addresses 878 Sergio Belotti (editor) 879 Alcatel-Lucent 880 Via Trento, 30 881 Vimercate 882 Italy 884 Email: sergio.belotti@alcatel-lucent.com 886 Pietro Vittorio Grandi 887 Alcatel-Lucent 888 Via Trento, 30 889 Vimercate 890 Italy 892 Email: pietro_vittorio.grandi@alcatel-lucent.com 894 Daniele Ceccarelli (editor) 895 Ericsson 896 Via A. Negrone 1/A 897 Genova - Sestri Ponente 898 Italy 900 Email: daniele.ceccarelli@ericsson.com 901 Diego Caviglia 902 Ericsson 903 Via A. Negrone 1/A 904 Genova - Sestri Ponente 905 Italy 907 Email: diego.caviglia@ericsson.com 909 Fatai Zhang 910 Huawei Technologies 911 F3-5-B R&D Center, Huawei Base 912 Shenzhen 518129 P.R.China Bantian, Longgang District 913 Phone: +86-755-28972912 915 Email: zhangfatai@huawei.com 917 Dan Li 918 Huawei Technologies 919 F3-5-B R&D Center, Huawei Base 920 Shenzhen 518129 P.R.China Bantian, Longgang District 921 Phone: +86-755-28973237 923 Email: danli@huawei.com