idnits 2.17.1 draft-ietf-ccamp-otn-g709-info-model-04.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-v3]), 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 12, 2012) is 4305 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3945' is mentioned on line 93, but not defined == Missing Reference: 'RFC3036' is mentioned on line 99, but not defined ** Obsolete undefined reference: RFC 3036 (Obsoleted by RFC 5036) == Missing Reference: 'RFC3212' is mentioned on line 99, but not defined == Missing Reference: 'RFC3209' is mentioned on line 99, but not defined == Missing Reference: 'RFC3471' is mentioned on line 100, but not defined == Missing Reference: 'RFC3473' is mentioned on line 104, but not defined == Missing Reference: 'G709-V3' is mentioned on line 840, but not defined == Missing Reference: 'OTN-RSVP' is mentioned on line 139, but not defined == Missing Reference: 'G.7715.1' is mentioned on line 165, but not defined == Missing Reference: 'G798-V3' is mentioned on line 565, but not defined == Missing Reference: 'RFC 4203' is mentioned on line 579, but not defined == Missing Reference: 'G709-V1' is mentioned on line 638, but not defined == Unused Reference: 'RFC6107' is defined on line 932, but no explicit reference was found in the text == Unused Reference: 'G.709-v1' is defined on line 938, but no explicit reference was found in the text == Unused Reference: 'G.709-v2' is defined on line 943, but no explicit reference was found in the text == Unused Reference: 'G.872-am2' is defined on line 952, but no explicit reference was found in the text -- No information found for draft-ietf-ccamp-gmpls-ospf-g709 - is the name correct? == Outdated reference: A later version (-15) exists of draft-ietf-ccamp-gmpls-g709-framework-05 Summary: 2 errors (**), 0 flaws (~~), 19 warnings (==), 2 comments (--). 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: January 13, 2013 D. Ceccarelli, Ed. 6 D. Caviglia 7 Ericsson 8 F. Zhang 9 D. Li 10 Huawei Technologies 11 July 12, 2012 13 Information model for G.709 Optical Transport Networks (OTN) 14 draft-ietf-ccamp-otn-g709-info-model-04 16 Abstract 18 The recent revision of ITU-T recommendation G.709 [G.709-v3] has 19 introduced new fixed and flexible ODU containers in Optical Transport 20 Networks (OTNs), enabling optimized support for an increasingly 21 abundant service mix. 23 This document provides a model of information needed by the routing 24 and signaling process in OTNs to support Generalized Multiprotocol 25 Label Switching (GMPLS) control of all currently defined ODU 26 containers. 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 January 13, 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. OSPF-TE requirements overview . . . . . . . . . . . . . . . . 4 65 3. RSVP-TE requirements overview . . . . . . . . . . . . . . . . 5 66 4. G.709 Digital Layer Info Model for Routing and Signaling . . . 5 67 4.1. Tributary Slot Granularity . . . . . . . . . . . . . . . . 8 68 4.1.1. Data Plane Considerations . . . . . . . . . . . . . . 8 69 4.1.1.1. Payload Type and TSG relationship . . . . . . . . 8 70 4.1.1.2. Fall-back procedure . . . . . . . . . . . . . . . 10 71 4.1.2. Control Plane considerations . . . . . . . . . . . . . 10 72 4.2. Tributary Port Number . . . . . . . . . . . . . . . . . . 14 73 4.3. Signal type . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.4. Bit rate and tolerance . . . . . . . . . . . . . . . . . . 15 75 4.5. Unreserved Resources . . . . . . . . . . . . . . . . . . . 16 76 4.6. Maximum LSP Bandwidth . . . . . . . . . . . . . . . . . . 16 77 4.7. Distinction between terminating and switching 78 capability . . . . . . . . . . . . . . . . . . . . . . . . 16 79 4.8. Priority Support . . . . . . . . . . . . . . . . . . . . . 19 80 4.9. Multi-stage multiplexing . . . . . . . . . . . . . . . . . 19 81 4.10. Generalized Label . . . . . . . . . . . . . . . . . . . . 20 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 91 1. Introduction 93 GMPLS[RFC3945] extends MPLS to include Layer-2 Switching (L2SC), 94 Time-Division Multiplexing (e.g., SONET/SDH, PDH, and OTN), 95 Wavelength (OCh, Lambdas) Switching and Spatial Switching (e.g., 96 incoming port or fiber to outgoing port or fiber). 98 The establishment of LSPs that span only interfaces recognizing 99 packet/cell boundaries is defined in [RFC3036, RFC3212, RFC3209]. 100 [RFC3471] presents a functional description of the extensions to 101 Multi-Protocol Label Switching (MPLS) signaling required to support 102 GMPLS. ReSource reserVation Protocol-Traffic Engineering (RSVP-TE) 103 -specific formats, mechanisms and technology specific details are 104 defined in [RFC3473]. 106 From a routing perspective, Open Shortest Path First-Traffic 107 Engineering (OSPF-TE) generates Link State Advertisements (LSAs) 108 carrying application-specific information and floods them to other 109 nodes as defined in [RFC5250]. Three types of opaque LSA are 110 defined, i.e. type 9 - link-local flooding scope, type 10 - area- 111 local flooding scope, type 11 - AS flooding scope. 113 Type 10 LSAs are composed of a standard LSA header and a payload 114 including one top-level TLV and possible several nested sub-TLVs. 115 [RFC3630] defines two top-level TLVs: Router Address TLV and Link 116 TLV; and nine possible sub-TLVs for the Link TLV, used to carry link 117 related TE information. The Link type sub-TLVs are enhanced by 118 [RFC4203] in order to support GMPLS networks and related specific 119 link information. In GMPLS networks each node generates TE LSAs to 120 advertise its TE information and capabilities (link-specific or node- 121 specific)through the network. The TE information carried in the LSAs 122 are collected by the other nodes of the network and stored into their 123 local Traffic Engineering Databases (TED). 125 In a GMPLS enabled G.709 Optical Transport Networks (OTN), routing 126 and signaling are fundamental in order to allow automatic calculation 127 and establishment of routes for ODUk LSPs. The recent revision of 128 ITU-T Recommendation G.709 [G709-V3] has introduced new fixed and 129 flexible ODU containers that augment those specified in foundation 130 OTN. As a result, it is necessary to provide OSPF-TE and RSVP-TE 131 extensions to allow GMPLS control of all currently defined ODU 132 containers. 134 This document provides the information model needed by the routing 135 and signaling processses in OTNs to allow GMPLS control of all 136 currently defined ODU containers. 138 OSPF-TE and RSVP-tE requirements are defined in [OTN-FWK], while 139 protocol extensions are defined in [OTN-OSPF] and [OTN-RSVP]. 141 1.1. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 2. OSPF-TE requirements overview 149 [OTN-FWK] provides a set of functional routing requirements 150 summarized below : 152 - Support for link multiplexing capability advertisement: The 153 routing protocol has to be able to carry information regarding the 154 capability of an OTU link to support different type of ODUs 156 - Support of any ODUk and ODUflex: The routing protocol must be 157 capable of carrying the required link bandwidth information for 158 performing accurate route computation for any of the fixed rate 159 ODUs as well as ODUflex. 161 - Support for differentiation between switching and terminating 162 capacity 164 - Support for the client server mappings as required by 165 [G.7715.1]. The list of different mappings methods is reported in 166 [G.709-v3]. Since different methods exist for how the same client 167 layer is mapped into a server layer, this needs to be captured in 168 order to avoid the set-up of connections that fail due to 169 incompatible mappings. 171 - Support different priorities for resource reservation. How many 172 priorities levels should be supported depends on operator 173 policies. Therefore, the routing protocol should be capable of 174 supporting either no priorities or up to 8 priority levels as 175 defined in [RFC4202]. 177 - Support link bundling of component links at the same line rate 178 and with same muxing hierarchy. 180 - Support for Tributary Slot Granularity (TSG) advertisement. 182 3. RSVP-TE requirements overview 184 [OTN-FWK] also provides a set of functional signaling requirements 185 summarized below : 187 - Support for LSP setup of new ODUk/ODUflex containers with 188 related mapping and multiplexing capabilities 190 - Support for LSP setup using different Tributary Slot granularity 192 - Support for Tributary Port Number allocation and negotiation 194 - Support for constraint signaling 196 - Support for TSG signaling 198 4. G.709 Digital Layer Info Model for Routing and Signaling 200 The digital OTN layered structure is comprised of digital path layer 201 networks (ODU) and digital section layer networks (OTU). An OTU 202 section layer supports one ODU path layer as client and provides 203 monitoring capability for the OCh. An ODU path layer may transport a 204 heterogeneous assembly of ODU clients. Some types of ODUs (i.e., 205 ODU1, ODU2, ODU3, ODU4) may assume either a client or server role 206 within the context of a particular networking domain. ITU-T G.872 207 recommendation provides two tables defining mapping and multiplexing 208 capabilities of OTNs, which are reproduced below. 210 +--------------------+--------------------+ 211 | ODU client | OTU server | 212 +--------------------+--------------------+ 213 | ODU 0 | - | 214 +--------------------+--------------------+ 215 | ODU 1 | OTU 1 | 216 +--------------------+--------------------+ 217 | ODU 2 | OTU 2 | 218 +--------------------+--------------------+ 219 | ODU 2e | - | 220 +--------------------+--------------------+ 221 | ODU 3 | OTU 3 | 222 +--------------------+--------------------+ 223 | ODU 4 | OTU 4 | 224 +--------------------+--------------------+ 225 | ODU flex | - | 226 +--------------------+--------------------+ 228 Figure 1: OTN mapping capability 230 +=================================+=========================+ 231 | ODU client | ODU server | 232 +---------------------------------+-------------------------+ 233 | 1,25 Gbps client | | 234 +---------------------------------+ ODU 0 | 235 | - | | 236 +=================================+=========================+ 237 | 2,5 Gbps client | | 238 +---------------------------------+ ODU 1 | 239 | ODU 0 | | 240 +=================================+=========================+ 241 | 10 Gbps client | | 242 +---------------------------------+ ODU 2 | 243 | ODU0,ODU1,ODUflex | | 244 +=================================+=========================+ 245 | 10,3125 Gbps client | | 246 +---------------------------------+ ODU 2e | 247 | - | | 248 +=================================+=========================+ 249 | 40 Gbps client | | 250 +---------------------------------+ ODU 3 | 251 | ODU0,ODU1,ODU2,ODU2e,ODUflex | | 252 +=================================+=========================+ 253 | 100 Gbps client | | 254 +---------------------------------+ ODU 4 | 255 |ODU0,ODU1,ODU2,ODU2e,ODU3,ODUflex| | 256 +=================================+=========================+ 257 |CBR clients from greater than | | 258 |2.5 Gbit/s to 100 Gbit/s: or | | 259 |GFP-F mapped packet clients from | ODUflex | 260 |1.25 Gbit/s to 100 Gbit/s. | | 261 +---------------------------------+ | 262 | - | | 263 +=================================+=========================+ 265 Figure 2: OTN multiplexing capability 267 How an ODUk connection service is transported within an operator 268 network is governed by operator policy. For example, the ODUk 269 connection service might be transported over an ODUk path over an 270 OTUk section, with the path and section being at the same rate as 271 that of the connection service (see Table 1). In this case, an 272 entire lambda of capacity is consumed in transporting the ODUk 273 connection service. On the other hand, the operator might exploit 274 different multiplexing capabilities in the network to improve 275 infrastructure efficiencies within any given networking domain. In 276 this case, ODUk multiplexing may be performed prior to transport over 277 various rate ODU servers (as per Table 2) over associated OTU 278 sections. 280 From the perspective of multiplexing relationships, a given ODUk may 281 play different roles as it traverses various networking domains. 283 As detailed in [OTN-FWK], client ODUk connection services can be 284 transported over: 286 o Case A) one or more wavelength sub-networks connected by optical 287 links or 289 o Case B) one or more ODU links (having sub-lambda and/or lambda 290 bandwidth granularity) 292 o Case C) a mix of ODU links and wavelength sub-networks. 294 This document considers the TE information needed for ODU path 295 computation and parameters needed to be signaled for LSP setup. 297 The following sections list and analyze each type of data that needs 298 to be advertised and signaled in order to support path computation 299 and LSP setup. 301 4.1. Tributary Slot Granularity 303 ITU-T recommendation defines two type of TS granularity. This TS 304 granularity is defined per layer, meaning that both ends of a link 305 can select proper TS granularity differently for each supported 306 layer, based on the rules below: 308 - If both ends of a link are new cards supporting both 1.25Gbps TS 309 and 2.5Gbps TS, then the link will work with 1.25Gbps TS. 311 - If one end is a new card supporting both the 1.25Gbps and 312 2,5Gbps TS, and the other end is an old card supporting just the 313 2.5Gbps TS, the link will work with 2.5Gbps TS. 315 4.1.1. Data Plane Considerations 317 4.1.1.1. Payload Type and TSG relationship 319 As defined in G.709 an ODUk container consist of an OPUk (Optical 320 Payload Unit) plus a specific ODUk Overhead (OH). OPUk OH 321 information is added to the OPUk information payload to create an 322 OPUk. It includes information to support the adaptation of client 323 signals. Within the OPUk overhead there is the payload structure 324 identifier (PSI) that includes the payload type (PT). The payload 325 type (PT) is used to indicate the composition of the OPUk signal. 326 When an ODUj signal is multiplexed into an ODUk, the ODUj signal is 327 first extended with frame alignment overhead and then mapped into an 328 Optical channel Data Tributary Unit (ODTU). Two different types of 329 ODTU are defined in G.709: 331 - ODTUjk ((j,k) = {(0,1), (1,2), (1,3), (2,3)}; ODTU01, ODTU12, 332 ODTU13 and ODTU23) in which an ODUj signal is mapped via the 333 asynchronous mapping procedure (AMP), defined in clause 19.5 of 334 G.709. 336 - ODTUk.ts ((k,ts) = (2,1..8), (3,1..32), (4,1..80)) in which a 337 lower order ODU (ODU0, ODU1, ODU2, ODU2e, ODU3, ODUflex) signal is 338 mapped via the generic mapping procedure (GMP), defined in clause 339 19.6 of G.709. 341 G.709 introduces also a logical entity, called ODTUGk, characterizing 342 the multiplexing of the various ODTU. The ODTUGk is then mapped into 343 OPUK. ODTUjk and ODTUk.ts signals are directly time-division 344 multiplexed into the tributary slots of an HO OPUk. 346 When PT is assuming value 20 or 21,together with OPUk type (K= 347 1,2,3,4), it is used to discriminate two different ODU multiplex 348 structure ODTUGx : 350 - Value 20: supporting ODTUjk only, 352 - Value 21: supporting ODTUk.ts or ODTUk.ts and ODTUjk. 354 The discrimination is needed for OPUk with K =2 or 3, since OPU2 and 355 OPU3 are able to support both the different ODU multiplex structures. 356 For OPU4 and OPU1, only one type of ODTUG is supported: ODTUG4 with 357 PT=21 and ODTUG1 with PT=20. (see table Figure 6).The relationship 358 between PT and TS granularity, is in the fact that the two different 359 ODTUGk discriminated by PT and OPUk are characterized by two 360 different TS granularities of the related OPUk, the former at 2.5 361 Gbps, the latter at 1.25Gbps. 363 In order to complete the picture, in the PSI OH there is also the 364 Multiplex Structure Identifier (MSI) that provides the information on 365 which tributary slots the different ODTUjk or ODTUk.ts are mapped 366 into the related OPUk. The following figure shows how the client 367 traffic is multiplexed till the OPUk layer. 369 +--------+ +------------+ 370 +----+ | !------| ODTUjk |-----Client 371 | | | ODTUGk | +-----.------+ 372 | |-----| PT=21 | . 373 | | | | +-----.------+ 374 | | | |------| ODTUk.TS |-----Client 375 |OPUk| +--------+ +------------+ 376 | | 377 | | +--------+ +------------+ 378 | | | |------| ODTUjk |-----Client 379 | |-----| | +-----.------+ 380 +----+ | ODTUGk | . 381 | PT=20 | +-----.------+ 382 | |------| ODTUjk |-----Client 383 +--------+ +------------+ 385 Figure 3: OTN client multiplexing 387 4.1.1.2. Fall-back procedure 389 SG15 ITU-T G.798 recommendation describes the so called PT=21-to- 390 PT=20 interworking process that explains how two equipments with 391 interfaces with different PayloadType, and hence different TS 392 granularity (1.25Gbps vs. 2.5Gbps), can be coordinated so to permit 393 the equipment with 1.25 TS granularity to adapt his TS allocation 394 accordingly to the different TS granularity (2.5Gbps) of a neighbor. 396 Therefore, in order to let the NE change TS granularity accordingly 397 to the nieghbour requirements, the AUTOpayloadtype needs to be set. 398 When both the neighbors (link or trail) have been configured as 399 structured, the payload type received in the overhead is compared to 400 the transmitted PT. If they are different and the transmitted PT=21, 401 the node must fallback to PT=20. In this case the fall-back process 402 makes the system self consistent and the only reason for signaling 403 the TS granularity is to provide the correct label (i.e. label for 404 PT=21 has twice the TS number of PT=20). On the other side, if the 405 AUTOpayloadtype is not configured, the RSVP-TE consequent actions in 406 case of TS mismatch need to be defined. 408 4.1.2. Control Plane considerations 410 When setting up an ODUj over an ODUk, it is possible to identify two 411 types of TSG, the server and the client one. The server TSG is used 412 to map an end to end ODUj onto a server ODUk LSP or links. This 413 parameter can not be influenced in any way from the ODUj LSP: ODUj 414 LSP will be mapped on tributary slots available on the different 415 links/ODUk LSPs. When setting up an ODUj at a given rate, the fact 416 that it is carried over a path composed by links/FAs structured with 417 1.25Gbps or 2.5Gbps TS size is completely transparent to the end to 418 end ODUj. 420 On the other side the client TSG is the tributary slot size that is 421 exported towards the client layer. The client TSG information is one 422 of the parameters needed to correctly select the adaptation towards 423 the client layers at the end nodes and this is the only thing that 424 the ODUj has to guarantee. When setting up an HO-ODUk/OTUk LSP or an 425 H-LSP/FA, in the case where the egress interface cannot be identified 426 from the ERO, it is necessary for the penultimate node to select an 427 interface on the egress node that supports the TSG and ODU client 428 hierarchy specified in signaling. It must then select an interface 429 on itself that can be paired with the interface it selected. 431 In figure 4 an example of client and server TSG utilization in a 432 scenario with mixed G.709 v2 and G.709 v3 interfaces is shown. 434 ODU1-LSP 435 ......................................... 436 TSG-C| |TSG-C 437 1.25| ODU2-H-LSP |1.25 438 +------------X--------------------------+ 439 | TSG-S| |TSG-S 440 | 2.5| |2.5 441 | | ODU3-H-LSP | 442 | |------------X-------------| 443 | | | 444 +--+--+ +--+--+ +---+-+ 445 | | | | +-+ +-+ | | 446 | A +------+ B +-----+ +***+ +-----+ Z | 447 | V.3 | OTU2 | V.2 |OTU3 +-+ +-+ OTU3| V.3 | 448 +-----+ +-----+ +-----+ 450 ... Service LSP 451 --- H-LSP 453 Figure 4: Client-Server TSG example 455 In this scenario, an ODU3 LSP is setup from node B to Z. Node B has 456 an old interface able to support 2.5 TSG granularity, hence only 457 client TSG equal to 2.5Gbps can be exported to ODU3 H-LSP possible 458 clients. An ODU2 LSP is setup from node A to node Z with client TSG 459 1.25 signaled and exported towards clients. The ODU2 LSP is carried 460 by ODU3 H-LSP from B to Z. Due to the limitations of old node B 461 interface, the ODU2 LSP is mapped with 2.5Gbps TSG over the ODU3 462 H-LSP. Then an ODU1 LSP is setup from A to Z, carried by the ODU2 463 H-LSP and mapped over it using a 1.25Gbps TSG. 465 What is shown in the example is that the TSG processing is a per 466 layer issue: even if the ODU3 H-LSP is created with TSG client at 467 2.5Gbps, the ODU2 H-LSP must guarantee a 1.25Gbps TSG client. ODU3 468 H-LSP is eligible from ODU2 LSP perspective since from the routing it 469 is known that this ODU3 interface at node Z, supports an ODU2 470 termination exporting a TSG 1.25/2.5. 472 Moreover, with respect to the penultimate hop implications let's 473 consider a further example in which the setup of an ODU3 path that is 474 going to carry an ODU0 is considered. In this case it is needed the 475 support of 1,25 GBps TS. The information related to the TSG is 476 carried in the signaling and node C, having two different interfaces 477 toward D with different TSGs, can choose the right one as depicted in 478 the following figure. In case the full ERO is provided in the 479 signaling with explicit interface declaration, there is no need for C 480 to choose the right interface as it has been already decided by the 481 ingress node or the PCE. 483 ODU0 484 ________________________________________ 485 | | 486 +--------+ +--------+ +--------+ +--------+ 487 | | | | | | 1.25 | | 488 | Node | | Node | | Node +------+ Node | 489 | A +------+ B +------+ C | ODU3 | D | 490 | | ODU3 | | ODU3 | +------+ | 491 +--------+ 1.25 +--------+ 2.5 +--------+ 2.5 +--------+ 493 Figure 5: TSG in signaling 495 The TSG information is needed also in the routing protocol as the 496 ingress node (A in the previous example) needs to know if the 497 interfaces between C and D can support the required TSG. In case 498 they cannot, A will compute an alternate path from itself to D. 500 In a multi-stage multiplexing environment any layer can have a 501 different TSG structure, e.g. in a multiplexing hierarchy like 502 ODU0->ODU2->ODU3, the ODU3 can be structured at TSG=2.5 in order to 503 support an ODU2 connection, but this ODU2 connection can be a tunnel 504 for ODU0, and hence structured with 1.25 TSG. Therefore any 505 multiplexing level has to advertise his TSG capabilities in order to 506 allow a correct path computation by the end nodes (both of the ODUk 507 trail and of the H-LSP/FA). 509 The following table shows the different mapping possibilities 510 depending on the TSG types. The client types are shown in the left 511 column, while the different OPUk server and related TSGs are listed 512 in the top row. The table also shows the relationship between the 513 TSG and the payload type. 515 +------------------------------------------------+ 516 | 2.5G TS || 1.25G TS | 517 | OPU2 | OPU3 || OPU1 | OPU2 | OPU3 | OPU4 | 518 +-------+------------------------------------------------+ 519 | | - | - || AMP | GMP | GMP | GMP | 520 | ODU0 | | || PT=20 | PT=21 | PT=21 | PT=21 | 521 +-------+------------------------------------------------+ 522 | | AMP | AMP || - | AMP | AMP | GMP | 523 | ODU1 | PT=20 | PT=20 || | PT=21 | PT=21 | PT=21 | 524 +-------+------------------------------------------------+ 525 | | - | AMP || - | - | AMP | GMP | 526 | ODU2 | | PT=20 || | | PT=21 | PT=21 | 527 +-------+------------------------------------------------+ 528 | | - | - || - | - | GMP | GMP | 529 | ODU2e | | || | | PT=21 | PT=21 | 530 +-------+------------------------------------------------+ 531 | | - | - || - | - | - | GMP | 532 | ODU3 | | || | | | PT=21 | 533 +-------+------------------------------------------------+ 534 | | - | - || - | GMP | GMP | GMP | 535 | ODUfl | | || | PT=21 | PT=21 | PT=21 | 536 +-------+------------------------------------------------+ 538 Figure 6: ODUj into OPUk mapping types 540 The signaled TSGs information is not enough to have a complete choice 541 since the penultimate hop node has to distinguish between interfaces 542 with the same TSG (e.g. 1.25Gbps) whether the interface is able to 543 support the right hierarchy, i.e. it is possible to have two 544 interfaces both at 1.25 TSG but only one is supporting ODU0. 546 A dedicated optional object could be defined in order to carry the 547 multiplexing hierarchy and adaptation information (i.e. TSG/PT, AMP/ 548 GMP) so to have a more precise choice capability. In this way, when 549 the penultimate node receives such object, together with the Traffic 550 Parameters Object, is allowed to choose the correct interface towards 551 the egress node. 553 In conclusion both routing and signaling will need to be extended to 554 appropriately represent the TSG/PT information. Routing will need to 555 represent a link's TSG and PT capabilities as well as the supported 556 multiplexing hierarchy. Signaling will need to represent the TSG/PT 557 and multiplexing hierarchy encoding. 559 4.2. Tributary Port Number 561 [RFC4328] supports only the deprecated auto-MSI mode which assumes 562 that the Tributary Port Number is automatically assigned in the 563 transmit direction and not checked in the receive direction. 565 As described in [G709-V3] and [G798-V3], the OPUk overhead in an OTUk 566 frame contains n (n = the total number of TSs of the ODUk) MSI 567 (Multiplex Structure Identifier) bytes (in the form of multi-frame), 568 each of which is used to indicate the association between tributary 569 port number and tributary slot of the ODUk. 571 The association between TPN and TS has to be configured by the 572 control plane and checked by the data plane on each side of the link. 573 (Please refer to [OTN-FWK] for further details). As a consequence, 574 the RSVP-TE signaling needs to be extended to support the TPN 575 assignment function. 577 4.3. Signal type 579 From a routing perspective, [RFC 4203] allows advertising foundation 580 G.709 (single TS type) without the capability of providing precise 581 information about bandwidth specific allocation. For example, in 582 case of link bundling, dividing the unreserved bandwidth by the MAX 583 LSP bandwidth it is not possible to know the exact number of LSPs at 584 MAX LSP bandwidth size that can be set up. (see example fig. 3) 586 The lack of spatial allocation heavily impacts the restoration 587 process, because the lack of information of free resources highly 588 increases the number of crank-backs affecting network convergence 589 time. 591 Moreover actual tools provided by OSPF-TE only allow advertising 592 signal types with fixed bandwidth and implicit hierarchy (e.g. SDH/ 593 SONET networks) or variable bandwidth with no hierarchy (e.g. packet 594 switching networks) but do not provide the means for advertising 595 networks with mixed approach (e.g. ODUflex CBR and ODUflex packet). 597 For example, advertising ODU0 as MIN LSP bandwidth and ODU4 as MAX 598 LSP bandwidth it is not possible to state whether the advertised link 599 supports ODU4 and ODUflex or ODU4, ODU3, ODU2, ODU1, ODU0 and 600 ODUflex. Such ambiguity is not present in SDH networks where the 601 hierarchy is implicit and flexible containers like ODUFlex do not 602 exist. The issue could be resolved by declaring 1 ISCD for each 603 signal type actually supported by the link. 605 Supposing for example to have an equivalent ODU2 unreserved bandwidth 606 in a TE-link (with bundling capability) distributed on 4 ODU1, it 607 would be advertised via the ISCD in this way: 609 MAX LSP Bw: ODU1 611 MIN LSP Bw: ODU1 613 - Maximum Reservable Bandwidth (of the bundle) set to ODU2 615 - Unreserved Bandwidth (of the bundle) set to ODU2 617 Moreover with the current IETF solutions, ([RFC4202], [RFC4203]) as 618 soon as no bandwidth is available for a certain signal type it is not 619 advertised into the related ISCD, losing also the related capability 620 until bandwidth is freed. 622 In conclusion, the OSPF-TE extensions defined in [RFC4203] require a 623 different ISCD per signal type in order to advertise each supported 624 container. This motivates attempting to look for a more optimized 625 solution, without proliferations of the number of ISCD advertised. 626 The OSPF LSA is required to stay within a single IP PDU; 627 fragmentation is not allowed. In a conforming Ethernet environment, 628 this limits the LSA to 1432 bytes (Packet_MTU (1500 Bytes) - 629 IP_Header (20 bytes) - OSPF_Header (28 bytes) - LSA_Header (20 630 bytes)). 632 With respect to link bundling, the utilization of the ISCD as it is, 633 would not allow precise advertising of spatial bandwidth allocation 634 information unless using only one component link per TE link. 636 On the other hand, from a singaling point of view, [RFC4328] 637 describes GMPLS signaling extensions to support the control for G.709 638 OTNs [G709-V1]. However,[RFC4328] needs to be updated because it 639 does not provide the means to signal all the new signal types and 640 related mapping and multiplexing functionalities. 642 4.4. Bit rate and tolerance 644 In the current traffic parameters signaling, bit rate and tolerance 645 are implicitly defined by the signal type. ODUflex CBR and Packet 646 can have variable bit rates and tolerances (please refer to [OTN-FWK] 647 table 2); it is thus needed to upgrade the signaling traffic 648 patameters so to specify requested bit rates and tolerance values 649 during LSP setup. 651 4.5. Unreserved Resources 653 Unreserved resources need to be advertised per priority and per 654 signal type in order to allow the correct functioning of the 655 restoration process. [RFC4203] only allows advertising unreserved 656 resources per priority, this leads not to know how many LSPs of a 657 specific signal type can be restored. As example it is possible to 658 consider the scenario depicted in the following figure. 660 +------+ component link 1 +------+ 661 | +------------------+ | 662 | | component link 2 | | 663 | N1 +------------------+ N2 | 664 | | component link 3 | | 665 | +------------------+ | 666 +------+ +---+--+ 668 Figure 7: Concurrent path computation 670 Suppose to have a TE link comprising 3 ODU3 component links with 671 32TSs available on the first one, 24TSs on the second, 24TSs on the 672 third and supporting ODU2 and ODU3 signal types. The node would 673 advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX 674 LSP bandwidth equal to 32 TSs. In case of restoration the network 675 could try to restore 2 ODU3 (64TSs) in such TE-link while only a 676 single ODU3 can be set up and a crank-back would be originated. In 677 more complex network scenarios the number of crank-backs can be much 678 higher. 680 4.6. Maximum LSP Bandwidth 682 Maximum LSP bandwidth is currently advertised in the common part of 683 the ISCD and advertised per priority, while in OTN networks it is 684 only required for ODUflex advertising. This leads to a significant 685 waste of bits inside each LSA. 687 4.7. Distinction between terminating and switching capability 689 The capability advertised by an interface needs further distinction 690 in order to separate termination and switching capabilities. Due to 691 internal constraints and/or limitations, the type of signal being 692 advertised by an interface could be just switched (i.e. forwarded to 693 switching matrix without multiplexing/demultiplexing actions), just 694 terminated (demuxed) or both of them. The following figures help 695 explainig the switching and terminating capabilities. 697 MATRIX LINE INTERFACE 698 +-----------------+ +-----------------+ 699 | +-------+ | ODU2 | | 700 ----->| ODU-2 |----|----------|--------\ | 701 | +-------+ | | +----+ | 702 | | | \__/ | 703 | | | \/ | 704 | +-------+ | ODU3 | | ODU3 | 705 ----->| ODU-3 |----|----------|------\ | | 706 | +-------+ | | \ | | 707 | | | \| | 708 | | | +----+ | 709 | | | \__/ | 710 | | | \/ | 711 | | | ---------> OTU-3 712 +-----------------+ +-----------------+ 714 Figure 8: Switching and Terminating capabilities 716 The figure in the example shows a line interface able to: 718 - Multiplex an ODU2 coming from the switching matrix into and ODU3 719 and map it into an OTU3 721 - Map an ODU3 coming from the switching matrix into an OTU3 723 In this case the interface bandwidth advertised is ODU2 with 724 switching capability and ODU3 with both switching and terminating 725 capabilities. 727 This piece of information needs to be advertised together with the 728 related unreserved bandwidth and signal type. As a consequence 729 signaling must have the possibility to setup an LSP allowing the 730 local selection of resources consistent with the limitations 731 considered during the path computation. 733 In figures 6 and 7 there are two examples of the need of termination/ 734 switching capability differentiation. In both examples all nodes are 735 supposed to support single-stage capability. The figure 6 addresses 736 a scenario in which a failure on link B-C forces node A to calculate 737 another ODU2 LSP path carrying ODU0 service along the nodes B-E-D. 738 Being D a single stage capable node, it is able to extract ODU0 739 service only from ODU2 interface. Node A has to know that from E to 740 D exists an available OTU2 link from which node D can extract the 741 ODU0 service. This information is required in order to avoid that 742 the OTU3 link is considered in the path computation. 744 ODU0 transparently transported 745 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 746 | ODU2 LSP Carrying ODU0 service | 747 | |'''''''''''''''''''''''''''''''''''''''''''| | 748 | | | | 749 | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | 750 ODU0 | | Link | | Link | | Link | | ODU0 751 ---->| A |_________| B |_________| C |_________| D |----> 752 | | | | | | | | 753 +-----+ +--+--+ +-----+ ++--+-+ 754 | | | 755 OTU3| | | 756 Link| +-----+__________________| | 757 | | | OTU3 Link | 758 |____| E | | 759 | |_____________________| 760 +-----+ OTU2 Link 762 Figure 9: Switching and Terminating capabilities - Example 1 764 Figure 7 addresses the scenario in which the restoration of the ODU2 765 LSP (ABCD) is required. The two bundled component links between B 766 and E could be used, but the ODU2 over the OTU2 component link can 767 only be terminated and not switched. This implies that it cannot be 768 used to restore the ODU2 LSP (ABCD). However such ODU2 unreserved 769 bandwidth must be advertised since it can be used for a different 770 ODU2 LSP terminating on E, e.g. (FBE). Node A has to know that the 771 ODU2 capability on the OTU2 link can only be terminated and that the 772 restoration of (ABCD) can only be performed using the ODU2 bandwidth 773 available on the OTU3 link. 775 ODU0 transparently transported 776 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 777 | ODU2 LSP Carrying ODU0 service | 778 | |'''''''''''''''''''''''''''''''''''''''''''| | 779 | | | | 780 | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | 781 ODU0 | | Link | | Link | | Link | | ODU0 782 ---->| A |_________| B |_________| C |_________| D |----> 783 | | | | | | | | 784 +-----+ ++-+-++ +-----+ +--+--+ 785 | | | | 786 OTU2| | | | 787 +-----+ Link| | | OTU3 +-----+ | 788 | | | | | Link | | | 789 | F |_______| | |___________| E |___________| 790 | | |_____________| | OTU2 Link 791 +-----+ OTU2 Link +-----+ 793 Figure 10: Switching and Terminating capabilities - Example 2 795 4.8. Priority Support 797 The IETF foresees that up to eight priorities must be supported and 798 that all of them have to be advertised independently on the number of 799 priorities supported by the implementation. Considering that the 800 advertisement of all the different supported signal types will 801 originate large LSAs, it is advised to advertise only the information 802 related to the really supported priorities. 804 4.9. Multi-stage multiplexing 806 With reference to the [OTN-FWK], introduction of multi-stage 807 multiplexing implies the advertisement of cascaded adaptation 808 capabilities together with the matrix access constraints. The 809 structure defined by IETF for the advertisement of adaptation 810 capabilities is ISCD/IACD as in [RFC4202] and [RFC5339]. 811 Modifications to ISCD/IACD, if needed, have to be addressed in the 812 releted encoding documents. 814 With respect to the routing, please note that in case of multi stage 815 muxing hierarchy (e.g. ODU1->ODU2->ODU3), not only the ODUk/OTUk 816 bandwidth (ODU3) and service layer bandwidth (ODU1) are needed, but 817 also the intermediate one (ODU2). This is a typical case of spatial 818 allocation problem. 820 Suppose in this scenario to have the following advertisement: 822 Hierarchy: ODU1->ODU2->ODU3 824 Number of ODU1==5 826 The number of ODU1 suggests that it is possible to have an ODU2 FA, 827 but it depends on the spatial allocation of such ODU1s. 829 It is possible that 2 links are bundled together and 3 830 ODU1->ODU2->ODU3 are available on a component link and 2 on the other 831 one, in such a case no ODU2 FA could be set up. The advertisement of 832 the ODU2 is needed because in case of ODU1 spatial allocation (3+2), 833 the ODU2 available bandwidth would be 0 (no ODU2 FA can be created), 834 while in case of ODU1 spatial allocation (4+1) the ODU2 available 835 bandwidth would be 1 (1 ODU2 FA can be created). 837 4.10. Generalized Label 839 The ODUk label format defined in [RFC4328] could be updated to 840 support new signal types defined in [G709-V3] but would hardly be 841 further enhanced to support possible new signal types. 843 Furthermore such label format may have scalability issues due to the 844 high number of labels needed when signaling large LSPs. For example, 845 when an ODU3 is mapped into an ODU4 with 1.25G tributary slots, it 846 would require the utilization of thirty-one labels (31*4*8=992 bits) 847 to be allocated while an ODUflex into an ODU4 may need up to eighty 848 labels (80*4*8=2560 bits). 850 A new flexible and scalable ODUk label format needs to be defined. 852 5. Security Considerations 854 This document provides a model of information needed by the routing 855 and signaling process in OTN networks. Such a model is very similar 856 from a security standpoint of the information that can be currently 857 conveyed via GMPLS routing protocols. For a general discussion on 858 MPLS- and GMPLS-related security issues, see the MPLS/GMPLS security 859 framework [RFC5920] 861 6. IANA Considerations 863 This informational document does not make any requests for IANA 864 action. 866 7. Contributors 868 Jonathan Sadler, Tellabs 870 EMail: jonathan.sadler@tellabs.com 872 John Drake, Juniper 874 EMail: jdrake@juniper.net 876 Francesco Fondelli 878 Ericsson 880 Via Moruzzi 1 882 Pisa - 56100 884 Email: francesco.fondelli@ericsson.com 886 8. Acknowledgements 888 The authors would like to thank Eve Varma and Sergio Lanzone for 889 their precious collaboration and review. 891 9. References 893 9.1. Normative References 895 [OTN-OSPF] 896 D.Ceccarelli,D.Caviglia,F.Zhang,D.Li,Y.Xu,P.Grandi,S.Belot 897 ti, "Traffic Engineering Extensions to OSPF for 898 Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN 899 Networks", work in 900 progress draft-ietf-ccamp-gmpls-ospf-g709-00, October 901 2011. 903 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 904 Requirement Levels", BCP 14, RFC 2119, March 1997. 906 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 907 (TE) Extensions to OSPF Version 2", RFC 3630, 908 September 2003. 910 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 911 Support of Generalized Multi-Protocol Label Switching 912 (GMPLS)", RFC 4202, October 2005. 914 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 915 of Generalized Multi-Protocol Label Switching (GMPLS)", 916 RFC 4203, October 2005. 918 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 919 Switching (GMPLS) Signaling Extensions for G.709 Optical 920 Transport Networks Control", RFC 4328, January 2006. 922 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 923 OSPF Opaque LSA Option", RFC 5250, July 2008. 925 [RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing 926 GMPLS Protocols against Multi-Layer and Multi-Region 927 Networks (MLN/MRN)", RFC 5339, September 2008. 929 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 930 Networks", RFC 5920, July 2010. 932 [RFC6107] Shiomoto, K. and A. Farrel, "Procedures for Dynamically 933 Signaled Hierarchical Label Switched Paths", RFC 6107, 934 February 2011. 936 9.2. Informative References 938 [G.709-v1] 939 ITU-T, "Interface for the Optical Transport Network 940 (OTN)", G.709 Recommendation (and Amendment 1), 941 February 2001. 943 [G.709-v2] 944 ITU-T, "Interface for the Optical Transport Network 945 (OTN)", G.709 Recommendation (and Amendment 1), 946 March 2003. 948 [G.709-v3] 949 ITU-T, "Rec G.709, version 3", approved by ITU-T on 950 December 2009. 952 [G.872-am2] 953 ITU-T, "Amendment 2 of G.872 Architecture of optical 954 transport networks for consent", consented by ITU-T on 955 June 2010. 957 [OTN-FWK] F.Zhang, D.Li, H.Li, S.Belotti, D.Ceccarelli, "Framework 958 for GMPLS and PCE Control of G.709 Optical Transport 959 Networks", work in 960 progress draft-ietf-ccamp-gmpls-g709-framework-05, 961 September 2011. 963 Authors' Addresses 965 Sergio Belotti (editor) 966 Alcatel-Lucent 967 Via Trento, 30 968 Vimercate 969 Italy 971 Email: sergio.belotti@alcatel-lucent.com 973 Pietro Vittorio Grandi 974 Alcatel-Lucent 975 Via Trento, 30 976 Vimercate 977 Italy 979 Email: pietro_vittorio.grandi@alcatel-lucent.com 981 Daniele Ceccarelli (editor) 982 Ericsson 983 Via A. Negrone 1/A 984 Genova - Sestri Ponente 985 Italy 987 Email: daniele.ceccarelli@ericsson.com 989 Diego Caviglia 990 Ericsson 991 Via A. Negrone 1/A 992 Genova - Sestri Ponente 993 Italy 995 Email: diego.caviglia@ericsson.com 996 Fatai Zhang 997 Huawei Technologies 998 F3-5-B R&D Center, Huawei Base 999 Shenzhen 518129 P.R.China Bantian, Longgang District 1000 Phone: +86-755-28972912 1002 Email: zhangfatai@huawei.com 1004 Dan Li 1005 Huawei Technologies 1006 F3-5-B R&D Center, Huawei Base 1007 Shenzhen 518129 P.R.China Bantian, Longgang District 1008 Phone: +86-755-28973237 1010 Email: danli@huawei.com