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