idnits 2.17.1 draft-ietf-ccamp-otn-g709-info-model-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([G.709-2012]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 28, 2012) is 4166 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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 (~~), 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: June 1, 2013 D. Ceccarelli, Ed. 6 D. Caviglia 7 Ericsson 8 F. Zhang 9 D. Li 10 Huawei Technologies 11 November 28, 2012 13 Evaluation of existing GMPLS encoding against G.709v3 Optical Transport 14 Networks (OTN) 15 draft-ietf-ccamp-otn-g709-info-model-05 17 Abstract 19 The recent revision of ITU-T recommendation G.709 [G.709-2012] has 20 introduced new fixed and flexible Optical Data Unit (ODU) containers 21 in Optical Transport Networks (OTNs), enabling optimized support for 22 an increasingly abundant service mix. 24 This document provides an evaluation of existing Generalized 25 Multiprotocol Label Switching (GMPLS) routing and signaling methods 26 against the G.709-2012 OTN networks. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 1, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. G.709 Mapping and Multiplexing Capabilities . . . . . . . . . 4 64 3. Tributary Slot Granularity . . . . . . . . . . . . . . . . . . 6 65 3.1. Data Plane Considerations . . . . . . . . . . . . . . . . 6 66 3.1.1. Payload Type and TSG relationship . . . . . . . . . . 6 67 3.1.2. Fall-back procedure . . . . . . . . . . . . . . . . . 8 68 3.2. Control Plane considerations . . . . . . . . . . . . . . . 8 69 4. Tributary Port Number . . . . . . . . . . . . . . . . . . . . 12 70 5. Signal type . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 6. Bit rate and tolerance . . . . . . . . . . . . . . . . . . . . 14 72 7. Unreserved Resources . . . . . . . . . . . . . . . . . . . . . 14 73 8. Maximum LSP Bandwidth . . . . . . . . . . . . . . . . . . . . 14 74 9. Distinction between terminating and switching capability . . . 15 75 10. Priority Support . . . . . . . . . . . . . . . . . . . . . . . 17 76 11. Multi-stage multiplexing . . . . . . . . . . . . . . . . . . . 17 77 12. Generalized Label . . . . . . . . . . . . . . . . . . . . . . 18 78 13. Security Considerations . . . . . . . . . . . . . . . . . . . 18 79 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 80 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 82 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 17.1. Normative References . . . . . . . . . . . . . . . . . . . 19 84 17.2. Informative References . . . . . . . . . . . . . . . . . . 21 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 87 1. Introduction 89 GMPLS[RFC3945] extends MPLS to include Layer-2 Switching (L2SC), 90 Time-Division Multiplexing (e.g., SONET/SDH, PDH, and OTN), 91 Wavelength (OCh, Lambdas) Switching and Spatial Switching (e.g., 92 incoming port or fiber to outgoing port or fiber). 94 The establishment of Label Switched Paths (LSPs) that span only 95 interfaces recognizing packet/cell boundaries is defined in [RFC3036, 96 RFC3212, RFC3209]. [RFC3471] presents a functional description of 97 the extensions to MPLS signaling required to support GMPLS. ReSource 98 reserVation Protocol-Traffic Engineering (RSVP-TE) -specific formats, 99 mechanisms and technology specific details are defined in [RFC3473]. 101 From a routing perspective, Open Shortest Path First-Traffic 102 Engineering (OSPF-TE) generates Link State Advertisements (LSAs) 103 carrying application-specific information and floods them to other 104 nodes as defined in [RFC5250]. Three types of opaque LSA are 105 defined, i.e. type 9 - link-local flooding scope, type 10 - area- 106 local flooding scope, type 11 - AS flooding scope. 108 Type 10 LSAs are composed of a standard LSA header and a payload 109 including one top-level TLV and possible several nested sub-TLVs. 110 [RFC3630] defines two top-level TLVs: Router Address TLV and Link 111 TLV; and nine possible sub-TLVs for the Link TLV, used to carry link 112 related TE information. The Link type sub-TLVs are enhanced by 113 [RFC4203] in order to support GMPLS networks and related specific 114 link information. In GMPLS networks each node generates TE LSAs to 115 advertise its TE information and capabilities (link-specific or node- 116 specific)through the network. The TE information carried in the LSAs 117 are collected by the other nodes of the network and stored into their 118 local Traffic Engineering Databases (TED). 120 In a GMPLS enabled G.709-2012 OTNs, routing and signaling are 121 fundamental in order to allow automatic calculation and establishment 122 of routes for ODUk LSPs. The recent revision of ITU-T Recommendation 123 G.709 [G.709-2012] has introduced new fixed and flexible ODU 124 containers that augment those specified in [RFC4328]. As a result, 125 it is necessary to provide OSPF-TE and RSVP-TE extensions to allow 126 GMPLS control of all currently defined ODU containers. 128 This document provides an evaluation of GMPLS signaling and routing 129 processes against [G.709-2012] requirements. 131 OSPF-TE and RSVP-TE requirements are defined in [OTN-FWK], while 132 protocol extensions are defined in [OTN-OSPF] and [OTN-RSVP]. 134 2. G.709 Mapping and Multiplexing Capabilities 136 The digital OTN layered structure is comprised of digital path layer 137 networks (ODU) and digital section layer networks (OTU). An OTU 138 (Optical Transport Unit) section layer supports one ODU path layer as 139 client and provides monitoring capability for the OCh. An ODU path 140 layer may transport a heterogeneous assembly of ODU clients. Some 141 types of ODUs (i.e., ODU1, ODU2, ODU3, ODU4) may assume either a 142 client or server role within the context of a particular networking 143 domain. ITU-T G.872 amendment 2 recommendation [G.872-a2] provides 144 two tables defining mapping and multiplexing capabilities of OTNs, 145 which are reproduced below. 147 +--------------------+--------------------+ 148 | ODU client | OTU server | 149 +--------------------+--------------------+ 150 | ODU 0 | - | 151 +--------------------+--------------------+ 152 | ODU 1 | OTU 1 | 153 +--------------------+--------------------+ 154 | ODU 2 | OTU 2 | 155 +--------------------+--------------------+ 156 | ODU 2e | - | 157 +--------------------+--------------------+ 158 | ODU 3 | OTU 3 | 159 +--------------------+--------------------+ 160 | ODU 4 | OTU 4 | 161 +--------------------+--------------------+ 162 | ODU flex | - | 163 +--------------------+--------------------+ 165 Figure 1: OTN mapping capability 167 +=================================+=========================+ 168 | ODU client | ODU server | 169 +---------------------------------+-------------------------+ 170 | 1.25 Gbps client | | 171 +---------------------------------+ ODU 0 | 172 | - | | 173 +=================================+=========================+ 174 | 2.5 Gbps client | | 175 +---------------------------------+ ODU 1 | 176 | ODU 0 | | 177 +=================================+=========================+ 178 | 10 Gbps client | | 179 +---------------------------------+ ODU 2 | 180 | ODU0,ODU1,ODUflex | | 181 +=================================+=========================+ 182 | 10.3125 Gbps client | | 183 +---------------------------------+ ODU 2e | 184 | - | | 185 +=================================+=========================+ 186 | 40 Gbps client | | 187 +---------------------------------+ ODU 3 | 188 | ODU0,ODU1,ODU2,ODU2e,ODUflex | | 189 +=================================+=========================+ 190 | 100 Gbps client | | 191 +---------------------------------+ ODU 4 | 192 |ODU0,ODU1,ODU2,ODU2e,ODU3,ODUflex| | 193 +=================================+=========================+ 194 |CBR clients from greater than | | 195 |2.5 Gbit/s to 100 Gbit/s: or | | 196 |GFP-F mapped packet clients from | ODUflex | 197 |1.25 Gbit/s to 100 Gbit/s. | | 198 +---------------------------------+ | 199 | - | | 200 +=================================+=========================+ 202 Figure 2: OTN multiplexing capability 204 How an ODUk connection service is transported within an operator 205 network is governed by operator policy. For example, the ODUk 206 connection service might be transported over an ODUk path over an 207 OTUk section, with the path and section being at the same rate as 208 that of the connection service (see Table 1). In this case, an 209 entire lambda of capacity is consumed in transporting the ODUk 210 connection service. On the other hand, the operator might exploit 211 different multiplexing capabilities in the network to improve 212 infrastructure efficiencies within any given networking domain. In 213 this case, ODUk multiplexing may be performed prior to transport over 214 various rate ODU servers (as per Table 2) over associated OTU 215 sections. 217 From the perspective of multiplexing relationships, a given ODUk may 218 play different roles as it traverses various networking domains. 220 As detailed in [OTN-FWK], client ODUk connection services can be 221 transported over: 223 o Case A) one or more wavelength sub-networks connected by optical 224 links or 226 o Case B) one or more ODU links (having sub-lambda and/or lambda 227 bandwidth granularity) 229 o Case C) a mix of ODU links and wavelength sub-networks. 231 This document considers the TE information needed for ODU path 232 computation and parameters needed to be signaled for LSP setup. 234 The following sections list and analyze, for each type of data that 235 needs to be advertised and signaled, what is already there in GMPLS 236 and what is missing. 238 3. Tributary Slot Granularity 240 ITU-T recommendation defines two type of Tributary Slot (TS) 241 granularity. This TS granularity is defined per layer, meaning that 242 both ends of a link can select proper TS granularity differently for 243 each supported layer, based on the rules below: 245 - If both ends of a link are new cards supporting both 1.25Gbps TS 246 and 2.5Gbps TS, then the link will work with 1.25Gbps TS. 248 - If one end is a new card supporting both the 1.25Gbps and 249 2,5Gbps TS, and the other end is an old card supporting just the 250 2.5Gbps TS, the link will work with 2.5Gbps TS. 252 3.1. Data Plane Considerations 254 3.1.1. Payload Type and TSG relationship 256 As defined in G.709-2012 an ODUk container consist of an Optical 257 Payload Unit (OPUk) plus a specific ODUk Overhead (OH). OPUk OH 258 information is added to the OPUk information payload to create an 259 OPUk. It includes information to support the adaptation of client 260 signals. Within the OPUk overhead there is the payload structure 261 identifier (PSI) that includes the payload type (PT). The payload 262 type (PT) is used to indicate the composition of the OPUk signal. 263 When an ODUj signal is multiplexed into an ODUk, the ODUj signal is 264 first extended with frame alignment overhead and then mapped into an 265 Optical channel Data Tributary Unit (ODTU). Two different types of 266 ODTU are defined: 268 - ODTUjk ((j,k) = {(0,1), (1,2), (1,3), (2,3)}; ODTU01, ODTU12, 269 ODTU13 and ODTU23) in which an ODUj signal is mapped via the 270 Asynchronous Mapping Procedure (AMP), defined in clause 19.5 of 271 G.709-2012. 273 - ODTUk.ts ((k,ts) = (2,1..8), (3,1..32), (4,1..80)) in which a 274 lower order ODU (ODU0, ODU1, ODU2, ODU2e, ODU3, ODUflex) signal is 275 mapped via the Generic Mapping Procedure (GMP), defined in clause 276 19.6 of G.709-2012. 278 G.709-2012 introduces also a logical entity, called Optical Data 279 Tributary Unit Group (ODTUGk), characterizing the multiplexing of the 280 various ODTU. The ODTUGk is then mapped into OPUK. ODTUjk and 281 ODTUk.ts signals are directly time-division multiplexed into the 282 tributary slots of an HO OPUk. 284 When PT is assuming value 20 or 21,together with OPUk type (K= 285 1,2,3,4), it is used to discriminate two different ODU multiplex 286 structure ODTUGx : 288 - Value 20: supporting ODTUjk only, 290 - Value 21: supporting ODTUk.ts or ODTUk.ts and ODTUjk. 292 The discrimination is needed for OPUk with K =2 or 3, since OPU2 and 293 OPU3 are able to support both the different ODU multiplex structures. 294 For OPU4 and OPU1, only one type of ODTUG is supported: ODTUG4 with 295 PT=21 and ODTUG1 with PT=20. (see table Figure 6).The relationship 296 between PT and TS granularity, is in the fact that the two different 297 ODTUGk discriminated by PT and OPUk are characterized by two 298 different TS granularities of the related OPUk, the former at 2.5 299 Gbps, the latter at 1.25Gbps. 301 In order to complete the picture, in the PSI OH there is also the 302 Multiplex Structure Identifier (MSI) that provides the information on 303 which tributary slots the different ODTUjk or ODTUk.ts are mapped 304 into the related OPUk. The following figure shows how the client 305 traffic is multiplexed till the OPUk layer. 307 +--------+ +------------+ 308 +----+ | !------| ODTUjk |-----Client 309 | | | ODTUGk | +-----.------+ 310 | |-----| PT=21 | . 311 | | | | +-----.------+ 312 | | | |------| ODTUk.TS |-----Client 313 |OPUk| +--------+ +------------+ 314 | | 315 | | +--------+ +------------+ 316 | | | |------| ODTUjk |-----Client 317 | |-----| | +-----.------+ 318 +----+ | ODTUGk | . 319 | PT=20 | +-----.------+ 320 | |------| ODTUjk |-----Client 321 +--------+ +------------+ 323 Figure 3: OTN client multiplexing 325 3.1.2. Fall-back procedure 327 ITU-T G.798 recommendation Amendment 2 [G.798-a2] describes the so 328 called PT=21-to-PT=20 interworking process that explains how two 329 equipments with interfaces with different PayloadType, and hence 330 different TS granularity (1.25Gbps vs. 2.5Gbps), can be coordinated 331 so to permit the equipment with 1.25 TS granularity to adapt his TS 332 allocation accordingly to the different TS granularity (2.5Gbps) of a 333 neighbor. 335 Therefore, in order to let the NE change TS granularity accordingly 336 to the nieghbour requirements, the AUTOpayloadtype needs to be set. 337 When both the neighbors (link or trail) have been configured as 338 structured, the payload type received in the overhead is compared to 339 the transmitted PT. If they are different and the transmitted PT=21, 340 the node must fallback to PT=20. In this case the fall-back process 341 makes the system self consistent and the only reason for signaling 342 the TS granularity is to provide the correct label (i.e. label for 343 PT=21 has twice the TS number of PT=20). On the other side, if the 344 AUTOpayloadtype is not configured, the RSVP-TE consequent actions in 345 case of TS mismatch need to be defined. 347 3.2. Control Plane considerations 349 When setting up an ODUj over an ODUk, it is possible to identify two 350 types of TSG, the server and the client one. The server TSG is used 351 to map an end to end ODUj onto a server ODUk LSP or links. This 352 parameter can not be influenced in any way from the ODUj LSP: ODUj 353 LSP will be mapped on tributary slots available on the different 354 links/ODUk LSPs. When setting up an ODUj at a given rate, the fact 355 that it is carried over a path composed by links/Forwarding 356 Adjacencies(FAs) structured with 1.25Gbps or 2.5Gbps TS size is 357 completely transparent to the end to end ODUj. 359 On the other side the client TSG is the tributary slot size that is 360 exported towards the client layer. The client TSG information is one 361 of the parameters needed to correctly select the adaptation towards 362 the client layers at the end nodes and this is the only thing that 363 the ODUj has to guarantee. 365 In figure 4 an example of client and server TSG utilization in a 366 scenario with mixed [RFC4328] OTN and [G.709-2012] OTN interfaces is 367 shown. 369 ODU1-LSP 370 ......................................... 371 TSG-C| |TSG-C 372 1.25| ODU2-H-LSP |1.25 373 +------------X--------------------------+ 374 | TSG-S| |TSG-S 375 | 2.5| |2.5 376 | | ODU3-H-LSP | 377 | |------------X-------------| 378 | | | 379 +--+--+ +--+--+ +---+-+ 380 | | | | +-+ +-+ | | 381 | A +------+ B +-----+ +***+ +-----+ Z | 382 | V.3 | OTU2 | V.1 |OTU3 +-+ +-+ OTU3| V.3 | 383 +-----+ +-----+ +-----+ 385 ... Service LSP 386 --- H-LSP 388 Figure 4: Client-Server TSG example 390 In this scenario, an ODU3 LSP is setup from node B to Z. Node B has 391 an old interface able to support 2.5 TSG granularity, hence only 392 client TSG equal to 2.5Gbps can be exported to ODU3 H-LSP possible 393 clients. An ODU2 LSP is setup from node A to node Z with client TSG 394 1.25 signaled and exported towards clients. The ODU2 LSP is carried 395 by ODU3 H-LSP from B to Z. Due to the limitations of old node B 396 interface, the ODU2 LSP is mapped with 2.5Gbps TSG over the ODU3 397 H-LSP. Then an ODU1 LSP is setup from A to Z, carried by the ODU2 398 H-LSP and mapped over it using a 1.25Gbps TSG. 400 What is shown in the example is that the TSG processing is a per 401 layer issue: even if the ODU3 H-LSP is created with TSG client at 402 2.5Gbps, the ODU2 H-LSP must guarantee a 1.25Gbps TSG client. ODU3 403 H-LSP is eligible from ODU2 LSP perspective since from the routing it 404 is known that this ODU3 interface at node Z, supports an ODU2 405 termination exporting a TSG 1.25/2.5. 407 The TSG information is needed in the routing protocol as the ingress 408 node (A in the previous example) needs to know if the interfaces at 409 the last hop can support the required TSG. In case they cannot, A 410 will compute an alternate path from itself to Z (see figure 4). 412 Moreover, also TSG information needs to be signaled. Consider as 413 example the setup of an ODU3 path that is going to carry an ODU0, 414 hence the support of 1,25 GBps TS is needed. The information related 415 to the TSG has to be carried in the signaling to permit node C (see 416 figure 5) chosose the right one among the different interfaces (with 417 different TSGs) towards D. In case the full ERO is provided in the 418 signaling with explicit interface declaration, there is no need for C 419 to choose the right interface towards D as it has been already 420 decided by the ingress node or by the PCE. 422 ODU3 423 ________________________ 425 ODU0 426 ________________________________________ 427 | | 428 +--------+ +--------+ +--------+ +--------+ 429 | | | | | | 1.25 | | 430 | Node | | Node | | Node +------+ Node | 431 | A +------+ B +------+ C | ODU3 | D | 432 | | ODU3 | | ODU3 | +------+ | 433 +--------+ 1.25 +--------+ 2.5 +--------+ 2.5 +--------+ 435 Figure 5: TSG in signaling 437 In case an ODUk FA_LSP needs to be set up nesting another ODUj (as 438 depicted in figure 4), there might be the need to know the hierarchy 439 of nested LSPs in addition to TSG, to permit the penultimate hop 440 choosing the correct interface towards the egress node. This is not 441 needed in case we allow bundling only component links with 442 homogeneous hierarchies. In case of specific implementation not 443 specifying in the ERO the last hop interface, crank-back can be a 444 solution. 446 In a multi-stage multiplexing environment any layer can have a 447 different TSG structure, e.g. in a multiplexing hierarchy like 448 ODU0->ODU2->ODU3, the ODU3 can be structured at TSG=2.5 in order to 449 support an ODU2 connection, but this ODU2 connection can be a tunnel 450 for ODU0, and hence structured with 1.25 TSG. Therefore any 451 multiplexing level has to advertise his TSG capabilities in order to 452 allow a correct path computation by the end nodes (both of the ODUk 453 trail and of the H-LSP/FA). 455 The following table shows the different mapping possibilities 456 depending on the TSG types. The client types are shown in the left 457 column, while the different OPUk server and related TSGs are listed 458 in the top row. The table also shows the relationship between the 459 TSG and the payload type. 461 +------------------------------------------------+ 462 | 2.5G TS || 1.25G TS | 463 | OPU2 | OPU3 || OPU1 | OPU2 | OPU3 | OPU4 | 464 +-------+------------------------------------------------+ 465 | | - | - || AMP | GMP | GMP | GMP | 466 | ODU0 | | || PT=20 | PT=21 | PT=21 | PT=21 | 467 +-------+------------------------------------------------+ 468 | | AMP | AMP || - | AMP | AMP | GMP | 469 | ODU1 | PT=20 | PT=20 || | PT=21 | PT=21 | PT=21 | 470 +-------+------------------------------------------------+ 471 | | - | AMP || - | - | AMP | GMP | 472 | ODU2 | | PT=20 || | | PT=21 | PT=21 | 473 +-------+------------------------------------------------+ 474 | | - | - || - | - | GMP | GMP | 475 | ODU2e | | || | | PT=21 | PT=21 | 476 +-------+------------------------------------------------+ 477 | | - | - || - | - | - | GMP | 478 | ODU3 | | || | | | PT=21 | 479 +-------+------------------------------------------------+ 480 | | - | - || - | GMP | GMP | GMP | 481 | ODUfl | | || | PT=21 | PT=21 | PT=21 | 482 +-------+------------------------------------------------+ 484 Figure 6: ODUj into OPUk mapping types (Source: Table 7-10 [G.709- 485 2012]) 487 The signaled TSGs information is not enough to have a complete choice 488 since the penultimate hop node has to distinguish between interfaces 489 with the same TSG (e.g. 1.25Gbps) whether the interface is able to 490 support the right hierarchy, i.e. it is possible to have two 491 interfaces both at 1.25 TSG but only one is supporting ODU0. 493 A dedicated optional object could be defined in order to carry the 494 multiplexing hierarchy and adaptation information (i.e. TSG/PT, AMP/ 495 GMP) so to have a more precise choice capability. In this way, when 496 the penultimate node receives such object, together with the Traffic 497 Parameters Object, is allowed to choose the correct interface towards 498 the egress node. 500 In conclusion both routing and signaling will need to be extended to 501 appropriately represent the TSG/PT information. Routing will need to 502 represent a link's TSG and PT capabilities as well as the supported 503 multiplexing hierarchy. Signaling will need to represent the TSG/PT 504 and multiplexing hierarchy encoding. 506 4. Tributary Port Number 508 [RFC4328] supports only the deprecated auto-MSI mode which assumes 509 that the Tributary Port Number is automatically assigned in the 510 transmit direction and not checked in the receive direction. 512 As described in [G.709-2012] and [G.798-a2], the OPUk overhead in an 513 OTUk frame contains n (n = the total number of TSs of the ODUk) MSI 514 (Multiplex Structure Identifier) bytes (in the form of multi-frame), 515 each of which is used to indicate the association between tributary 516 port number and tributary slot of the ODUk. 518 The association between TPN and TS has to be configured by the 519 control plane and checked by the data plane on each side of the link. 520 (Please refer to [OTN-FWK] for further details). As a consequence, 521 the RSVP-TE signaling needs to be extended to support the TPN 522 assignment function. 524 5. Signal type 526 From a routing perspective, [RFC4203] allows advertising [RFC4328] 527 interfaces (single TS type) without the capability of providing 528 precise information about bandwidth specific allocation. For 529 example, in case of link bundling, dividing the unreserved bandwidth 530 by the MAX LSP bandwidth it is not possible to know the exact number 531 of LSPs at MAX LSP bandwidth size that can be set up. (see example 532 fig. 3) 534 The lack of spatial allocation heavily impacts the restoration 535 process, because the lack of information of free resources highly 536 increases the number of crank-backs affecting network convergence 537 time. 539 Moreover actual tools provided by [RFC4203] only allow advertising 540 signal types with fixed bandwidth and implicit hierarchy (e.g. SDH/ 541 SONET networks) or variable bandwidth with no hierarchy (e.g. packet 542 switching networks) but do not provide the means for advertising 543 networks with mixed approach (e.g. ODUflex CBR and ODUflex packet). 545 For example, advertising ODU0 as MIN LSP bandwidth and ODU4 as MAX 546 LSP bandwidth it is not possible to state whether the advertised link 547 supports ODU4 and ODUflex or ODU4, ODU3, ODU2, ODU1, ODU0 and 548 ODUflex. Such ambiguity is not present in SDH networks where the 549 hierarchy is implicit and flexible containers like ODUFlex do not 550 exist. The issue could be resolved by declaring 1 ISCD for each 551 signal type actually supported by the link. 553 Supposing for example to have an equivalent ODU2 unreserved bandwidth 554 in a TE-link (with bundling capability) distributed on 4 ODU1, it 555 would be advertised via the ISCD in this way: 557 MAX LSP Bw: ODU1 559 MIN LSP Bw: ODU1 561 - Maximum Reservable Bandwidth (of the bundle) set to ODU2 563 - Unreserved Bandwidth (of the bundle) set to ODU2 565 In conclusion, the OSPF-TE extensions defined in [RFC4203] require a 566 different ISCD per signal type in order to advertise each supported 567 container. This motivates attempting to look for a more optimized 568 solution, without proliferations of the number of ISCD advertised. 569 Per [RFC2328], OSPF messages are directly encapsulated in IP 570 datagrams and depend on IP fragmentation when transmitting packets 571 larger than the network MTU. [RFC2328] recommends that "IP 572 fragmentation should be avoided whenever possible." This 573 recommendation further constraints solutions as OSPF does not support 574 any generic mechanism to fragment OSPF LSAs. 576 With respect to link bundling [RFC4201], the utilization of the ISCD 577 as it is, would not allow precise advertising of spatial bandwidth 578 allocation information unless using only one component link per TE 579 link. 581 On the other hand, from a singaling point of view, [RFC4328] 582 describes GMPLS signaling extensions to support the control for pre- 583 G.709-2012 OTNs. However, [RFC4328] needs to be updated because it 584 does not provide the means to signal all the new signal types and 585 related mapping and multiplexing functionalities. 587 6. Bit rate and tolerance 589 In the current traffic parameters signaling, bit rate and tolerance 590 are implicitly defined by the signal type. ODUflex CBR and Packet 591 can have variable bit rates and tolerances (please refer to [OTN-FWK] 592 table 2); it is thus needed to upgrade the signaling traffic 593 patameters so to specify requested bit rates and tolerance values 594 during LSP setup. 596 7. Unreserved Resources 598 Unreserved resources need to be advertised per priority and per 599 signal type in order to allow the correct functioning of the 600 restoration process. [RFC4203] only allows advertising unreserved 601 resources per priority, this leads not to know how many LSPs of a 602 specific signal type can be restored. As example it is possible to 603 consider the scenario depicted in the following figure. 605 +------+ component link 1 +------+ 606 | +------------------+ | 607 | | component link 2 | | 608 | N1 +------------------+ N2 | 609 | | component link 3 | | 610 | +------------------+ | 611 +------+ +---+--+ 613 Figure 7: Concurrent path computation 615 Suppose to have a TE link comprising 3 ODU3 component links with 616 32TSs available on the first one, 24TSs on the second, 24TSs on the 617 third and supporting ODU2 and ODU3 signal types. The node would 618 advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX 619 LSP bandwidth equal to 32 TSs. In case of restoration the network 620 could try to restore 2 ODU3 (64TSs) in such TE-link while only a 621 single ODU3 can be set up and a crank-back would be originated. In 622 more complex network scenarios the number of crank-backs can be much 623 higher. 625 8. Maximum LSP Bandwidth 627 Maximum LSP bandwidth is currently advertised in the common part of 628 the ISCD and advertised per priority, while in OTN networks it is 629 only required for ODUflex advertising. This leads to a significant 630 waste of bits inside each LSA. 632 9. Distinction between terminating and switching capability 634 The capability advertised by an interface needs further distinction 635 in order to separate termination and switching capabilities. Due to 636 internal constraints and/or limitations, the type of signal being 637 advertised by an interface could be just switched (i.e. forwarded to 638 switching matrix without multiplexing/demultiplexing actions), just 639 terminated (demuxed) or both of them. The following figures help 640 explainig the switching and terminating capabilities. 642 MATRIX LINE INTERFACE 643 +-----------------+ +-----------------+ 644 | +-------+ | ODU2 | | 645 ----->| ODU-2 |----|----------|--------\ | 646 | +-------+ | | +----+ | 647 | | | \__/ | 648 | | | \/ | 649 | +-------+ | ODU3 | | ODU3 | 650 ----->| ODU-3 |----|----------|------\ | | 651 | +-------+ | | \ | | 652 | | | \| | 653 | | | +----+ | 654 | | | \__/ | 655 | | | \/ | 656 | | | ---------> OTU-3 657 +-----------------+ +-----------------+ 659 Figure 8: Switching and Terminating capabilities 661 The figure in the example shows a line interface able to: 663 - Multiplex an ODU2 coming from the switching matrix into and ODU3 664 and map it into an OTU3 666 - Map an ODU3 coming from the switching matrix into an OTU3 668 In this case the interface bandwidth advertised is ODU2 with 669 switching capability and ODU3 with both switching and terminating 670 capabilities. 672 This piece of information needs to be advertised together with the 673 related unreserved bandwidth and signal type. As a consequence 674 signaling must have the possibility to setup an LSP allowing the 675 local selection of resources consistent with the limitations 676 considered during the path computation. 678 In figures 9 and 10 there are two examples of the need of 679 termination/switching capability differentiation. In both examples 680 all nodes only support single-stage capability. Figure 9 represents 681 a scenario in which a failure on link B-C forces node A to calculate 682 another ODU2 LSP path carrying ODU0 service along the nodes B-E-D. 683 As node D is a single stage capable node, it is able to extract ODU0 684 service only from ODU2 interface. Node A has to know that from E to 685 D exists an available OTU2 link from which node D can extract the 686 ODU0 service. This information is required in order to avoid that 687 the OTU3 link is considered in the path computation. 689 ODU0 transparently transported 690 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 691 | ODU2 LSP Carrying ODU0 service | 692 | |'''''''''''''''''''''''''''''''''''''''''''| | 693 | | | | 694 | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | 695 ODU0 | | Link | | Link | | Link | | ODU0 696 ---->| A |_________| B |_________| C |_________| D |----> 697 | | | | | | | | 698 +-----+ +--+--+ +-----+ ++--+-+ 699 | | | 700 OTU3| | | 701 Link| +-----+__________________| | 702 | | | OTU3 Link | 703 |____| E | | 704 | |_____________________| 705 +-----+ OTU2 Link 707 Figure 9: Switching and Terminating capabilities - Example 1 709 Figure 7 addresses the scenario in which the restoration of the ODU2 710 LSP (ABCD) is required. The two bundled component links between B 711 and E could be used, but the ODU2 over the OTU2 component link can 712 only be terminated and not switched. This implies that it cannot be 713 used to restore the ODU2 LSP (ABCD). However such ODU2 unreserved 714 bandwidth must be advertised since it can be used for a different 715 ODU2 LSP terminating on E, e.g. (FBE). Node A has to know that the 716 ODU2 capability on the OTU2 link can only be terminated and that the 717 restoration of (ABCD) can only be performed using the ODU2 bandwidth 718 available on the OTU3 link. 720 ODU0 transparently transported 721 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 722 | ODU2 LSP Carrying ODU0 service | 723 | |'''''''''''''''''''''''''''''''''''''''''''| | 724 | | | | 725 | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | 726 ODU0 | | Link | | Link | | Link | | ODU0 727 ---->| A |_________| B |_________| C |_________| D |----> 728 | | | | | | | | 729 +-----+ ++-+-++ +-----+ +--+--+ 730 | | | | 731 OTU2| | | | 732 +-----+ Link| | | OTU3 +-----+ | 733 | | | | | Link | | | 734 | F |_______| | |___________| E |___________| 735 | | |_____________| | OTU2 Link 736 +-----+ OTU2 Link +-----+ 738 Figure 10: Switching and Terminating capabilities - Example 2 740 10. Priority Support 742 The IETF foresees that up to eight priorities must be supported and 743 that all of them have to be advertised independently on the number of 744 priorities supported by the implementation. Considering that the 745 advertisement of all the different supported signal types will 746 originate large LSAs, it is advised to advertise only the information 747 related to the really supported priorities. 749 11. Multi-stage multiplexing 751 With reference to the [OTN-FWK], introduction of multi-stage 752 multiplexing implies the advertisement of cascaded adaptation 753 capabilities together with the matrix access constraints. The 754 structure defined by IETF for the advertisement of adaptation 755 capabilities is ISCD/IACD as in [RFC4202] and [RFC5339]. 756 Modifications to ISCD/IACD, if needed, have to be addressed in the 757 releted encoding documents. 759 With respect to the routing, please note that in case of multi stage 760 muxing hierarchy (e.g. ODU1->ODU2->ODU3), not only the ODUk/OTUk 761 bandwidth (ODU3) and service layer bandwidth (ODU1) are needed, but 762 also the intermediate one (ODU2). This is a typical case of spatial 763 allocation problem. 765 Suppose in this scenario to have the following advertisement: 767 Hierarchy: ODU1->ODU2->ODU3 769 Number of ODU1==5 771 The number of ODU1 suggests that it is possible to have an ODU2 FA, 772 but it depends on the spatial allocation of such ODU1s. 774 It is possible that 2 links are bundled together and 3 775 ODU1->ODU2->ODU3 are available on a component link and 2 on the other 776 one, in such a case no ODU2 FA could be set up. The advertisement of 777 the ODU2 is needed because in case of ODU1 spatial allocation (3+2), 778 the ODU2 available bandwidth would be 0 (no ODU2 FA can be created), 779 while in case of ODU1 spatial allocation (4+1) the ODU2 available 780 bandwidth would be 1 (1 ODU2 FA can be created). 782 12. Generalized Label 784 The ODUk label format defined in [RFC4328] could be updated to 785 support new signal types defined in [G.709-2012] but would hardly be 786 further enhanced to support possible new signal types. 788 Furthermore such label format may have scalability issues due to the 789 high number of labels needed when signaling large LSPs. For example, 790 when an ODU3 is mapped into an ODU4 with 1.25G tributary slots, it 791 would require the utilization of thirty-one labels (31*4*8=992 bits) 792 to be allocated while an ODUflex into an ODU4 may need up to eighty 793 labels (80*4*8=2560 bits). 795 A new flexible and scalable ODUk label format needs to be defined. 797 13. Security Considerations 799 This document provides an evaluation of OTN requirements against 800 actual routing [RFC4202] and [RFC4203] and signaling mechanism 801 [RFC3471], [RFC3473] and [RFC4328]in GMPLS. 803 New types of information to be conveyed regard OTN containers and 804 hierarchies and from a security standpoint this memo does not 805 introduce further risks with respect to the information that can be 806 currently conveyed via GMPLS protocols. For a general discussion on 807 MPLS and GMPLS-related security issues, see the MPLS/GMPLS security 808 framework [RFC5920]. 810 14. IANA Considerations 812 This informational document does not make any requests for IANA 813 action. 815 15. Contributors 817 Jonathan Sadler, Tellabs 819 EMail: jonathan.sadler@tellabs.com 821 John Drake, Juniper 823 EMail: jdrake@juniper.net 825 Francesco Fondelli 827 Ericsson 829 Via Moruzzi 1 831 Pisa - 56100 833 Email: francesco.fondelli@ericsson.com 835 16. Acknowledgements 837 The authors would like to thank Eve Varma and Sergio Lanzone for 838 their precious collaboration and review. 840 17. References 842 17.1. Normative References 844 [OTN-OSPF] 845 D.Ceccarelli,D.Caviglia,F.Zhang,D.Li,Y.Xu,P.Grandi,S.Belot 846 ti, "Traffic Engineering Extensions to OSPF for 847 Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN 848 Networks", work in 849 progress draft-ietf-ccamp-gmpls-ospf-g709v3-04, November 850 2012. 852 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 854 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 855 (GMPLS) Signaling Functional Description", RFC 3471, 856 January 2003. 858 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 859 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 860 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 862 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 863 (TE) Extensions to OSPF Version 2", RFC 3630, 864 September 2003. 866 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 867 (GMPLS) Architecture", RFC 3945, October 2004. 869 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 870 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 872 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 873 Support of Generalized Multi-Protocol Label Switching 874 (GMPLS)", RFC 4202, October 2005. 876 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 877 of Generalized Multi-Protocol Label Switching (GMPLS)", 878 RFC 4203, October 2005. 880 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 881 Switching (GMPLS) Signaling Extensions for G.709 Optical 882 Transport Networks Control", RFC 4328, January 2006. 884 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 885 OSPF Opaque LSA Option", RFC 5250, July 2008. 887 [RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing 888 GMPLS Protocols against Multi-Layer and Multi-Region 889 Networks (MLN/MRN)", RFC 5339, September 2008. 891 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 892 Networks", RFC 5920, July 2010. 894 17.2. Informative References 896 [G.709-2012] 897 ITU-T, "Rec G.709, version 4", approved by ITU-T in 2012. 899 [G.798-a2] 900 ITU-T, "Amendment 2 of G.798 Characteristics of optical 901 transport network hierarchy equipment functional blocks", 902 consented by ITU-T on April 2012. 904 [G.872-a2] 905 ITU-T, "Amendment 2 of G.872 Architecture of optical 906 transport networks for consent", consented by ITU-T on 907 June 2010. 909 [OTN-FWK] F.Zhang, D.Li, H.Li, S.Belotti, D.Ceccarelli, "Framework 910 for GMPLS and PCE Control of G.709 Optical Transport 911 Networks", work in 912 progress draft-ietf-ccamp-gmpls-g709-framework-11, 913 November 2012. 915 [OTN-RSVP] 916 F.Zhang, G.Zhang, S.Belotti, D.Ceccarelli, K.Pithewan, 917 "Generalized Multi-Protocol Label Switching (GMPLS) 918 Signaling Extensions for the evolving G.709 Optical 919 Transport Networks Control, work in progress 920 draft-ietf-ccamp-gmpls-signaling-g709v3-05", 921 November 2012. 923 Authors' Addresses 925 Sergio Belotti (editor) 926 Alcatel-Lucent 927 Via Trento, 30 928 Vimercate 929 Italy 931 Email: sergio.belotti@alcatel-lucent.com 932 Pietro Vittorio Grandi 933 Alcatel-Lucent 934 Via Trento, 30 935 Vimercate 936 Italy 938 Email: pietro_vittorio.grandi@alcatel-lucent.com 940 Daniele Ceccarelli (editor) 941 Ericsson 942 Via A. Negrone 1/A 943 Genova - Sestri Ponente 944 Italy 946 Email: daniele.ceccarelli@ericsson.com 948 Diego Caviglia 949 Ericsson 950 Via A. Negrone 1/A 951 Genova - Sestri Ponente 952 Italy 954 Email: diego.caviglia@ericsson.com 956 Fatai Zhang 957 Huawei Technologies 958 F3-5-B R&D Center, Huawei Base 959 Shenzhen 518129 P.R.China Bantian, Longgang District 960 Phone: +86-755-28972912 962 Email: zhangfatai@huawei.com 964 Dan Li 965 Huawei Technologies 966 F3-5-B R&D Center, Huawei Base 967 Shenzhen 518129 P.R.China Bantian, Longgang District 968 Phone: +86-755-28973237 970 Email: danli@huawei.com