idnits 2.17.1 draft-ietf-ccamp-otn-g709-info-model-08.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 (May 29, 2013) is 3957 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3630' is defined on line 831, but no explicit reference was found in the text == Unused Reference: 'RFC5250' is defined on line 853, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-ccamp-gmpls-ospf-g709v3-04 == Outdated reference: A later version (-15) exists of draft-ietf-ccamp-gmpls-g709-framework-11 == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-gmpls-signaling-g709v3-05 Summary: 1 error (**), 0 flaws (~~), 6 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: November 30, 2013 D. Ceccarelli, Ed. 6 D. Caviglia 7 Ericsson 8 F. Zhang 9 D. Li 10 Huawei Technologies 11 May 29, 2013 13 Evaluation of existing GMPLS encoding against G.709v3 Optical Transport 14 Networks (OTN) 15 draft-ietf-ccamp-otn-g709-info-model-08 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 methods 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 November 30, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. G.709 Mapping and Multiplexing Capabilities . . . . . . . . . 3 63 3. Tributary Slot Granularity . . . . . . . . . . . . . . . . . . 6 64 3.1. Data Plane Considerations . . . . . . . . . . . . . . . . 6 65 3.1.1. Payload Type and TSG 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 . . . . . . . . . . . . . . . . . . . 18 78 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 79 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 81 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 17.1. Normative References . . . . . . . . . . . . . . . . . . . 20 83 17.2. Informative References . . . . . . . . . . . . . . . . . . 21 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 GMPLS[RFC3945] extends MPLS to include Layer-2 Switching (L2SC), 89 Time-Division Multiplexing (e.g., SONET/SDH, PDH, and OTN), 90 Wavelength (OCh, Lambdas) Switching and Spatial Switching (e.g. 91 incoming port or fiber to outgoing port or fiber). 93 This document provides an evaluation of GMPLS signaling and routing 94 processes against G.709 [G.709-2012] requirements. 96 OSPF-TE and RSVP-TE requirements are defined in [OTN-FWK], while 97 protocol extensions are defined in [OTN-OSPF] and [OTN-RSVP]. 99 2. G.709 Mapping and Multiplexing Capabilities 101 The digital OTN layered structure is comprised of digital path layer 102 (ODU) and digital section layer (OTU). An OTU (Optical Transport 103 Unit) section layer supports one ODU path layer as client and 104 provides monitoring capability for the OCh. An ODU path layer may 105 transport a heterogeneous assembly of ODU clients. Some types of 106 ODUs (i.e., ODU1, ODU2, ODU3, ODU4) may assume either a client or 107 server role within the context of a particular networking domain. 108 ITU-T G.872 recommendation [G.872] provides two tables defining 109 mapping and multiplexing capabilities of OTNs, which are reported 110 below. 112 +--------------------+--------------------+ 113 | ODU client | OTU server | 114 +--------------------+--------------------+ 115 | ODU 0 | - | 116 +--------------------+--------------------+ 117 | ODU 1 | OTU 1 | 118 +--------------------+--------------------+ 119 | ODU 2 | OTU 2 | 120 +--------------------+--------------------+ 121 | ODU 2e | - | 122 +--------------------+--------------------+ 123 | ODU 3 | OTU 3 | 124 +--------------------+--------------------+ 125 | ODU 4 | OTU 4 | 126 +--------------------+--------------------+ 127 | ODU flex | - | 128 +--------------------+--------------------+ 130 Figure 1: OTN mapping capability 132 +=================================+=========================+ 133 | ODU client | ODU server | 134 +---------------------------------+-------------------------+ 135 | 1.25 Gbps client | | 136 +---------------------------------+ ODU 0 | 137 | - | | 138 +=================================+=========================+ 139 | 2.5 Gbps client | | 140 +---------------------------------+ ODU 1 | 141 | ODU 0 | | 142 +=================================+=========================+ 143 | 10 Gbps client | | 144 +---------------------------------+ ODU 2 | 145 | ODU0,ODU1,ODUflex | | 146 +=================================+=========================+ 147 | 10.3125 Gbps client | | 148 +---------------------------------+ ODU 2e | 149 | - | | 150 +=================================+=========================+ 151 | 40 Gbps client | | 152 +---------------------------------+ ODU 3 | 153 | ODU0,ODU1,ODU2,ODU2e,ODUflex | | 154 +=================================+=========================+ 155 | 100 Gbps client | | 156 +---------------------------------+ ODU 4 | 157 |ODU0,ODU1,ODU2,ODU2e,ODU3,ODUflex| | 158 +=================================+=========================+ 159 |CBR clients from greater than | | 160 |2.5 Gbit/s to 100 Gbit/s: or | | 161 |GFP-F mapped packet clients from | ODUflex | 162 |1.25 Gbit/s to 100 Gbit/s. | | 163 +---------------------------------+ | 164 | - | | 165 +=================================+=========================+ 167 Figure 2: OTN multiplexing capability 169 How an ODUk connection service is transported within an operator 170 network is governed by operator policy. For example, the ODUk 171 connection service might be transported over an ODUk path over an 172 OTUk section, with the path and section being at the same rate as 173 that of the connection service (see Table 1). In this case, an 174 entire lambda of capacity is consumed in transporting the ODUk 175 connection service. On the other hand, the operator might exploit 176 different multiplexing capabilities in the network to improve 177 infrastructure efficiencies within any given networking domain. In 178 this case, ODUk multiplexing may be performed prior to transport over 179 various rate ODU servers (as per Table 2) over associated OTU 180 sections. 182 From the perspective of multiplexing relationships, a given ODUk may 183 play different roles as it traverses various networking domains. 185 As detailed in [OTN-FWK], client ODUk connection services can be 186 transported over: 188 o Case A) one or more wavelength sub-networks connected by optical 189 links or 191 o Case B) one or more ODU links (having sub-lambda and/or lambda 192 bandwidth granularity) 194 o Case C) a mix of ODU links and wavelength sub-networks. 196 This document considers the TE information needed for ODU path 197 computation and parameters needed to be signaled for LSP setup. 199 The following sections list and analyze, for each type of data that 200 needs to be advertised and signaled, what is already there in GMPLS 201 and what is missing. 203 3. Tributary Slot Granularity 205 ITU-T recommendation defines two types of Tributary Slot (TS) 206 granularity. This TS granularity is defined per layer, meaning that 207 both ends of a link can select proper TS granularity differently for 208 each supported layer, based on the rules below: 210 - If both ends of a link are new cards supporting both 1.25Gbps TS 211 and 2.5Gbps TS, then the link will work with 1.25Gbps TS. 213 - If one end is a new card supporting both the 1.25Gbps and 214 2,5Gbps TS, and the other end is an old card supporting just the 215 2.5Gbps TS, the link will work with 2.5Gbps TS. 217 3.1. Data Plane Considerations 219 3.1.1. Payload Type and TSG relationship 221 As defined in G.709-2012 an ODUk container consist of an Optical 222 Payload Unit (OPUk) plus a specific ODUk Overhead (OH). OPUk OH 223 information is added to the OPUk information payload to create an 224 OPUk. It includes information to support the adaptation of client 225 signals. Within the OPUk overhead there is the payload structure 226 identifier (PSI) that includes the payload type (PT). The payload 227 type (PT) is used to indicate the composition of the OPUk signal. 228 When an ODUj signal is multiplexed into an ODUk, the ODUj signal is 229 first extended with frame alignment overhead and then mapped into an 230 Optical channel Data Tributary Unit (ODTU). Two different types of 231 ODTU are defined: 233 - ODTUjk ((j,k) = {(0,1), (1,2), (1,3), (2,3)}; ODTU01, ODTU12, 234 ODTU13 and ODTU23) in which an ODUj signal is mapped via the 235 Asynchronous Mapping Procedure (AMP), defined in clause 19.5 of 236 G.709-2012. 238 - ODTUk.ts ((k,ts) = (2,1..8), (3,1..32), (4,1..80)) in which a 239 lower order ODU (ODU0, ODU1, ODU2, ODU2e, ODU3, ODUflex) signal is 240 mapped via the Generic Mapping Procedure (GMP), defined in clause 241 19.6 of G.709-2012. 243 G.709-2012 introduces also a logical entity, called Optical Data 244 Tributary Unit Group (ODTUGk), characterizing the multiplexing of the 245 various ODTU. The ODTUGk is then mapped into OPUK. ODTUjk and 246 ODTUk.ts signals are directly time-division multiplexed into the 247 tributary slots of an HO OPUk. 249 When PT is assuming value 0x20 or 0x21,together with OPUk type (K= 250 1,2,3,4), it is used to discriminate two different ODU multiplex 251 structure ODTUGx : 253 - Value 0x20: supporting ODTUjk only, 255 - Value 0x21: supporting ODTUk.ts or ODTUk.ts and ODTUjk. 257 The discrimination is needed for OPUk with K =2 or 3, since OPU2 and 258 OPU3 are able to support both the different ODU multiplex structures. 259 For OPU4 and OPU1, only one type of ODTUG is supported: ODTUG4 with 260 PT=0x21 and ODTUG1 with PT=0x20. (see table Figure 6).The 261 relationship between PT and TS granularity, is in the fact that the 262 two different ODTUGk discriminated by PT and OPUk are characterized 263 by two different TS granularities of the related OPUk, the former at 264 2.5 Gbps, the latter at 1.25Gbps. 266 In order to complete the picture, in the PSI OH there is also the 267 Multiplex Structure Identifier (MSI) that provides the information on 268 which tributary slots the different ODTUjk or ODTUk.ts are mapped 269 into the related OPUk. The following figure shows how the client 270 traffic is multiplexed till the OPUk layer. 272 +--------+ +------------+ 273 +----+ | !------| ODTUjk |-----Client 274 | | | ODTUGk | +-----.------+ 275 | |-----| PT=0x21| . 276 | | | | +-----.------+ 277 | | | |------| ODTUk.TS |-----Client 278 |OPUk| +--------+ +------------+ 279 | | 280 | | +--------+ +------------+ 281 | | | |------| ODTUjk |-----Client 282 | |-----| | +-----.------+ 283 +----+ | ODTUGk | . 284 | PT=0x20| +-----.------+ 285 | |------| ODTUjk |-----Client 286 +--------+ +------------+ 288 Figure 3: OTN client multiplexing 290 3.1.2. Fall-back procedure 292 ITU-T G.798 r[G.798] describes the so called PT=0x21-to-PT=0x20 293 interworking process that explains how two nodes with interfaces with 294 different PayloadType, and hence different TS granularity (1.25Gbps 295 vs. 2.5Gbps), can be coordinated so to permit the equipment with 1.25 296 TS granularity to adapt his TS allocation accordingly to the 297 different TS granularity (2.5Gbps) of a neighbor. 299 Therefore, in order to let the NE change TS granularity accordingly 300 to the neighbor requirements, the AUTOpayloadtype needs to be set. 301 When both the neighbors (link or trail) have been configured as 302 structured, the payload type received in the overhead is compared to 303 the transmitted PT. If they are different and the transmitted 304 PT=0x21, the node must fallback to PT=0x20. In this case the 305 fallback process makes the system self-consistent and the only reason 306 for signaling the TS granularity is to provide the correct label 307 (i.e. label for PT=0x21 has twice the TS number of PT=0x20). On the 308 other side, if the AUTOpayloadtype is not configured, the RSVP-TE 309 consequent actions in case of TS mismatch need to be defined. 311 3.2. Control Plane considerations 313 When setting up an ODUj over an ODUk, it is possible to identify two 314 types of TSG, the server and the client one. The server TSG is used 315 to map an end to end ODUj onto a server ODUk LSP or links. This 316 parameter cannot be influenced in any way from the ODUj LSP: ODUj LSP 317 will be mapped on tributary slots available on the different links/ 318 ODUk LSPs. When setting up an ODUj at a given rate, the fact that it 319 is carried over a path composed by links/Forwarding Adjacencies(FAs) 320 structured with 1.25Gbps or 2.5Gbps TS size is completely transparent 321 to the end to end ODUj. 323 On the other side the client TSG is the tributary slot size that is 324 exported towards the client layer. The client TSG information is one 325 of the parameters needed to correctly select the adaptation towards 326 the client layers at the end nodes and this is the only thing that 327 the ODUj has to guarantee. 329 In figure 4 an example of client and server TSG utilization in a 330 scenario with mixed [RFC4328] OTN and [G.709-2012] OTN interfaces is 331 shown. 333 ODU1-LSP 334 ......................................... 335 TSG-C| |TSG-C 336 1.25| ODU2-H-LSP |1.25 337 +------------X--------------------------+ 338 | TSG-S| |TSG-S 339 | 2.5| |2.5 340 | | ODU3-H-LSP | 341 | |------------X-------------| 342 | | | 343 +--+--+ +--+--+ +---+-+ 344 | | | | +-+ +-+ | | 345 | A +------+ B +-----+ +***+ +-----+ Z | 346 | V.3 | OTU2 | V.1 |OTU3 +-+ +-+ OTU3| V.3 | 347 +-----+ +-----+ +-----+ 349 ... Service LSP 350 --- H-LSP 352 Figure 4: Client-Server TSG example 354 In this scenario, an ODU3 LSP is setup from node B to Z. Node B has 355 an old interface able to support 2.5 TSG, hence only client TSG equal 356 to 2.5Gbps can be exported to ODU3 H-LSP possible clients. An ODU2 357 LSP is setup from node A to node Z with client TSG 1.25 signaled and 358 exported towards clients. The ODU2 LSP is carried by ODU3 H-LSP from 359 B to Z. Due to the limitations of old node B interface, the ODU2 LSP 360 is mapped with 2.5Gbps TSG over the ODU3 H-LSP. Then an ODU1 LSP is 361 setup from A to Z, carried by the ODU2 H-LSP and mapped over it using 362 a 1.25Gbps TSG. 364 What is shown in the example is that the TSG processing is a per 365 layer issue: even if the ODU3 H-LSP is created with TSG client at 366 2.5Gbps, the ODU2 H-LSP must guarantee a 1.25Gbps TSG client. ODU3 367 H-LSP is eligible from ODU2 LSP perspective since from the routing it 368 is known that this ODU3 interface at node Z, supports an ODU2 369 termination exporting a TSG 1.25/2.5. 371 The TSG information is needed in the routing protocol as the ingress 372 node (A in the previous example) needs to know if the interfaces at 373 the last hop can support the required TSG. In case they cannot, A 374 will compute an alternate path from itself to Z (see figure 4). 376 Moreover, also TSG information needs to be signaled. Consider as 377 example the setup of an ODU3 forwarding adjacency that is going to 378 carry an ODU0, hence the support of 1.25 GBps TS is needed. The 379 information related to the TSG has to be carried in the signaling to 380 permit node C (see figure 5) choose the right one among the different 381 interfaces (with different TSGs) towards D. In case the full ERO is 382 provided in the signaling with explicit interface declaration, there 383 is no need for C to choose the right interface towards D as it has 384 been already decided by the ingress node or by the PCE. 386 ODU3 387 <----------------------> 389 ODU0 390 <--------------------------------------> 391 | | 392 +--------+ +--------+ +--------+ +--------+ 393 | | | | | | 1.25 | | 394 | Node | | Node | | Node +------+ Node | 395 | A +------+ B +------+ C | ODU3 | D | 396 | | ODU3 | | ODU3 | +------+ | 397 +--------+ 1.25 +--------+ 2.5 +--------+ 2.5 +--------+ 399 Figure 5: TSG in signaling 401 In case an ODUk FA_LSP needs to be set up nesting another ODUj (as 402 depicted in figure 4), there might be the need to know the hierarchy 403 of nested LSPs in addition to TSG, to permit the penultimate hop 404 (i.e. C) choosing the correct interface towards the egress node or 405 any intermediate node (i.e. B) choosing the right path when 406 performing ERO expansion. This is not needed in case we allow 407 bundling only component links with homogeneous hierarchies. In case 408 of specific implementation not specifying in the ERO the last hop 409 interface, crank-back can be a solution. 411 In a multi-stage multiplexing environment any layer can have a 412 different TSG structure, e.g. in a multiplexing hierarchy like 413 ODU0->ODU2->ODU3, the ODU3 can be structured at TSG=2.5 in order to 414 support an ODU2 connection, but this ODU2 connection can be a tunnel 415 for ODU0, and hence structured with 1.25 TSG. Therefore any 416 multiplexing level has to advertise his TSG capabilities in order to 417 allow a correct path computation by the end nodes (both of the ODUk 418 trail and of the H-LSP/FA). 420 The following table shows the different mapping possibilities 421 depending on the TSG types. The client types are shown in the left 422 column, while the different OPUk server and related TSGs are listed 423 in the top row. The table also shows the relationship between the 424 TSG and the payload type. 426 +------------------------------------------------+ 427 | 2.5G TS || 1.25G TS | 428 | OPU2 | OPU3 || OPU1 | OPU2 | OPU3 | OPU4 | 429 +-------+------------------------------------------------+ 430 | | - | - || AMP | GMP | GMP | GMP | 431 | ODU0 | | ||PT=0x20|PT=0x21|PT=0x21|PT=0x21| 432 +-------+------------------------------------------------+ 433 | | AMP | AMP || - | AMP | AMP | GMP | 434 | ODU1 |PT=0x20|PT=0x20|| |PT=0x21|PT=0x21|PT=0x21| 435 +-------+------------------------------------------------+ 436 | | - | AMP || - | - | AMP | GMP | 437 | ODU2 | |PT=0x20|| | |PT=0x21|PT=0x21| 438 +-------+------------------------------------------------+ 439 | | - | - || - | - | GMP | GMP | 440 | ODU2e | | || | |PT=0x21|PT=0x21| 441 +-------+------------------------------------------------+ 442 | | - | - || - | - | - | GMP | 443 | ODU3 | | || | | |PT=0x21| 444 +-------+------------------------------------------------+ 445 | | - | - || - | GMP | GMP | GMP | 446 | ODUfl | | || |PT=0x21|PT=0x21|PT=0x21| 447 +-------+------------------------------------------------+ 449 Figure 6: ODUj into OPUk mapping types (Source: Table 7-10 [G.709- 450 2012]) 452 The signaled TSGs information is not enough to have a complete choice 453 since the penultimate hop node (or any intermediate node performing 454 ERO expansion) has to distinguish between interfaces with the same 455 TSG (e.g. 1.25Gbps) whether the interface is able to support the 456 right hierarchy, i.e. it is possible to have two interfaces both at 457 1.25 TSG but only one is supporting ODU0. 459 Specific information could be defined in order to carry the 460 multiplexing hierarchy and adaptation information (i.e. TSG/PT, AMP/ 461 GMP) so to have a more precise choice capability. In this way, when 462 the penultimate node (or the intermediate node performing ERO 463 expansion) receives such object, together with the Traffic Parameters 464 Object, it is allowed to choose the correct interface towards the 465 egress node. 467 In conclusion both routing and signaling needs to be extended to 468 appropriately represent the TSG/PT information. Routing needs to 469 represent a link's TSG and PT capabilities as well as the supported 470 multiplexing hierarchy. Signaling needs to represent the TSG/PT and 471 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, [RFC4203] allows advertising [RFC4328] 494 interfaces (single TS type) without the capability of providing 495 precise information about bandwidth specific allocation. For 496 example, in case of link bundling, dividing the unreserved bandwidth 497 by the MAX LSP bandwidth it is not possible to know the exact number 498 of LSPs at MAX LSP bandwidth size that can be set up. (see example 499 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] only allow advertising 507 signal types with fixed bandwidth and implicit hierarchy (e.g. SDH/ 508 SONET networks) or variable bandwidth with no hierarchy (e.g. packet 509 switching networks) but do not provide the means for advertising 510 networks with mixed approach (e.g. ODUflex CBR and 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 OSPF-TE extensions defined in [RFC4203] require a 533 different ISCD per signal type in order to advertise each supported 534 container. This motivates attempting to look for a more optimized 535 solution, without proliferations of the number of ISCD advertised. 536 Per [RFC2328], OSPF messages are directly encapsulated in IP 537 datagrams and depend on IP fragmentation when transmitting packets 538 larger than the network MTU. [RFC2328] recommends that "IP 539 fragmentation should be avoided whenever possible." This 540 recommendation further constraints solutions as OSPF does not support 541 any generic mechanism to fragment OSPF LSAs. 543 With respect to link bundling [RFC4201], the utilization of the ISCD 544 as it is, would not allow precise advertising of spatial bandwidth 545 allocation information unless using only one component link per TE 546 link. 548 On the other hand, from a signaling point of view, [RFC4328] 549 describes GMPLS signaling extensions to support the control for pre- 550 G.709-2012 OTNs. However, [RFC4328] needs to be updated because it 551 does not provide the means to signal all the new signal types and 552 related mapping and multiplexing functionalities. 554 6. Bit rate and tolerance 556 In the current traffic parameters signaling, bit rate and tolerance 557 are implicitly defined by the signal type. ODUflex CBR and Packet 558 can have variable bit rates(please refer to [OTN-FWK] table 2); hence 559 signaling traffic parameters need to be upgraded. With respect to 560 the tolerance there is no need to upgrade GMPLS protocols as a fixed 561 value (+/-100 ppm or +/-20ppm depending on the signal type) is 562 defined for each signal type. 564 7. Unreserved Resources 566 Unreserved resources need to be advertised per priority and per 567 signal type in order to allow the correct functioning of the 568 restoration process. [RFC4203] only allows advertising unreserved 569 resources per priority, this leads not to know how many LSPs of a 570 specific signal type can be restored. As example it is possible to 571 consider the scenario depicted in the following figure. 573 +------+ component link 1 +------+ 574 | +------------------+ | 575 | | component link 2 | | 576 | N1 +------------------+ N2 | 577 | | component link 3 | | 578 | +------------------+ | 579 +------+ +---+--+ 581 Figure 7: Concurrent path computation 583 Consider the case where a TE link is composed of 3 ODU3 component 584 links with 32TSs available on the first one, 24TSs on the second, 585 24TSs on the third and supporting ODU2 and ODU3 signal types. The 586 node would advertise a TE link unreserved bandwidth equal to 80 TSs 587 and a MAX LSP bandwidth equal to 32 TSs. In case of restoration the 588 network could try to restore 2 ODU3 (64TSs) in such TE-link while 589 only a single ODU3 can be set up and a crank-back would be 590 originated. In more complex network scenarios the number of crank- 591 backs can be much higher. 593 8. Maximum LSP Bandwidth 595 Maximum LSP bandwidth is currently advertised in the common part of 596 the ISCD and advertised per priority, while in OTN networks it is 597 only required for ODUflex advertising. This leads to a significant 598 waste of bits inside each LSA. 600 9. Distinction between terminating and switching capability 602 The capability advertised by an interface needs further distinction 603 in order to separate termination and switching capabilities. Due to 604 internal constraints and/or limitations, the type of signal being 605 advertised by an interface could be just switched (i.e. forwarded to 606 switching matrix without multiplexing/demultiplexing actions), just 607 terminated (demultiplexed) or both. The following figures help 608 explaining the switching and terminating capabilities. 610 MATRIX LINE INTERFACE 611 +-----------------+ +-----------------+ 612 | +-------+ | ODU2 | | 613 ----->| ODU-2 |----|----------|--------\ | 614 | +-------+ | | +----+ | 615 | | | \__/ | 616 | | | \/ | 617 | +-------+ | ODU3 | | ODU3 | 618 ----->| ODU-3 |----|----------|------\ | | 619 | +-------+ | | \ | | 620 | | | \| | 621 | | | +----+ | 622 | | | \__/ | 623 | | | \/ | 624 | | | ---------> OTU-3 625 +-----------------+ +-----------------+ 627 Figure 8: Switching and Terminating capabilities 629 The figure in the example shows a line interface able to: 631 - Multiplex an ODU2 coming from the switching matrix into and ODU3 632 and map it into an OTU3 634 - Map an ODU3 coming from the switching matrix into an OTU3 636 In this case the interface bandwidth advertised is ODU2 with 637 switching capability and ODU3 with both switching and terminating 638 capabilities. 640 This piece of information needs to be advertised together with the 641 related unreserved bandwidth and signal type. As a consequence 642 signaling must have the possibility to setup an LSP allowing the 643 local selection of resources consistent with the limitations 644 considered during the path computation. 646 In figures 9 and 10 there are two examples of the need of 647 termination/switching capability differentiation. In both examples 648 all nodes only support single-stage capability. Figure 9 represents 649 a scenario in which a failure on link B-C forces node A to calculate 650 another ODU2 LSP path carrying ODU0 service along the nodes B-E-D. 651 As node D is a single stage capable node, it is able to extract ODU0 652 service only from ODU2 interface. Node A has to know that from E to 653 D exists an available OTU2 link from which node D can extract the 654 ODU0 service. This information is required in order to avoid that 655 the OTU3 link is considered in the path computation. 657 ODU0 transparently transported 658 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 659 | ODU2 LSP Carrying ODU0 service | 660 | |'''''''''''''''''''''''''''''''''''''''''''| | 661 | | | | 662 | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | 663 ODU0 | | Link | | Link | | Link | | ODU0 664 ---->| A |_________| B |_________| C |_________| D |----> 665 | | | | | | | | 666 +-----+ +--+--+ +-----+ ++--+-+ 667 | | | 668 OTU3| | | 669 Link| +-----+__________________| | 670 | | | OTU3 Link | 671 |____| E | | 672 | |_____________________| 673 +-----+ OTU2 Link 675 Figure 9: Switching and Terminating capabilities - Example 1 677 Figure 7 addresses the scenario in which the restoration of the ODU2 678 LSP (ABCD) is required. The two bundled component links between B 679 and E could be used, but the ODU2 over the OTU2 component link can 680 only be terminated and not switched. This implies that it cannot be 681 used to restore the ODU2 LSP (ABCD). However such ODU2 unreserved 682 bandwidth must be advertised since it can be used for a different 683 ODU2 LSP terminating on E, e.g. (FBE). Node A has to know that the 684 ODU2 capability on the OTU2 link can only be terminated and that the 685 restoration of (ABCD) can only be performed using the ODU2 bandwidth 686 available on the OTU3 link. 688 ODU0 transparently transported 689 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 690 | ODU2 LSP Carrying ODU0 service | 691 | |'''''''''''''''''''''''''''''''''''''''''''| | 692 | | | | 693 | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | 694 ODU0 | | Link | | Link | | Link | | ODU0 695 ---->| A |_________| B |_________| C |_________| D |----> 696 | | | | | | | | 697 +-----+ ++-+-++ +-----+ +--+--+ 698 | | | | 699 OTU2| | | | 700 +-----+ Link| | | OTU3 +-----+ | 701 | | | | | Link | | | 702 | F |_______| | |___________| E |___________| 703 | | |_____________| | OTU2 Link 704 +-----+ OTU2 Link +-----+ 706 Figure 10: Switching and Terminating capabilities - Example 2 708 10. Priority Support 710 The IETF foresees that up to eight priorities must be supported and 711 that all of them have to be advertised independently on the number of 712 priorities supported by the implementation. Considering that the 713 advertisement of all the different supported signal types will 714 originate large LSAs, it is advised to advertise only the information 715 related to the really supported priorities. 717 11. Multi-stage multiplexing 719 With reference to the [OTN-FWK], introduction of multi-stage 720 multiplexing implies the advertisement of cascaded adaptation 721 capabilities together with the matrix access constraints. The 722 structure defined by IETF for the advertisement of adaptation 723 capabilities is ISCD/IACD as in [RFC4202] and [RFC5339]. 724 Modifications to ISCD/IACD, if needed, have to be addressed in the 725 related encoding documents. 727 With respect to the routing, please note that in case of multi stage 728 multiplexing hierarchy (e.g. ODU1->ODU2->ODU3), not only the ODUk/ 729 OTUk bandwidth (ODU3) and service layer bandwidth (ODU1) are needed, 730 but also the intermediate one (ODU2). This is a typical case of 731 spatial allocation problem. 733 Suppose in this scenario to have the following advertisement: 735 Hierarchy: ODU1->ODU2->ODU3 737 Number of ODU1==5 739 The number of ODU1 suggests that it is possible to have an ODU2 FA, 740 but it depends on the spatial allocation of such ODU1s. 742 It is possible that 2 links are bundled together and 3 743 ODU1->ODU2->ODU3 are available on a component link and 2 on the other 744 one, in such a case no ODU2 FA could be set up. The advertisement of 745 the ODU2 is needed because in case of ODU1 spatial allocation (3+2), 746 the ODU2 available bandwidth would be 0 (no ODU2 FA can be created), 747 while in case of ODU1 spatial allocation (4+1) the ODU2 available 748 bandwidth would be 1 (1 ODU2 FA can be created). 750 12. Generalized Label 752 The ODUk label format defined in [RFC4328] could be updated to 753 support new signal types defined in [G.709-2012] but would hardly be 754 further enhanced to support possible new signal types. 756 Furthermore such label format may have scalability issues due to the 757 high number of labels needed when signaling large LSPs. For example, 758 when an ODU3 is mapped into an ODU4 with 1.25G tributary slots, it 759 would require the utilization of thirty-one labels (31*4*8=992 bits) 760 to be allocated while an ODUflex into an ODU4 may need up to eighty 761 labels (80*4*8=2560 bits). 763 A new flexible and scalable ODUk label format needs to be defined. 765 13. Security Considerations 767 This document provides an evaluation of OTN requirements against 768 actual routing [RFC4202] and [RFC4203] and signaling mechanism 770 [RFC3471], [RFC3473] and [RFC4328]in GMPLS. 772 New types of information to be conveyed regard OTN containers and 773 hierarchies and from a security standpoint this memo does not 774 introduce further risks with respect to the information that can be 775 currently conveyed via GMPLS protocols. For a general discussion on 776 MPLS and GMPLS-related security issues, see the MPLS/GMPLS security 777 framework [RFC5920]. 779 14. IANA Considerations 781 This informational document does not make any requests for IANA 782 action. 784 15. Contributors 786 Jonathan Sadler, Tellabs 788 EMail: jonathan.sadler@tellabs.com 790 John Drake, Juniper 792 EMail: jdrake@juniper.net 794 Francesco Fondelli 796 Ericsson 798 Via Moruzzi 1 800 Pisa - 56100 802 Email: francesco.fondelli@ericsson.com 804 16. Acknowledgements 806 The authors would like to thank Lou Berger, Eve Varma and Sergio 807 Lanzone for their precious collaboration and review. 809 17. References 811 17.1. Normative References 813 [OTN-OSPF] 814 D.Ceccarelli,D.Caviglia,F.Zhang,D.Li,Y.Xu,P.Grandi,S.Belot 815 ti, "Traffic Engineering Extensions to OSPF for 816 Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN 817 Networks", work in 818 progress draft-ietf-ccamp-gmpls-ospf-g709v3-04, November 819 2012. 821 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 823 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 824 (GMPLS) Signaling Functional Description", RFC 3471, 825 January 2003. 827 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 828 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 829 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 831 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 832 (TE) Extensions to OSPF Version 2", RFC 3630, 833 September 2003. 835 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 836 (GMPLS) Architecture", RFC 3945, October 2004. 838 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 839 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 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 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 854 OSPF Opaque LSA Option", RFC 5250, July 2008. 856 [RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing 857 GMPLS Protocols against Multi-Layer and Multi-Region 858 Networks (MLN/MRN)", RFC 5339, September 2008. 860 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 861 Networks", RFC 5920, July 2010. 863 17.2. Informative References 865 [G.709-2012] 866 ITU-T, "Rec G.709, version 4", approved by ITU-T in 2012. 868 [G.798] ITU-T, "Revised version of G.798 Characteristics of 869 optical transport network hierarchy equipment functional 870 blocks", consented by ITU-T on December 2012. 872 [G.872] ITU-T, "Revised version of G.872: Architecture of optical 873 transport networks for consent", consented by ITU-T on 874 December 2012. 876 [OTN-FWK] F.Zhang, D.Li, H.Li, S.Belotti, D.Ceccarelli, "Framework 877 for GMPLS and PCE Control of G.709 Optical Transport 878 Networks", work in 879 progress draft-ietf-ccamp-gmpls-g709-framework-11, 880 November 2012. 882 [OTN-RSVP] 883 F.Zhang, G.Zhang, S.Belotti, D.Ceccarelli, K.Pithewan, 884 "Generalized Multi-Protocol Label Switching (GMPLS) 885 Signaling Extensions for the evolving G.709 Optical 886 Transport Networks Control, work in progress 887 draft-ietf-ccamp-gmpls-signaling-g709v3-05", 888 November 2012. 890 Authors' Addresses 892 Sergio Belotti (editor) 893 Alcatel-Lucent 894 Via Trento, 30 895 Vimercate 896 Italy 898 Email: sergio.belotti@alcatel-lucent.com 899 Pietro Vittorio Grandi 900 Alcatel-Lucent 901 Via Trento, 30 902 Vimercate 903 Italy 905 Email: pietro_vittorio.grandi@alcatel-lucent.com 907 Daniele Ceccarelli (editor) 908 Ericsson 909 Via A. Negrone 1/A 910 Genova - Sestri Ponente 911 Italy 913 Email: daniele.ceccarelli@ericsson.com 915 Diego Caviglia 916 Ericsson 917 Via A. Negrone 1/A 918 Genova - Sestri Ponente 919 Italy 921 Email: diego.caviglia@ericsson.com 923 Fatai Zhang 924 Huawei Technologies 925 F3-5-B R&D Center, Huawei Base 926 Shenzhen 518129 P.R.China Bantian, Longgang District 927 Phone: +86-755-28972912 929 Email: zhangfatai@huawei.com 931 Dan Li 932 Huawei Technologies 933 F3-5-B R&D Center, Huawei Base 934 Shenzhen 518129 P.R.China Bantian, Longgang District 935 Phone: +86-755-28973237 937 Email: danli@huawei.com