idnits 2.17.1 draft-ietf-ccamp-otn-g709-info-model-11.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 (August 22, 2013) is 3898 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: February 23, 2014 D. Ceccarelli, Ed. 6 D. Caviglia 7 Ericsson 8 F. Zhang 9 D. Li 10 Huawei Technologies 11 August 22, 2013 13 Evaluation of existing GMPLS encoding against G.709v3 Optical Transport 14 Networks (OTN) 15 draft-ietf-ccamp-otn-g709-info-model-11 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 February 23, 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 . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . 19 78 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 79 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 81 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 17.1. Normative References . . . . . . . . . . . . . . . . . . . 20 83 17.2. Informative References . . . . . . . . . . . . . . . . . . 21 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 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 OTN networks based on the 2001 revision of the G.709 91 specification. The 2012 revision of the G.709 specification, [G.709- 92 2012], includes new 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 defined in [OTN-OSPF] and 99 [OTN-RSVP] specifically address the gaps identified in this document. 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, GMPLS OSPF [RFC4203] and GMPLS IS-IS 493 [RFC5307] only allow advertising [RFC4328] interfaces (single TS 494 type) without the capability of providing precise information about 495 bandwidth specific allocation. For example, in case of link 496 bundling, dividing the unreserved bandwidth by the MAX LSP bandwidth 497 it is not possible to know the exact number of LSPs at MAX LSP 498 bandwidth size that can be set up. (see example 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 and [RFC5307] only allow 506 advertising signal types with fixed bandwidth and implicit hierarchy 507 (e.g. SDH/SONET networks) or variable bandwidth with no hierarchy 508 (e.g. packet switching networks) but do not provide the means for 509 advertising networks with mixed approach (e.g. ODUflex CBR and 510 ODUflex packet). 512 For example, advertising ODU0 as MIN LSP bandwidth and ODU4 as MAX 513 LSP bandwidth it is not possible to state whether the advertised link 514 supports ODU4 and ODUflex or ODU4, ODU3, ODU2, ODU1, ODU0 and 515 ODUflex. Such ambiguity is not present in SDH networks where the 516 hierarchy is implicit and flexible containers like ODUFlex do not 517 exist. The issue could be resolved by declaring 1 ISCD for each 518 signal type actually supported by the link. 520 Supposing for example to have an equivalent ODU2 unreserved bandwidth 521 in a TE-link (with bundling capability) distributed on 4 ODU1, it 522 would be advertised via the ISCD in this way: 524 MAX LSP Bw: ODU1 526 MIN LSP Bw: ODU1 528 - Maximum Reservable Bandwidth (of the bundle) set to ODU2 530 - Unreserved Bandwidth (of the bundle) set to ODU2 532 In conclusion, the routing extensions defined in [RFC4203] and 533 [RFC5307] require a different ISCD per signal type in order to 534 advertise each supported container. This motivates attempting to 535 look for a more optimized solution, without proliferations of the 536 number of ISCD advertised. 538 Per [RFC2328], OSPF messages are directly encapsulated in IP 539 datagrams and depend on IP fragmentation when transmitting packets 540 larger than the network MTU. [RFC2328] recommends that "IP 541 fragmentation should be avoided whenever possible." This 542 recommendation further constraints solutions as OSPF does not support 543 any generic mechanism to fragment OSPF LSAs. Even when used in IP 544 environments IS-IS [RFC1195], does not support message sizes larger 545 than a link's maximum frame size. 547 With respect to link bundling [RFC4201], the utilization of the ISCD 548 as it is, would not allow precise advertising of spatial bandwidth 549 allocation information unless using only one component link per TE 550 link. 552 On the other hand, from a signaling point of view, [RFC4328] 553 describes GMPLS signaling extensions to support the control for pre- 554 G.709-2012 OTNs. However, [RFC4328] needs to be updated because it 555 does not provide the means to signal all the new signal types and 556 related mapping and multiplexing functionalities. 558 6. Bit rate and tolerance 560 In the current traffic parameters signaling, bit rate and tolerance 561 are implicitly defined by the signal type. ODUflex CBR and Packet 562 can have variable bit rates(please refer to [OTN-FWK] table 2); hence 563 signaling traffic parameters need to be upgraded. With respect to 564 tolerance there is no need to upgrade GMPLS protocols as a fixed 565 value (+/-100 ppm or +/-20ppm depending on the signal type) is 566 defined for each signal type. 568 7. Unreserved Resources 570 Unreserved resources need to be advertised per priority and per 571 signal type in order to allow the correct functioning of the 572 restoration process. [RFC4203] only allows advertising unreserved 573 resources per priority, this leads not to know how many LSPs of a 574 specific signal type can be restored. As example it is possible to 575 consider the scenario depicted in the following figure. 577 +------+ component link 1 +------+ 578 | +------------------+ | 579 | | component link 2 | | 580 | N1 +------------------+ N2 | 581 | | component link 3 | | 582 | +------------------+ | 583 +------+ +---+--+ 585 Figure 7: Concurrent path computation 587 Consider the case where a TE link is composed of 3 ODU3 component 588 links with 32TSs available on the first one, 24TSs on the second, 589 24TSs on the third and supporting ODU2 and ODU3 signal types. The 590 node would advertise a TE link unreserved bandwidth equal to 80 TSs 591 and a MAX LSP bandwidth equal to 32 TSs. In case of restoration the 592 network could try to restore 2 ODU3 (64TSs) in such TE-link while 593 only a single ODU3 can be set up and a crank-back would be 594 originated. In more complex network scenarios the number of crank- 595 backs can be much higher. 597 8. Maximum LSP Bandwidth 599 Maximum LSP bandwidth is currently advertised in the common part of 600 the ISCD and advertised per priority, while in OTN networks it is 601 only required for ODUflex advertising. This leads to a significant 602 waste of bits inside each LSA. 604 9. Distinction between terminating and switching capability 606 The capability advertised by an interface needs further distinction 607 in order to separate termination and switching capabilities. Due to 608 internal constraints and/or limitations, the type of signal being 609 advertised by an interface could be just switched (i.e. forwarded to 610 switching matrix without multiplexing/demultiplexing actions), just 611 terminated (demultiplexed) or both. The following figures help 612 explaining the switching and terminating capabilities. 614 MATRIX LINE INTERFACE 615 +-----------------+ +-----------------+ 616 | +-------+ | ODU2 | | 617 ----->| ODU-2 |----|----------|--------\ | 618 | +-------+ | | +----+ | 619 | | | \__/ | 620 | | | \/ | 621 | +-------+ | ODU3 | | ODU3 | 622 ----->| ODU-3 |----|----------|------\ | | 623 | +-------+ | | \ | | 624 | | | \| | 625 | | | +----+ | 626 | | | \__/ | 627 | | | \/ | 628 | | | ---------> OTU-3 629 +-----------------+ +-----------------+ 631 Figure 8: Switching and Terminating capabilities 633 The figure in the example shows a line interface able to: 635 - Multiplex an ODU2 coming from the switching matrix into and ODU3 636 and map it into an OTU3 638 - Map an ODU3 coming from the switching matrix into an OTU3 640 In this case the interface bandwidth advertised is ODU2 with 641 switching capability and ODU3 with both switching and terminating 642 capabilities. 644 This piece of information needs to be advertised together with the 645 related unreserved bandwidth and signal type. As a consequence 646 signaling must have the possibility to setup an LSP allowing the 647 local selection of resources consistent with the limitations 648 considered during the path computation. 650 In figures 9 and 10 there are two examples of the need of 651 termination/switching capability differentiation. In both examples 652 all nodes only support single-stage capability. Figure 9 represents 653 a scenario in which a failure on link B-C forces node A to calculate 654 another ODU2 LSP path carrying ODU0 service along the nodes B-E-D. 655 As node D is a single stage capable node, it is able to extract ODU0 656 service only from ODU2 interface. Node A has to know that from E to 657 D exists an available OTU2 link from which node D can extract the 658 ODU0 service. This information is required in order to avoid that 659 the OTU3 link is considered in the path computation. 661 ODU0 transparently transported 662 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 663 | ODU2 LSP Carrying ODU0 service | 664 | |'''''''''''''''''''''''''''''''''''''''''''| | 665 | | | | 666 | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | 667 ODU0 | | Link | | Link | | Link | | ODU0 668 ---->| A |_________| B |_________| C |_________| D |----> 669 | | | | | | | | 670 +-----+ +--+--+ +-----+ ++--+-+ 671 | | | 672 OTU3| | | 673 Link| +-----+__________________| | 674 | | | OTU3 Link | 675 |____| E | | 676 | |_____________________| 677 +-----+ OTU2 Link 679 Figure 9: Switching and Terminating capabilities - Example 1 681 Figure 7 addresses the scenario in which the restoration of the ODU2 682 LSP (ABCD) is required. The two bundled component links between B 683 and E could be used, but the ODU2 over the OTU2 component link can 684 only be terminated and not switched. This implies that it cannot be 685 used to restore the ODU2 LSP (ABCD). However such ODU2 unreserved 686 bandwidth must be advertised since it can be used for a different 687 ODU2 LSP terminating on E, e.g. (FBE). Node A has to know that the 688 ODU2 capability on the OTU2 link can only be terminated and that the 689 restoration of (ABCD) can only be performed using the ODU2 bandwidth 690 available on the OTU3 link. 692 ODU0 transparently transported 693 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 694 | ODU2 LSP Carrying ODU0 service | 695 | |'''''''''''''''''''''''''''''''''''''''''''| | 696 | | | | 697 | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | 698 ODU0 | | Link | | Link | | Link | | ODU0 699 ---->| A |_________| B |_________| C |_________| D |----> 700 | | | | | | | | 701 +-----+ ++-+-++ +-----+ +--+--+ 702 | | | | 703 OTU2| | | | 704 +-----+ Link| | | OTU3 +-----+ | 705 | | | | | Link | | | 706 | F |_______| | |___________| E |___________| 707 | | |_____________| | OTU2 Link 708 +-----+ OTU2 Link +-----+ 710 Figure 10: Switching and Terminating capabilities - Example 2 712 The issue shown above is analyzed in an OTN context but it is a 713 general technology independent GMPLS limitation. 715 10. Priority Support 717 [RFC4202] defines 8 priorities for resource availability and usage. 718 All of them have to be advertised independently on the number of 719 priorities supported by the implementation. Considering that the 720 advertisement of all the different supported signal types will 721 originate large LSAs, it is advised to advertise only the information 722 related to the really supported priorities. 724 11. Multi-stage multiplexing 726 With reference to the [OTN-FWK], introduction of multi-stage 727 multiplexing implies the advertisement of cascaded adaptation 728 capabilities together with the matrix access constraints. The 729 structure defined by IETF for the advertisement of adaptation 730 capabilities is ISCD/IACD as in [RFC4202] and [RFC5339]. 732 With respect to routing, please note that in case of multi stage 733 multiplexing hierarchy (e.g. ODU1->ODU2->ODU3), not only the ODUk/ 734 OTUk bandwidth (ODU3) and service layer bandwidth (ODU1) are needed, 735 but also the intermediate one (ODU2). This is a typical case of 736 spatial allocation problem. 738 Suppose in this scenario to have the following advertisement: 740 Hierarchy: ODU1->ODU2->ODU3 742 Number of ODU1==5 744 The number of ODU1 suggests that it is possible to have an ODU2 FA, 745 but it depends on the spatial allocation of such ODU1s. 747 It is possible that 2 links are bundled together and 3 748 ODU1->ODU2->ODU3 are available on a component link and 2 on the other 749 one, in such a case no ODU2 FA could be set up. The advertisement of 750 the ODU2 is needed because in case of ODU1 spatial allocation (3+2), 751 the ODU2 available bandwidth would be 0 (no ODU2 FA can be created), 752 while in case of ODU1 spatial allocation (4+1) the ODU2 available 753 bandwidth would be 1 (1 ODU2 FA can be created). 755 What said above implies augmenting both the ISCD and the IACD. 757 12. Generalized Label 759 The ODUk label format defined in [RFC4328] could be updated to 760 support new signal types defined in [G.709-2012] but it would be 761 difficult to further enhance it to support possible new signal types. 763 Furthermore such label format may have scalability issues due to the 764 high number of labels needed when signaling large LSPs. For example, 765 when an ODU3 is mapped into an ODU4 with 1.25Gbps tributary slots, it 766 would require the utilization of thirty-one labels (31*4*8=992 bits) 767 to be allocated while an ODUflex into an ODU4 may need up to eighty 768 labels (80*4*8=2560 bits). 770 A new flexible and scalable ODUk label format needs to be defined. 772 13. Security Considerations 774 This document provides an evaluation of OTN requirements against 775 actual routing [RFC4202], [RFC4203] and [RFC5307] and signaling 776 mechanism [RFC3471], [RFC3473] and [RFC4328]in GMPLS. 778 New types of information to be conveyed regard OTN containers and 779 hierarchies and from a security standpoint this memo does not 780 introduce further risks with respect to the information that can be 781 currently conveyed via GMPLS protocols. For a general discussion on 782 MPLS and GMPLS-related security issues, see the MPLS/GMPLS security 783 framework [RFC5920]. 785 14. IANA Considerations 787 This informational document does not make any requests for IANA 788 action. 790 15. Contributors 792 Jonathan Sadler, Tellabs 794 EMail: jonathan.sadler@tellabs.com 796 John Drake, Juniper 798 EMail: jdrake@juniper.net 800 Francesco Fondelli 802 Ericsson 804 Via Moruzzi 1 806 Pisa - 56100 808 Email: francesco.fondelli@ericsson.com 810 16. Acknowledgements 812 The authors would like to thank Lou Berger, Eve Varma and Sergio 813 Lanzone for their precious collaboration and review. 815 17. References 817 17.1. Normative References 819 [G.709-2012] 820 ITU-T, "Rec G.709, version 4", approved by ITU-T in 2012. 822 [G.798] ITU-T, "Revised version of G.798 Characteristics of 823 optical transport network hierarchy equipment functional 824 blocks", consented by ITU-T on December 2012. 826 [G.872] ITU-T, "Revised version of G.872: Architecture of optical 827 transport networks for consent", consented by ITU-T on 828 December 2012. 830 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 831 dual environments", RFC 1195, December 1990. 833 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 834 (GMPLS) Signaling Functional Description", RFC 3471, 835 January 2003. 837 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 838 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 839 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 841 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 842 Support of Generalized Multi-Protocol Label Switching 843 (GMPLS)", RFC 4202, October 2005. 845 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 846 of Generalized Multi-Protocol Label Switching (GMPLS)", 847 RFC 4203, October 2005. 849 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 850 Switching (GMPLS) Signaling Extensions for G.709 Optical 851 Transport Networks Control", RFC 4328, January 2006. 853 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 854 of Generalized Multi-Protocol Label Switching (GMPLS)", 855 RFC 5307, October 2008. 857 [RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing 858 GMPLS Protocols against Multi-Layer and Multi-Region 859 Networks (MLN/MRN)", RFC 5339, September 2008. 861 17.2. Informative References 863 [OTN-FWK] F.Zhang, D.Li, H.Li, S.Belotti, D.Ceccarelli, "Framework 864 for GMPLS and PCE Control of G.709 Optical Transport 865 Networks", work in 866 progress draft-ietf-ccamp-gmpls-g709-framework-14, August 867 2013. 869 [OTN-OSPF] 870 D.Ceccarelli,D.Caviglia,F.Zhang,D.Li,Y.Xu,P.Grandi,S.Belot 871 ti, "Traffic Engineering Extensions to OSPF for 872 Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN 873 Networks", work in 874 progress draft-ietf-ccamp-gmpls-ospf-g709v3-07, June 2013. 876 [OTN-RSVP] 877 F.Zhang, G.Zhang, S.Belotti, D.Ceccarelli, K.Pithewan, 878 "Generalized Multi-Protocol Label Switching (GMPLS) 879 Signaling Extensions for the evolving G.709 Optical 880 Transport Networks Control, work in progress 881 draft-ietf-ccamp-gmpls-signaling-g709v3-11", August 2012. 883 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 885 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 886 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 888 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 889 Networks", RFC 5920, July 2010. 891 Authors' Addresses 893 Sergio Belotti (editor) 894 Alcatel-Lucent 895 Via Trento, 30 896 Vimercate 897 Italy 899 Email: sergio.belotti@alcatel-lucent.com 900 Pietro Vittorio Grandi 901 Alcatel-Lucent 902 Via Trento, 30 903 Vimercate 904 Italy 906 Email: pietro_vittorio.grandi@alcatel-lucent.com 908 Daniele Ceccarelli (editor) 909 Ericsson 910 Via A. Negrone 1/A 911 Genova - Sestri Ponente 912 Italy 914 Email: daniele.ceccarelli@ericsson.com 916 Diego Caviglia 917 Ericsson 918 Via A. Negrone 1/A 919 Genova - Sestri Ponente 920 Italy 922 Email: diego.caviglia@ericsson.com 924 Fatai Zhang 925 Huawei Technologies 926 F3-5-B R&D Center, Huawei Base 927 Shenzhen 518129 P.R.China Bantian, Longgang District 928 Phone: +86-755-28972912 930 Email: zhangfatai@huawei.com 932 Dan Li 933 Huawei Technologies 934 F3-5-B R&D Center, Huawei Base 935 Shenzhen 518129 P.R.China Bantian, Longgang District 936 Phone: +86-755-28973237 938 Email: danli@huawei.com