idnits 2.17.1 draft-ietf-ccamp-otn-g709-info-model-13.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 (November 5, 2013) is 3787 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-14 == 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-11 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: May 9, 2014 D. Ceccarelli, Ed. 6 D. Caviglia 7 Ericsson 8 F. Zhang 9 D. Li 10 Huawei Technologies 11 November 5, 2013 13 Evaluation of existing GMPLS encoding against G.709v3 Optical Transport 14 Networks (OTN) 15 draft-ietf-ccamp-otn-g709-info-model-13 17 Abstract 19 ITU-T recommendation [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 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 May 9, 2014. 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 . . . . . . . . . . . . . . . . 7 65 3.1.1. Payload Type and TS granularity relationship . . . . . 7 66 3.1.2. Fall-back procedure . . . . . . . . . . . . . . . . . 8 67 3.2. Control Plane considerations . . . . . . . . . . . . . . . 9 68 4. Tributary Port Number . . . . . . . . . . . . . . . . . . . . 12 69 5. Signal type . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 6. Bit rate and tolerance . . . . . . . . . . . . . . . . . . . . 14 71 7. Unreserved Resources . . . . . . . . . . . . . . . . . . . . . 15 72 8. Maximum LSP Bandwidth . . . . . . . . . . . . . . . . . . . . 15 73 9. Distinction between terminating and switching capability . . . 15 74 10. Priority Support . . . . . . . . . . . . . . . . . . . . . . . 18 75 11. Multi-stage multiplexing . . . . . . . . . . . . . . . . . . . 18 76 12. Generalized Label . . . . . . . . . . . . . . . . . . . . . . 19 77 13. Security Considerations . . . . . . . . . . . . . . . . . . . 19 78 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 79 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 80 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 81 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 17.1. Normative References . . . . . . . . . . . . . . . . . . . 21 83 17.2. Informative References . . . . . . . . . . . . . . . . . . 22 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 86 1. Introduction 88 GMPLS routing and signaling, as defined by [RFC4203], [RFC5307], 89 [RFC3473] and [RFC4328], provides the mechanisms for basic GMPLS 90 control of Optical Transport Networks (OTNs) based on the 2001 91 revision of the G.709 specification. The 2012 revision of the G.709 92 specification, [G.709-2012], includes new OTN features which are not 93 supported by GMPLS. 95 This document provides an evaluation of exiting GMPLS signaling and 96 routing protocols against G.709 requirements. Background information 97 and a framework for the GMPLS protocol extensions needed to support 98 G.709 is provided in [OTN-FWK]. Specific routing and signaling 99 extensions defined in [OTN-OSPF] and [OTN-RSVP] specifically address 100 the gaps identified in this document. 102 2. G.709 Mapping and Multiplexing Capabilities 104 The digital OTN layered structure is comprised of the digital path 105 layer (ODU) and the digital section layer (OTU). An OTU (Optical 106 Transport Unit) section layer supports one ODU path layer as client 107 and provides monitoring capability for the Optical Channel (OCh), 108 which is the optical path carrying the digital OTN structure. An ODU 109 path layer may transport a heterogeneous assembly of ODU clients. 110 Some types of ODUs (i.e., ODU1, ODU2, ODU3, ODU4) may assume either a 111 client or server role within the context of a particular networking 112 domain. The terms ODU1, ODU2, ODU3, ODU4, and ODUflex are explained 113 in G.709. G.872 [G.872] provides two tables defining mapping and 114 multiplexing capabilities of OTNs, which are reported below. 116 +--------------------+--------------------+ 117 | ODU client | OTU server | 118 +--------------------+--------------------+ 119 | ODU0 | - | 120 +--------------------+--------------------+ 121 | ODU1 | OTU 1 | 122 +--------------------+--------------------+ 123 | ODU2 | OTU 2 | 124 +--------------------+--------------------+ 125 | ODU2e | - | 126 +--------------------+--------------------+ 127 | ODU3 | OTU 3 | 128 +--------------------+--------------------+ 129 | ODU4 | OTU 4 | 130 +--------------------+--------------------+ 131 | ODUflex | - | 132 +--------------------+--------------------+ 134 Figure 1: OTN mapping capability 136 +=================================+=========================+ 137 | ODU client | ODU server | 138 +---------------------------------+-------------------------+ 139 | 1.25 Gbps client | | 140 +---------------------------------+ ODU0 | 141 | - | | 142 +=================================+=========================+ 143 | 2.5 Gbps client | | 144 +---------------------------------+ ODU1 | 145 | ODU0 | | 146 +=================================+=========================+ 147 | 10 Gbps client | | 148 +---------------------------------+ ODU2 | 149 | ODU0,ODU1,ODUflex | | 150 +=================================+=========================+ 151 | 10.3125 Gbps client | | 152 +---------------------------------+ ODU2e | 153 | - | | 154 +=================================+=========================+ 155 | 40 Gbps client | | 156 +---------------------------------+ ODU3 | 157 | ODU0,ODU1,ODU2,ODU2e,ODUflex | | 158 +=================================+=========================+ 159 | 100 Gbps client | | 160 +---------------------------------+ ODU4 | 161 |ODU0,ODU1,ODU2,ODU2e,ODU3,ODUflex| | 162 +=================================+=========================+ 163 |CBR* clients from greater than | | 164 |2.5 Gbit/s to 100 Gbit/s: or | | 165 |GFP-F**mapped packet clients from| ODUflex | 166 |1.25 Gbit/s to 100 Gbit/s. | | 167 +---------------------------------+ | 168 | - | | 169 +=================================+=========================+ 170 (*) - Constant Bit Rate 171 (**) - Generic Framing Procedure - Framed (GFP-F) 173 Figure 2: OTN multiplexing capability 175 In the following, the terms ODUj and ODUk are used in a multiplexing 176 scenario to identify the lower order signal (ODUj) and the higher 177 order signal (ODUk). How an ODUk connection service is transported 178 within an operator network is governed by operator policy. For 179 example, the ODUk connection service might be transported over an 180 ODUk path over an OTUk section, with the path and section being at 181 the same rate as that of the connection service (see Table 1). In 182 this case, an entire lambda of capacity is consumed in transporting 183 the ODUk connection service. On the other hand, the operator might 184 exploit different multiplexing capabilities in the network to improve 185 infrastructure efficiencies within any given networking domain. In 186 this case, ODUk multiplexing may be performed prior to transport over 187 various rate ODU servers (as per Table 2) over associated OTU 188 sections. 190 From the perspective of multiplexing relationships, a given ODUk may 191 play different roles as it traverses various networking domains. 193 As detailed in [OTN-FWK], client ODUk connection services can be 194 transported over: 196 o Case A) one or more wavelength sub-networks connected by optical 197 links or 199 o Case B) one or more ODU links (having sub-lambda and/or lambda 200 bandwidth granularity) 202 o Case C) a mix of ODU links and wavelength sub-networks. 204 This document considers the TE information needed for ODU path 205 computation and parameters needed to be signaled for Label Switched 206 Path (LSP) setup. 208 The following sections list and analyze, for each type of data that 209 needs to be advertised and signaled, what is already there in GMPLS 210 and what is missing. 212 3. Tributary Slot Granularity 214 G.709 defines two types of Tributary Slot (TS) granularity. This TS 215 granularity is defined per layer, meaning that both ends of a link 216 can select proper TS granularity differently for each supported 217 layer, based on the rules below: 219 - If both ends of a link are new cards supporting both 1.25Gbps TS 220 and 2.5Gbps TS, then the link will work with 1.25Gbps TS. 222 - If one end is a new card supporting both the 1.25Gbps and 223 2.5Gbps TS granularities, and the other end is an old card 224 supporting just the 2.5Gbps TS granularity, the link will work 225 with 2.5Gbps TS granularity. 227 3.1. Data Plane Considerations 229 3.1.1. Payload Type and TS granularity relationship 231 As defined in G.709 an ODUk container consist of an Optical Payload 232 Unit (OPUk) plus a specific ODUk Overhead (OH). OPUk OH information 233 is added to the OPUk information payload to create an OPUk. It 234 includes information to support the adaptation of client signals. 235 Within the OPUk overhead there is the payload structure identifier 236 (PSI) that includes the payload type (PT). The payload type (PT) is 237 used to indicate the composition of the OPUk signal. When an ODUj 238 signal is multiplexed into an ODUk, the ODUj signal is first extended 239 with frame alignment overhead and then mapped into an Optical channel 240 Data Tributary Unit (ODTU). Two different types of ODTU are defined: 242 - ODTUjk ((j,k) = {(0,1), (1,2), (1,3), (2,3)}; ODTU01, ODTU12, 243 ODTU13 and ODTU23) in which an ODUj signal is mapped via the 244 Asynchronous Mapping Procedure (AMP), defined in clause 19.5 of 245 G.709. 247 - ODTUk.ts ((k,ts) = (2,1..8), (3,1..32), (4,1..80)) in which a 248 lower order ODU (ODU0, ODU1, ODU2, ODU2e, ODU3, ODUflex) signal is 249 mapped via the Generic Mapping Procedure (GMP), defined in clause 250 19.6 of G.709. 252 G.709 introduces also a logical entity, called Optical Data Tributary 253 Unit Group (ODTUGk), characterizing the multiplexing of the various 254 ODTU. The ODTUGk is then mapped into OPUK. ODTUjk and ODTUk.ts 255 signals are directly time-division multiplexed into the tributary 256 slots of an HO OPUk. 258 When PT is assuming value 0x20 or 0x21,together with OPUk type (K= 259 1,2,3,4), it is used to discriminate two different ODU multiplex 260 structure ODTUGx : 262 - Value 0x20: supporting ODTUjk only, 264 - Value 0x21: supporting ODTUk.ts or ODTUk.ts and ODTUjk. 266 The distinction is needed for OPUk with K =2 or 3, since OPU2 and 267 OPU3 are able to support both the different ODU multiplex structures. 268 For OPU4 and OPU1, only one type of ODTUG is supported: ODTUG4 with 269 PT=0x21 and ODTUG1 with PT=0x20. (see table Figure 6).The 270 relationship between PT and TS granularity, is in the fact that the 271 two different ODTUGk discriminated by PT and OPUk are characterized 272 by two different TS granularities of the related OPUk, the former at 273 2.5Gbps, the latter at 1.25Gbps. 275 In order to complete the picture, in the PSI OH there is also the 276 Multiplex Structure Identifier (MSI) that provides the information on 277 which tributary slots the different ODTUjk or ODTUk.ts are mapped 278 into the related OPUk. The following figure shows how the client 279 traffic is multiplexed till the OPUk layer. 281 +--------+ +------------+ 282 +----+ | !------| ODTUjk |-----Client 283 | | | ODTUGk | +-----.------+ 284 | |-----| PT=0x21| . 285 | | | | +-----.------+ 286 | | | |------| ODTUk.TS |-----Client 287 |OPUk| +--------+ +------------+ 288 | | 289 | | +--------+ +------------+ 290 | | | |------| ODTUjk |-----Client 291 | |-----| | +-----.------+ 292 +----+ | ODTUGk | . 293 | PT=0x20| +-----.------+ 294 | |------| ODTUjk |-----Client 295 +--------+ +------------+ 297 Figure 3: OTN client multiplexing 299 3.1.2. Fall-back procedure 301 G.798 [G.798] describes the so called PT=0x21-to-PT=0x20 interworking 302 process that explains how two nodes with interfaces with different 303 PayloadType, and hence different TS granularity (1.25Gbps vs. 304 2.5Gbps), can be coordinated so to permit the equipment with 1.25 TS 305 granularity to adapt his TS allocation accordingly to the different 306 TS granularity (2.5Gbps) of a neighbor. 308 Therefore, in order to let the NE change TS granularity accordingly 309 to the neighbor requirements, the AUTOpayloadtype [G.798] needs to be 310 set. When both the neighbors (link or trail) have been configured as 311 structured, the payload type received in the overhead is compared to 312 the transmitted PT. If they are different and the transmitted 313 PT=0x21, the node must fallback to PT=0x20. In this case the 314 fallback process makes the system self-consistent and the only reason 315 for signaling the TS granularity is to provide the correct label 316 (i.e. label for PT=0x21 has twice the TS number of PT=0x20). On the 317 other side, if the AUTOpayloadtype is not configured, the RSVP-TE 318 consequent actions in case of TS mismatch need to be defined. 320 3.2. Control Plane considerations 322 When setting up an ODUj over an ODUk, it is possible to identify two 323 types of TS granularity (TSG), the server and the client one. The 324 server TS granularity is used to map an end to end ODUj onto a server 325 ODUk LSP or links. This parameter cannot be influenced in any way 326 from the ODUj LSP: ODUj LSP will be mapped on tributary slots 327 available on the different links/ODUk LSPs. When setting up an ODUj 328 at a given rate, the fact that it is carried over a path composed by 329 links/Forwarding Adjacencies(FAs) structured with 1.25Gbps or 2.5Gbps 330 TS granularity is completely transparent to the end to end ODUj. 332 The client TS granularity information is one of the parameters needed 333 to correctly select the adaptation towards the client layers at the 334 end nodes and this is the only thing that the ODUj has to guarantee. 336 In figure 4 an example of client and server TS granularity 337 utilization in a scenario with mixed [RFC4328] OTN and [G.709-2012] 338 OTN interfaces is shown. 340 ODU1-LSP 341 ......................................... 342 TSG-C| |TSG-C 343 1.25| ODU2-H-LSP |1.25 344 +------------X--------------------------+ 345 | TSG-S| |TSG-S 346 | 2.5| |2.5 347 | | ODU3-H-LSP | 348 | |------------X-------------| 349 | | | 350 +--+--+ +--+--+ +---+-+ 351 | | | | +-+ +-+ | | 352 | A +------+ B +-----+ +***+ +-----+ Z | 353 | V.3 | OTU2 | V.1 |OTU3 +-+ +-+ OTU3| V.3 | 354 +-----+ +-----+ +-----+ 356 ... Service LSP 357 --- Hierarchical-LSP (H-LSP) 359 Figure 4: Client-Server TS granularity example 361 In this scenario, an ODU3 LSP is setup from node B to Z. Node B has 362 an old interface able to support 2.5Gbps TS granularity, hence only 363 client TS granularity equal to 2.5Gbps can be exported to ODU3 H-LSP 364 possible clients. An ODU2 LSP is setup from node A to node Z with 365 client TS granularity 1.25Gbps signaled and exported towards clients. 367 The ODU2 LSP is carried by ODU3 H-LSP from B to Z. Due to the 368 limitations of old node B interface, the ODU2 LSP is mapped with 369 2.5Gbps TS granularity over the ODU3 H-LSP. Then an ODU1 LSP is 370 setup from A to Z, carried by the ODU2 H-LSP and mapped over it using 371 a 1.25Gbps TS granularity. 373 What is shown in the example is that the TS granularity processing is 374 a per layer issue: even if the ODU3 H-LSP is created with TS 375 granularity client at 2.5Gbps, the ODU2 H-LSP must guarantee a 376 1.25Gbps TS granularity client. ODU3 H-LSP is eligible from ODU2 LSP 377 perspective since from the routing it is known that this ODU3 378 interface at node Z, supports an ODU2 termination exporting a TS 379 granularity 1.25Gbps/2.5Gbps. 381 The TS granularity information is needed in the routing protocol as 382 the ingress node (A in the previous example) needs to know if the 383 interfaces at the last hop can support the required TS granularity. 384 In case they cannot, A will compute an alternate path from itself to 385 Z (see figure 4). 387 Moreover, also TS granularity information needs to be signaled. 388 Consider as example the setup of an ODU3 forwarding adjacency that is 389 going to carry an ODU0, hence the support of 1.25Gbps TS is needed. 390 The information related to the TS granularity has to be carried in 391 the signaling to permit node C (see figure 5) choose the right one 392 among the different interfaces (with different TS granularitys) 393 towards D. In case the full Explicit Route Object (ERO) is provided 394 in the signaling with explicit interface declaration, there is no 395 need for C to choose the right interface towards D as it has been 396 already decided by the ingress node or by the Path Computation 397 Element (PCE). 399 ODU3 400 <----------------------> 402 ODU0 403 <--------------------------------------> 404 | | 405 +--------+ +--------+ +--------+ +--------+ 406 | | | | | | 1.25 | | 407 | Node | | Node | | Node +------+ Node | 408 | A +------+ B +------+ C | ODU3 | D | 409 | | ODU3 | | ODU3 | +------+ | 410 +--------+ 1.25 +--------+ 2.5 +--------+ 2.5 +--------+ 412 Figure 5: TS granularity in signaling 414 In case an ODUk FA_LSP needs to be set up nesting another ODUj (as 415 depicted in figure 5), there might be the need to know the hierarchy 416 of nested LSPs in addition to TS granularity, to permit the 417 penultimate hop (i.e. C) choosing the correct interface towards the 418 egress node or any intermediate node (i.e. B) choosing the right 419 path when performing ERO expansion. This is not needed in case we 420 allow bundling only component links with homogeneous hierarchies. In 421 case of specific implementation not specifying in the ERO the last 422 hop interface, crank-back can be a solution. 424 In a multi-stage multiplexing environment any layer can have a 425 different TS granularity structure, e.g. in a multiplexing hierarchy 426 such as ODU0->ODU2->ODU3, the ODU3 can be structured at TS 427 granularity=2.5Gbps in order to support an ODU2 connection, but this 428 ODU2 connection can be a tunnel for ODU0, and hence structured with 429 1.25Gbps TS granularity. Therefore any multiplexing level has to 430 advertise its TS granularity capabilities in order to allow a correct 431 path computation by the end nodes (both of the ODUk trail and of the 432 H-LSP/FA). 434 The following table shows the different mapping possibilities 435 depending on the TS granularity types. The client types are shown in 436 the left column, while the different OPUk server and related TS 437 granularities are listed in the top row. The table also shows the 438 relationship between the TS granularity and the payload type. 440 +------------------------------------------------+ 441 | 2.5G TS || 1.25G TS | 442 | OPU2 | OPU3 || OPU1 | OPU2 | OPU3 | OPU4 | 443 +-------+------------------------------------------------+ 444 | | - | - || AMP | GMP | GMP | GMP | 445 | ODU0 | | ||PT=0x20|PT=0x21|PT=0x21|PT=0x21| 446 +-------+------------------------------------------------+ 447 | | AMP | AMP || - | AMP | AMP | GMP | 448 | ODU1 |PT=0x20|PT=0x20|| |PT=0x21|PT=0x21|PT=0x21| 449 +-------+------------------------------------------------+ 450 | | - | AMP || - | - | AMP | GMP | 451 | ODU2 | |PT=0x20|| | |PT=0x21|PT=0x21| 452 +-------+------------------------------------------------+ 453 | | - | - || - | - | GMP | GMP | 454 | ODU2e | | || | |PT=0x21|PT=0x21| 455 +-------+------------------------------------------------+ 456 | | - | - || - | - | - | GMP | 457 | ODU3 | | || | | |PT=0x21| 458 +-------+------------------------------------------------+ 459 | | - | - || - | GMP | GMP | GMP | 460 | ODUfl | | || |PT=0x21|PT=0x21|PT=0x21| 461 +-------+------------------------------------------------+ 463 Figure 6: ODUj into OPUk mapping types (Source: Table 7-10 [G.709- 464 2012]) 466 Specific information could be defined in order to carry the 467 multiplexing hierarchy and adaptation information (i.e. TS 468 granularity/PT, AMP/GMP) to enable precise path selection. In this 469 way, when the penultimate node (or the intermediate node performing 470 ERO expansion) receives such object, together with the Traffic 471 Parameters Object, it is possible to choose the correct interface 472 towards the egress node. 474 In conclusion both routing and signaling needs to be extended to 475 appropriately represent the TS granularity/PT information. Routing 476 needs to represent a link's TS granularity and PT capabilities as 477 well as the supported multiplexing hierarchy. Signaling needs to 478 represent the TS granularity/PT and multiplexing hierarchy encoding. 480 4. Tributary Port Number 482 [RFC4328] supports only the deprecated auto-MSI mode which assumes 483 that the Tributary Port Number is automatically assigned in the 484 transmit direction and not checked in the receive direction. 486 As described in [G.709-2012] and [G.798], the OPUk overhead in an 487 OTUk frame contains n (n = the total number of TSs of the ODUk) MSI 488 (Multiplex Structure Identifier) bytes (in the form of multi-frame), 489 each of which is used to indicate the association between tributary 490 port number and tributary slot of the ODUk. 492 The association between Tributary Port Number (TPN) and TS has to be 493 configured by the control plane and checked by the data plane on each 494 side of the link. (Please refer to [OTN-FWK] for further details). 495 As a consequence, the RSVP-TE signaling needs to be extended to 496 support the TPN assignment function. 498 5. Signal type 500 From a routing perspective, GMPLS OSPF [RFC4203] and GMPLS IS-IS 501 [RFC5307] only allow advertising [RFC4328] interfaces (single TS 502 type) without the capability of providing precise information about 503 bandwidth specific allocation. For example, in case of link 504 bundling, dividing the unreserved bandwidth by the MAX LSP bandwidth 505 it is not possible to know the exact number of LSPs at MAX LSP 506 bandwidth size that can be set up. (see example fig. 3) 508 The lack of spatial allocation heavily impacts the restoration 509 process, because the lack of information of free resources highly 510 increases the number of crank-backs affecting network convergence 511 time. 513 Moreover actual tools provided by [RFC4203] and [RFC5307] only allow 514 advertising signal types with fixed bandwidth and implicit hierarchy 515 (e.g. SDH/SONET networks) or variable bandwidth with no hierarchy 516 (e.g. packet switching networks) but do not provide the means for 517 advertising networks with mixed approach (e.g. ODUflex CBR and 518 ODUflex packet). 520 For example, advertising ODU0 as MIN LSP bandwidth and ODU4 as MAX 521 LSP bandwidth it is not possible to state whether the advertised link 522 supports ODU4 and ODUflex or ODU4, ODU3, ODU2, ODU1, ODU0 and 523 ODUflex. Such ambiguity is not present in SDH networks where the 524 hierarchy is implicit and flexible containers like ODUFlex do not 525 exist. The issue could be resolved by declaring 1 Interface 526 Switching Capability Descriptor (ISCD) for each signal type actually 527 supported by the link. 529 Supposing for example to have an equivalent ODU2 unreserved bandwidth 530 in a TE-link (with bundling capability) distributed on 4 ODU1, it 531 would be advertised via the ISCD in this way: 533 MAX LSP Bandwidth: ODU1 535 MIN LSP Bandwidth: ODU1 537 - Maximum Reservable Bandwidth (of the bundle) set to ODU2 539 - Unreserved Bandwidth (of the bundle) set to ODU2 541 In conclusion, the routing extensions defined in [RFC4203] and 542 [RFC5307] require a different ISCD per signal type in order to 543 advertise each supported container. This motivates attempting to 544 look for a more optimized solution, without proliferations of the 545 number of ISCD advertised. 547 Per [RFC2328], OSPF messages are directly encapsulated in IP 548 datagrams and depend on IP fragmentation when transmitting packets 549 larger than the network MTU. [RFC2328] recommends that "IP 550 fragmentation should be avoided whenever possible." This 551 recommendation further constraints solutions as OSPF does not support 552 any generic mechanism to fragment OSPF Link State Advertisements 553 (LSAs). Even when used in IP environments IS-IS [RFC1195], does not 554 support message sizes larger than a link's maximum frame size. 556 With respect to link bundling [RFC4201], the utilization of the ISCD 557 as it is, would not allow precise advertising of spatial bandwidth 558 allocation information unless using only one component link per TE 559 link. 561 On the other hand, from a signaling point of view, [RFC4328] 562 describes GMPLS signaling extensions to support the control of G.709 563 OTNs defined before 2011 [G.709-2001]. However, [RFC4328] needs to 564 be updated because it does not provide the means to signal all the 565 new signal types and related mapping and multiplexing 566 functionalities. 568 6. Bit rate and tolerance 570 In the current traffic parameters signaling, bit rate and tolerance 571 are implicitly defined by the signal type. ODUflex CBR and Packet 572 can have variable bit rates(please refer to [OTN-FWK] table 2); hence 573 signaling traffic parameters need to be upgraded. With respect to 574 tolerance there is no need to upgrade GMPLS protocols as a fixed 575 value (+/-100 ppm or +/-20ppm depending on the signal type) is 576 defined for each signal type. 578 7. Unreserved Resources 580 Unreserved resources need to be advertised per priority and per 581 signal type in order to allow the correct functioning of the 582 restoration process. [RFC4203] only allows advertising unreserved 583 resources per priority, this leads not to know how many LSPs of a 584 specific signal type can be restored. As example it is possible to 585 consider the scenario depicted in the following figure. 587 +------+ component link 1 +------+ 588 | +------------------+ | 589 | | component link 2 | | 590 | N1 +------------------+ N2 | 591 | | component link 3 | | 592 | +------------------+ | 593 +------+ +---+--+ 595 Figure 7: Concurrent path computation 597 Consider the case where a TE link is composed of 3 ODU3 component 598 links with 32TSs available on the first one, 24TSs on the second, 599 24TSs on the third and supporting ODU2 and ODU3 signal types. The 600 node would advertise a TE link unreserved bandwidth equal to 80 TSs 601 and a MAX LSP bandwidth equal to 32 TSs. In case of restoration the 602 network could try to restore 2 ODU3 (64TSs) in such TE-link while 603 only a single ODU3 can be set up and a crank-back would be 604 originated. In more complex network scenarios the number of crank- 605 backs can be much higher. 607 8. Maximum LSP Bandwidth 609 Maximum LSP bandwidth is currently advertised per priority in the 610 common part of the ISCD. Section 5 reviews some of the implications 611 of advertising OTN network information using ISCDs, and identifies 612 the need for a more optimized solution. While strictly not required, 613 such an optimization effort should also consider the optimization of 614 the per priority maximum LSP bandwidth advertisement of both fixed 615 and variable ODU types. 617 9. Distinction between terminating and switching capability 619 The capability advertised by an interface needs further distinction 620 in order to separate termination and switching capabilities. Due to 621 internal constraints and/or limitations, the type of signal being 622 advertised by an interface could be just switched (i.e. forwarded to 623 switching matrix without multiplexing/demultiplexing actions), just 624 terminated (demultiplexed) or both. The following figures help 625 explaining the switching and terminating capabilities. 627 MATRIX LINE INTERFACE 628 +-----------------+ +-----------------+ 629 | +-------+ | ODU2 | | 630 ----->| ODU2 |----|----------|--------\ | 631 | +-------+ | | +----+ | 632 | | | \__/ | 633 | | | \/ | 634 | +-------+ | ODU3 | | ODU3 | 635 ----->| ODU3 |----|----------|------\ | | 636 | +-------+ | | \ | | 637 | | | \| | 638 | | | +----+ | 639 | | | \__/ | 640 | | | \/ | 641 | | | ---------> OTU-3 642 +-----------------+ +-----------------+ 644 Figure 8: Switching and Terminating capabilities 646 The figure in the example shows a line interface able to: 648 - Multiplex an ODU2 coming from the switching matrix into and ODU3 649 and map it into an OTU3 651 - Map an ODU3 coming from the switching matrix into an OTU3 653 In this case the interface bandwidth advertised is ODU2 with 654 switching capability and ODU3 with both switching and terminating 655 capabilities. 657 This piece of information needs to be advertised together with the 658 related unreserved bandwidth and signal type. As a consequence 659 signaling must have the possibility to setup an LSP allowing the 660 local selection of resources consistent with the limitations 661 considered during the path computation. 663 In figures 9 and 10 there are two examples of the need of 664 termination/switching capability differentiation. In both examples 665 all nodes only support single-stage capability. Figure 9 represents 666 a scenario in which a failure on link B-C forces node A to calculate 667 another ODU2 LSP path carrying ODU0 service along the nodes B-E-D. 668 As node D is a single stage capable node, it is able to extract ODU0 669 service only from ODU2 interface. Node A has to know that from E to 670 D exists an available OTU2 link from which node D can extract the 671 ODU0 service. This information is required in order to avoid that 672 the OTU3 link is considered in the path computation. 674 ODU0 transparently transported 675 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 676 | ODU2 LSP Carrying ODU0 service | 677 | |'''''''''''''''''''''''''''''''''''''''''''| | 678 | | | | 679 | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | 680 ODU0 | | Link | | Link | | Link | | ODU0 681 ---->| A |_________| B |_________| C |_________| D |----> 682 | | | | | | | | 683 +-----+ +--+--+ +-----+ ++--+-+ 684 | | | 685 OTU3| | | 686 Link| +-----+__________________| | 687 | | | OTU3 Link | 688 |____| E | | 689 | |_____________________| 690 +-----+ OTU2 Link 692 Figure 9: Switching and Terminating capabilities - Example 1 694 Figure 10 addresses the scenario in which the restoration of the ODU2 695 LSP (ABCD) is required. The two bundled component links between B 696 and E could be used, but the ODU2 over the OTU2 component link can 697 only be terminated and not switched. This implies that it cannot be 698 used to restore the ODU2 LSP (ABCD). However such ODU2 unreserved 699 bandwidth must be advertised since it can be used for a different 700 ODU2 LSP terminating on E, e.g. (FBE). Node A has to know that the 701 ODU2 capability on the OTU2 link can only be terminated and that the 702 restoration of (ABCD) can only be performed using the ODU2 bandwidth 703 available on the OTU3 link. 705 ODU0 transparently transported 706 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 707 | ODU2 LSP Carrying ODU0 service | 708 | |'''''''''''''''''''''''''''''''''''''''''''| | 709 | | | | 710 | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | 711 ODU0 | | Link | | Link | | Link | | ODU0 712 ---->| A |_________| B |_________| C |_________| D |----> 713 | | | | | | | | 714 +-----+ ++-+-++ +-----+ +--+--+ 715 | | | | 716 OTU2| | | | 717 +-----+ Link| | | OTU3 +-----+ | 718 | | | | | Link | | | 719 | F |_______| | |___________| E |___________| 720 | | |_____________| | OTU2 Link 721 +-----+ OTU2 Link +-----+ 723 Figure 10: Switching and Terminating capabilities - Example 2 725 The issue shown above is analyzed in an OTN context but it is a 726 general technology independent GMPLS limitation. 728 10. Priority Support 730 [RFC4202] defines 8 priorities for resource availability and usage. 731 As defined, each is advertised independent of the number of 732 priorities supported by a network, and even unsupported priorities 733 are included. As is the case in Section 8, addressing any 734 inefficiency with such advertisements is not required to support OTN 735 networks. But any such inefficiency should also be considered as 736 part of the optimization effort identified in Section 5. 738 11. Multi-stage multiplexing 740 With reference to the [OTN-FWK], introduction of multi-stage 741 multiplexing implies the advertisement of cascaded adaptation 742 capabilities together with the matrix access constraints. The 743 structure defined by IETF for the advertisement of adaptation 744 capabilities is Interface Adaptation Capability Descriptor (IACD) as 745 in [RFC4202] and [RFC5339]. 747 With respect to routing, please note that in case of multi stage 748 multiplexing hierarchy (e.g. ODU1->ODU2->ODU3), not only the ODUk/ 749 OTUk bandwidth (ODU3) and service layer bandwidth (ODU1) are needed, 750 but also the intermediate one (ODU2). This is a typical case of 751 spatial allocation problem. 753 Suppose in this scenario to have the following advertisement: 755 Hierarchy: ODU1->ODU2->ODU3 757 Number of ODU1==5 759 The number of ODU1 suggests that it is possible to have an ODU2 FA, 760 but it depends on the spatial allocation of such ODU1s. 762 It is possible that 2 links are bundled together and 3 763 ODU1->ODU2->ODU3 are available on a component link and 2 on the other 764 one, in such a case no ODU2 FA could be set up. The advertisement of 765 the ODU2 is needed because in case of ODU1 spatial allocation (3+2), 766 the ODU2 available bandwidth would be 0 (no ODU2 FA can be created), 767 while in case of ODU1 spatial allocation (4+1) the ODU2 available 768 bandwidth would be 1 (1 ODU2 FA can be created). 770 What said above implies augmenting both the ISCD and the IACD. 772 12. Generalized Label 774 The ODUk label format defined in [RFC4328] could be updated to 775 support new signal types defined in [G.709-2012] but it would be 776 difficult to further enhance it to support possible new signal types. 778 Furthermore such label format may have scalability issues due to the 779 high number of labels needed when signaling large LSPs. For example, 780 when an ODU3 is mapped into an ODU4 with 1.25Gbps tributary slots, it 781 would require the utilization of thirty-one labels (31*4*8=992 bits) 782 to be allocated while an ODUflex into an ODU4 may need up to eighty 783 labels (80*4*8=2560 bits). 785 A new flexible and scalable ODUk label format needs to be defined. 787 13. Security Considerations 789 This document provides an evaluation of OTN requirements against 790 actual routing [RFC4202], [RFC4203] and [RFC5307] and signaling 791 mechanism [RFC3471], [RFC3473] and [RFC4328]in GMPLS. 793 This document defines new types of information to be carried that 794 described OTN containers and hierarchies. It does not define any new 795 protocol elements and from a security standpoint this memo does not 796 introduce further risks with respect to the information that can be 797 currently conveyed via GMPLS protocols. For a general discussion on 798 MPLS and GMPLS-related security issues, see the MPLS/GMPLS security 799 framework [RFC5920]. 801 14. IANA Considerations 803 This informational document does not make any requests for IANA 804 action. 806 15. Contributors 808 Jonathan Sadler, Tellabs 810 EMail: jonathan.sadler@tellabs.com 812 John Drake, Juniper 814 EMail: jdrake@juniper.net 816 Francesco Fondelli 818 Ericsson 820 Via Moruzzi 1 822 Pisa - 56100 824 Email: francesco.fondelli@ericsson.com 826 16. Acknowledgements 828 The authors would like to thank Lou Berger, Eve Varma and Sergio 829 Lanzone for their precious collaboration and review. 831 17. References 832 17.1. Normative References 834 [G.709-2001] 835 ITU-T, "Rec G.709, version 1", approved by ITU-T in 2001. 837 [G.709-2012] 838 ITU-T, "Rec G.709, version 4", approved by ITU-T in 2012. 840 [G.798] ITU-T, "Revised version of G.798 Characteristics of 841 optical transport network hierarchy equipment functional 842 blocks", consented by ITU-T on December 2012. 844 [G.872] ITU-T, "Revised version of G.872: Architecture of optical 845 transport networks for consent", consented by ITU-T on 846 December 2012. 848 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 849 dual environments", RFC 1195, December 1990. 851 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 852 (GMPLS) Signaling Functional Description", RFC 3471, 853 January 2003. 855 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 856 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 857 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 859 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 860 Support of Generalized Multi-Protocol Label Switching 861 (GMPLS)", RFC 4202, October 2005. 863 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 864 of Generalized Multi-Protocol Label Switching (GMPLS)", 865 RFC 4203, October 2005. 867 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 868 Switching (GMPLS) Signaling Extensions for G.709 Optical 869 Transport Networks Control", RFC 4328, January 2006. 871 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 872 of Generalized Multi-Protocol Label Switching (GMPLS)", 873 RFC 5307, October 2008. 875 [RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing 876 GMPLS Protocols against Multi-Layer and Multi-Region 877 Networks (MLN/MRN)", RFC 5339, September 2008. 879 17.2. Informative References 881 [OTN-FWK] F.Zhang, D.Li, H.Li, S.Belotti, D.Ceccarelli, "Framework 882 for GMPLS and PCE Control of G.709 Optical Transport 883 Networks", work in 884 progress draft-ietf-ccamp-gmpls-g709-framework-14, August 885 2013. 887 [OTN-OSPF] 888 D.Ceccarelli,D.Caviglia,F.Zhang,D.Li,Y.Xu,P.Grandi,S.Belot 889 ti, "Traffic Engineering Extensions to OSPF for 890 Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN 891 Networks", work in 892 progress draft-ietf-ccamp-gmpls-ospf-g709v3-07, June 2013. 894 [OTN-RSVP] 895 F.Zhang, G.Zhang, S.Belotti, D.Ceccarelli, K.Pithewan, 896 "Generalized Multi-Protocol Label Switching (GMPLS) 897 Signaling Extensions for the evolving G.709 Optical 898 Transport Networks Control, work in progress 899 draft-ietf-ccamp-gmpls-signaling-g709v3-11", August 2012. 901 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 903 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 904 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 906 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 907 Networks", RFC 5920, July 2010. 909 Authors' Addresses 911 Sergio Belotti (editor) 912 Alcatel-Lucent 913 Via Trento, 30 914 Vimercate 915 Italy 917 Email: sergio.belotti@alcatel-lucent.com 918 Pietro Vittorio Grandi 919 Alcatel-Lucent 920 Via Trento, 30 921 Vimercate 922 Italy 924 Email: pietro_vittorio.grandi@alcatel-lucent.com 926 Daniele Ceccarelli (editor) 927 Ericsson 928 Via A. Negrone 1/A 929 Genova - Sestri Ponente 930 Italy 932 Email: daniele.ceccarelli@ericsson.com 934 Diego Caviglia 935 Ericsson 936 Via A. Negrone 1/A 937 Genova - Sestri Ponente 938 Italy 940 Email: diego.caviglia@ericsson.com 942 Fatai Zhang 943 Huawei Technologies 944 F3-5-B R&D Center, Huawei Base 945 Shenzhen 518129 P.R.China Bantian, Longgang District 946 Phone: +86-755-28972912 948 Email: zhangfatai@huawei.com 950 Dan Li 951 Huawei Technologies 952 F3-5-B R&D Center, Huawei Base 953 Shenzhen 518129 P.R.China Bantian, Longgang District 954 Phone: +86-755-28973237 956 Email: danli@huawei.com