idnits 2.17.1 draft-ietf-ccamp-otn-g709-info-model-02.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 (October 28, 2011) is 4564 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3945' is mentioned on line 90, but not defined == Missing Reference: 'RFC3036' is mentioned on line 96, but not defined ** Obsolete undefined reference: RFC 3036 (Obsoleted by RFC 5036) == Missing Reference: 'RFC3212' is mentioned on line 96, but not defined == Missing Reference: 'RFC3209' is mentioned on line 96, but not defined == Missing Reference: 'RFC3471' is mentioned on line 97, but not defined == Missing Reference: 'RFC3473' is mentioned on line 101, but not defined == Missing Reference: 'G709-V3' is mentioned on line 762, but not defined == Missing Reference: 'OTN-RSVP' is mentioned on line 136, but not defined == Missing Reference: 'G.7715.1' is mentioned on line 162, but not defined == Missing Reference: 'G798-V3' is mentioned on line 488, but not defined == Missing Reference: 'RFC 4203' is mentioned on line 502, but not defined == Missing Reference: 'G709-V1' is mentioned on line 560, but not defined == Unused Reference: 'HIER-BIS' is defined on line 801, but no explicit reference was found in the text == Unused Reference: 'G.709-v1' is defined on line 842, but no explicit reference was found in the text == Unused Reference: 'G.709-v2' is defined on line 847, but no explicit reference was found in the text == Unused Reference: 'G.872-am2' is defined on line 856, but no explicit reference was found in the text -- No information found for draft-ietf-lsp-hierarchy-bis - is the name correct? == Outdated reference: A later version (-07) exists of draft-ceccarelli-ccamp-gmpls-ospf-g709-03 == Outdated reference: A later version (-15) exists of draft-ietf-ccamp-gmpls-g709-framework-00 Summary: 2 errors (**), 0 flaws (~~), 20 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: April 30, 2012 D. Ceccarelli, Ed. 6 D. Caviglia 7 Ericsson 8 F. Zhang 9 D. Li 10 Huawei Technologies 11 October 28, 2011 13 Information model for G.709 Optical Transport Networks (OTN) 14 draft-ietf-ccamp-otn-g709-info-model-02 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 April 30, 2012. 45 Copyright Notice 47 Copyright (c) 2011 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. Fall-back procedure . . . . . . . . . . . . . . . . . 12 69 4.2. Tributary Port Number . . . . . . . . . . . . . . . . . . 12 70 4.3. Signal type . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.4. Bit rate and tolerance . . . . . . . . . . . . . . . . . . 14 72 4.5. Unreserved Resources . . . . . . . . . . . . . . . . . . . 14 73 4.6. Maximum LSP Bandwidth . . . . . . . . . . . . . . . . . . 15 74 4.7. Distinction between terminating and switching 75 capability . . . . . . . . . . . . . . . . . . . . . . . . 15 76 4.8. Priority Support . . . . . . . . . . . . . . . . . . . . . 17 77 4.9. Multi-stage multiplexing . . . . . . . . . . . . . . . . . 17 78 4.10. Generalized Label . . . . . . . . . . . . . . . . . . . . 18 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 GMPLS[RFC3945] extends MPLS to include Layer-2 Switching (L2SC), 91 Time-Division Multiplexing (e.g., SONET/SDH, PDH, and OTN), 92 Wavelength (OCh, Lambdas) Switching and Spatial Switching (e.g., 93 incoming port or fiber to outgoing port or fiber). 95 The establishment of LSPs that span only interfaces recognizing 96 packet/cell boundaries is defined in [RFC3036, RFC3212, RFC3209]. 97 [RFC3471] presents a functional description of the extensions to 98 Multi-Protocol Label Switching (MPLS) signaling required to support 99 GMPLS. ReSource reserVation Protocol-Traffic Engineering (RSVP-TE) 100 -specific formats,mechanisms and technology specific details are 101 defined in [RFC3473]. 103 From a routing perspective, Open Shortest Path First-Traffic 104 Engineering (OSPF-TE) generates Link State Advertisements (LSAs) 105 carrying application-specific information and floods them to other 106 nodes as defined in [RFC5250]. Three types of opaque LSA are 107 defined, i.e. type 9 - link-local flooding scope, type 10 - area- 108 local flooding scope, type 11 - AS flooding scope. 110 Type 10 LSAs are composed of a standard LSA header and a payload 111 including one top-level TLV and possible several nested sub-TLVs. 112 [RFC3630] defines two top-level TLVs: Router Address TLV and Link 113 TLV; and nine possible sub-TLVs for the Link TLV, used to carry link 114 related TE information. The Link type sub-TLVs are enhanced by 115 [RFC4203] in order to support GMPLS networks and related specific 116 link information. In GMPLS networks each node generates TE LSAs to 117 advertise its TE information and capabilities (link-specific or node- 118 specific)through the network. The TE information carried in the LSAs 119 are collected by the other nodes of the network and stored into their 120 local Traffic Engineering Databases (TED). 122 In a GMPLS enabled G.709 Optical Transport Networks (OTN), routing 123 and signaling are fundamental in order to allow automatic calculation 124 and establishment of routes for ODUk LSPs. The recent revision of 125 ITU-T Recommendation G.709 [G709-V3] has introduced new fixed and 126 flexible ODU containers that augment those specified in foundation 127 OTN. As a result, it is necessary to provide OSPF-TE and RSVP-TE 128 extensions to allow GMPLS control of all currently defined ODU 129 containers. 131 This document provides the information model needed by the routing 132 and signaling processses in OTNs to allow GMPLS control of all 133 currently defined ODU containers. 135 OSPF-TE and RSVP-tE requirements are defined in [OTN-FWK], while 136 protocol extensions are defined in [OTN-OSPF] and [OTN-RSVP]. 138 1.1. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 2. OSPF-TE requirements overview 146 [OTN-FWK] provides a set of functional routing requirements 147 summarized below : 149 - Support for link multiplexing capability advertisement: The 150 routing protocol has to be able to carry information regarding the 151 capability of an OTU link to support different type of ODUs 153 - Support of any ODUk and ODUflex: The routing protocol must be 154 capable of carrying the required link bandwidth information for 155 performing accurate route computation for any of the fixed rate 156 ODUs as well as ODUflex. 158 - Support for differentiation between switching and terminating 159 capacity 161 - Support for the client server mappings as required by 162 [G.7715.1]. The list of different mappings methods is reported in 163 [G.709-v3]. Since different methods exist for how the same client 164 layer is mapped into a server layer, this needs to be captured in 165 order to avoid the set-up of connections that fail due to 166 incompatible mappings. 168 - Support different priorities for resource reservation. How many 169 priorities levels should be supported depends on operator 170 policies. Therefore, the routing protocol should be capable of 171 supporting either no priorities or up to 8 priority levels as 172 defined in [RFC4202]. 174 - Support link bundling of component links at the same line rate 175 and with same muxing hierarchy. 177 - Support for Tributary Slot Granularity (TSG) advertisement. 179 3. RSVP-TE requirements overview 181 [OTN-FWK] also provides a set of functional signaling requirements 182 summarized below : 184 - Support for LSP setup of new ODUk/ODUflex containers with 185 related mapping and multiplexing capabilities 187 - Support for LSP setup using different Tributary Slot granularity 189 - Support for Tributary Port Number allocation and negoziation 191 - Support for constraint signaling 193 - Support for TSG signaling 195 4. G.709 Digital Layer Info Model for Routing and Signaling 197 The digital OTN layered structure is comprised of digital path layer 198 networks (ODU) and digital section layer networks (OTU). An OTU 199 section layer supports one ODU path layer as client and provides 200 monitoring capability for the OCh. An ODU path layer may transport a 201 heterogeneous assembly of ODU clients. Some types of ODUs (i.e., 202 ODU1, ODU2, ODU3, ODU4) may assume either a client or server role 203 within the context of a particular networking domain. ITU-T G.872 204 recommendation provides two tables defining mapping and multiplexing 205 capabilities of OTNs, which are reproduced below. 207 +--------------------+--------------------+ 208 | ODU client | OTU server | 209 +--------------------+--------------------+ 210 | ODU 0 | - | 211 +--------------------+--------------------+ 212 | ODU 1 | OTU 1 | 213 +--------------------+--------------------+ 214 | ODU 2 | OTU 2 | 215 +--------------------+--------------------+ 216 | ODU 2e | - | 217 +--------------------+--------------------+ 218 | ODU 3 | OTU 3 | 219 +--------------------+--------------------+ 220 | ODU 4 | OTU 4 | 221 +--------------------+--------------------+ 222 | ODU flex | - | 223 +--------------------+--------------------+ 225 Figure 1: OTN mapping capability 227 +=================================+=========================+ 228 | ODU client | ODU server | 229 +---------------------------------+-------------------------+ 230 | 1,25 Gbps client | | 231 +---------------------------------+ ODU 0 | 232 | - | | 233 +=================================+=========================+ 234 | 2,5 Gbps client | | 235 +---------------------------------+ ODU 1 | 236 | ODU 0 | | 237 +=================================+=========================+ 238 | 10 Gbps client | | 239 +---------------------------------+ ODU 2 | 240 | ODU0,ODU1,ODUflex | | 241 +=================================+=========================+ 242 | 10,3125 Gbps client | | 243 +---------------------------------+ ODU 2e | 244 | - | | 245 +=================================+=========================+ 246 | 40 Gbps client | | 247 +---------------------------------+ ODU 3 | 248 | ODU0,ODU1,ODU2,ODU2e,ODUflex | | 249 +=================================+=========================+ 250 | 100 Gbps client | | 251 +---------------------------------+ ODU 4 | 252 |ODU0,ODU1,ODU2,ODU2e,ODU3,ODUflex| | 253 +=================================+=========================+ 254 |CBR clients from greater than | | 255 |2.5 Gbit/s to 100 Gbit/s: or | | 256 |GFP-F mapped packet clients from | ODUflex | 257 |1.25 Gbit/s to 100 Gbit/s. | | 258 +---------------------------------+ | 259 | - | | 260 +=================================+=========================+ 262 Figure 2: OTN multiplexing capability 264 How an ODUk connection service is transported within an operator 265 network is governed by operator policy. For example, the ODUk 266 connection service might be transported over an ODUk path over an 267 OTUk section, with the path and section being at the same rate as 268 that of the connection service (see Table 1). In this case, an 269 entire lambda of capacity is consumed in transporting the ODUk 270 connection service. On the other hand, the operator might exploit 271 different multiplexing capabilities in the network to improve 272 infrastructure efficiencies within any given networking domain. In 273 this case, ODUk multiplexing may be performed prior to transport over 274 various rate ODU servers (as per Table 2) over associated OTU 275 sections. 277 From the perspective of multiplexing relationships, a given ODUk may 278 play different roles as it traverses various networking domains. 280 As detailed in [OTN-FWK], client ODUk connection services can be 281 transported over: 283 o Case A) one or more wavelength sub-networks connected by optical 284 links or 286 o Case B) one or more ODU links (having sub-lambda and/or lambda 287 bandwidth granularity) 289 o Case C) a mix of ODU links and wavelength sub-networks. 291 This document considers the TE information needed for ODU path 292 computation and parameters needed to be signaled for LSP setup. 294 The following sections list and analyze each type of data that needs 295 to be advertised and signaled in order to support path computation 296 and LSP setup. 298 4.1. Tributary Slot Granularity 300 ITU-T recommendation defines two type of TS granularity. This TS 301 granularity is defined per layer, meaning that both ends of a link 302 can select proper TS granularity differently for each supported 303 layer, based on the rules below: 305 - If both ends of a link are new cards supporting both 1.25Gbps TS 306 and 2.5Gbps TS, then the link will work with 1.25Gbps TS. 308 - If one end is a new card supporting both the 1.25Gbps and 309 2,5Gbps TS, and the other end is an old card supporting just the 310 2.5Gbps TS, the link will work with 2.5Gbps TS. 312 When setting up an ODUj over an ODUk, it is possible to identify two 313 types of TSG, the server and the client one. The server TSG is used 314 to map an end to end ODUj onto a server ODUk LSP or links. This 315 parameter can not be influenced in any way from the ODUj LSP: ODUj 316 LSP will be mapped on tributary slots available on the different 317 links/ODUk LSPs. When setting up an ODUj at a given rate, the fact 318 that it is carried over a path composed by links/FAs structured with 319 1.25Gbps or 2.5Gbps TS size is completely transparent to the end to 320 end ODUj. 322 On the other side the client TSG is the tributary slot size that is 323 exported towards the client layer. The client TSG information is one 324 of the parameters needed to correctly select the adaptation towards 325 the client layers at the end nodes and this is the only thing that 326 the ODUj has to guarantee. When setting up an HO-ODUk/OTUk LSP or an 327 H-LSP/FA, in the case where the egress interface cannot be identified 328 from the ERO, it is necessary for the penultimate node to select an 329 interface on the egress node that supports the TSG and ODU client 330 hierarchy specified in signaling. It must then select an interface 331 on itself that can be paired with the interface it selected. 333 In figure 4 an example of client and server TSG utilization in a 334 scenario with mixed G.709 v2 and G.709 v3 interfaces is shown. 336 ODU1-LSP 337 ......................................... 338 TSG-C| |TSG-C 339 1.25| ODU2-H-LSP |1.25 340 +------------X--------------------------+ 341 | TSG-S| |TSG-S 342 | 2.5| |2.5 343 | | ODU3-H-LSP | 344 | |------------X-------------| 345 | | | 346 +--+--+ +--+--+ +---+-+ 347 | | | | +-+ +-+ | | 348 | A +------+ B +-----+ +***+ +-----+ Z | 349 | V.3 | OTU2 | V.2 |OTU3 +-+ +-+ OTU3| V.3 | 350 +-----+ +-----+ +-----+ 352 ... Service LSP 353 --- H-LSP 355 Figure 3: Client-Server TSG example 357 In this scenario, an ODU3 LSP is setup from node B to Z. Node B has 358 an old interface able to support 2.5 TSG granularity, hence only 359 client TSG equal to 2.5Gbps can be exported to ODU3 H-LSP possible 360 clients. An ODU2 LSP is setup from node A to node Z with client TSG 361 1.25 signaled and exported towards clients. The ODU2 LSP is carried 362 by ODU3 H-LSP from B to Z. Due to the limitations of old node B 363 interface, the ODU2 LSP is mapped with 2.5Gbps TSG over the ODU3 364 H-LSP. Then an ODU1 LSP is setup from A to Z, carried by the ODU2 365 H-LSP and mapped over it using a 1.25Gbps TSG. 367 What is shown in the example is that the TSG processing is a per 368 layer issue: even if the ODU3 H-LSP is created with TSG client at 369 2.5Gbps, the ODU2 H-LSP must guarantee a 1.25Gbps TSG client. ODU3 370 H-LSP is elegible from ODU2 LSP perspective since from the routing it 371 is known that this ODU3 interface at node Z, supports an ODU2 372 termination exporting a TSG 1.25/2.5. 374 Moreover, with respect to the penultimate hop implications let's 375 consider a further example in which the setup of an ODU3 path that is 376 going to carry an ODU0 is considered. In this case it is needed the 377 support of 1,25 GBps TS. The information related to the TSG is 378 carried in the signaling and node C, having two different interfaces 379 toward D with different TSGs, can choose the right one as depicted in 380 the following figure. In case the full ERO is provided in the 381 signaling with explicit interface declaration, there is no need for C 382 to choose the right interface as it has been already decided by the 383 ingress node or the PCE. 385 ODU0 386 ________________________________________ 387 | | 388 +--------+ +--------+ +--------+ +--------+ 389 | | | | | | 1.25 | | 390 | Node | | Node | | Node +------+ Node | 391 | A +------+ B +------+ C | ODU3 | D | 392 | | ODU3 | | ODU3 | +------+ | 393 +--------+ 1.25 +--------+ 2.5 +--------+ 2.5 +--------+ 395 Figure 4: TSG in signaling 397 The TSG information is needed also in the routing protocol as the 398 ingress node (A in the previous example) needs to know if the 399 interfaces between C and D can support the required TSG. In case 400 they cannot, A will compute an alternate path from itself to D. 402 In a multi-stage multiplexing environment any layer can have a 403 different TSG structure, e.g. in a multiplexing hierarchy like 404 ODU0->ODU2->ODU3, the ODU3 can be structured at TSG=2.5 in order to 405 support an ODU2 connection, but this ODU2 connection can be a tunnel 406 for ODU0, and hence structured with 1.25 TSG. Therefore any 407 multiplexing level has to advertise his TSG capabilities in order to 408 allow a correct path computation by the end nodes (both of the ODUk 409 trail and of the H-LSP/FA). 411 The following table shows the different mapping possibilities 412 depending on the TSG types. The client types are shown in the left 413 column, while the different OPUk server and related TSGs are listed 414 in the top row. The table also shows the relationship between the 415 TSG and the payload type. 417 +------------------------------------------------+ 418 | 2.5G TS || 1.25G TS | 419 | OPU2 | OPU3 || OPU1 | OPU2 | OPU3 | OPU4 | 420 +-------+------------------------------------------------+ 421 | | - | - || AMP | GMP | GMP | GMP | 422 | ODU0 | | || PT=20 | PT=21 | PT=21 | PT=21 | 423 +-------+------------------------------------------------+ 424 | | AMP | AMP || - | AMP | AMP | GMP | 425 | ODU1 | PT=20 | PT=20 || | PT=21 | PT=21 | PT=21 | 426 +-------+------------------------------------------------+ 427 | | - | AMP || - | - | AMP | GMP | 428 | ODU2 | | PT=20 || | | PT=21 | PT=21 | 429 +-------+------------------------------------------------+ 430 | | - | - || - | - | GMP | GMP | 431 | ODU2e | | || | | PT=21 | PT=21 | 432 +-------+------------------------------------------------+ 433 | | - | - || - | - | - | GMP | 434 | ODU3 | | || | | | PT=21 | 435 +-------+------------------------------------------------+ 436 | | - | - || - | GMP | GMP | GMP | 437 | ODUfl | | || | PT=21 | PT=21 | PT=21 | 438 +-------+------------------------------------------------+ 440 Figure 5: ODUj into OPUk mapping types 442 The signaled TSGs information is not enough to have a complete choice 443 since the penultimate hop node has to distinguish between interfaces 444 with the same TSG (e.g. 1.25Gbps) whether the interface is able to 445 support the right hierarchy, i.e. it is possible to have two 446 interfaces both at 1.25 TSG but only one is supporting ODU0. 448 A dedicated optional object could be defined in order to carry the 449 multiplexing hierarchy and adaptation information (i.e. TSG/PT, AMP/ 450 GMP) so to have a more precise choice capability. In this way, when 451 the penultimate node receives such object, together with the Traffic 452 Parameters Object, is allowed to choose the correct interface towards 453 the egress node. 455 In conclusion both routing and signaling will need to be extended to 456 appropriately represent the TSG/PT information. Routing will need to 457 represent a link's TSG and PT capabilities as well as the supported 458 multiplexing hierarchy. Signaling will need to represent the TSG/PT 459 and multiplexing hierarchy encoding. 461 4.1.1. Fall-back procedure 463 SG15 ITU-T G.798 recommendation describes the so called PT=21-to- 464 PT=20 interworking process that explains how two equipments with 465 interfaces with different PayloadType, and hence different TS 466 granularity (1.25Gbps vs. 2.5Gbps), can be coordinated so to permit 467 the equipment with 1.25 TS granularity to adapt his TS allocation 468 accordingly to the different TS granularity (2.5Gbps) of a neighbour. 470 Therefore, in order to let the NE change TS granularity accordingly 471 to the nieghbour requirements, the AUTOpayloadtype needs to be set. 472 When both the neighbors (link or trail) have been configured as 473 structured, the payload type received in the overhead is compared to 474 the transmitted PT. If they are different and the transmitted PT=21, 475 the node must fallback to PT=20. In this case the fall-back process 476 makes the system self consistent and the only reason for signaling 477 the TS granularity is to provide the correct label (i.e. label for 478 PT=21 has twice the TS number of PT=20). On the other side, if the 479 AUTOpayloadtype is not configured, the RSVP-TE consequent actions in 480 case of TS mismatch need to be defined. 482 4.2. Tributary Port Number 484 [RFC4328] supports only the deprecated auto-MSI mode which assumes 485 that the Tributary Port Number is automatically assigned in the 486 transmit direction and not checked in the receive direction. 488 As described in [G709-V3] and [G798-V3], the OPUk overhead in an OTUk 489 frame contains n (n = the total number of TSs of the ODUk) MSI 490 (Multiplex Structure Identifier) bytes (in the form of multi-frame), 491 each of which is used to indicate the association between tributary 492 port number and tributary slot of the ODUk. 494 The association between TPN and TS has to be configured by the 495 control plane and checked by the data plane on each side of the link. 496 (Please refer to [OTN-FWK] for further details). As a consequence, 497 the RSVP-TE signaling needs to be extended to support the TPN 498 assignment function. 500 4.3. Signal type 502 From a routing perspetive, [RFC 4203] allows advertising foundation 503 G.709 (single TS type) without the capability of providing precise 504 information about bandwidth specific allocation. For example, in 505 case of link bundling, dividing the unreserved bandwidth by the MAX 506 LSP bandwidth it is not possible to know the exact number of LSPs at 507 MAX LSP bandwidth size that can be set up. (see example fig. 3) 508 The lack of spatial allocation heavily impacts the restoration 509 process, because the lack of information of free resources highly 510 increases the number of crank-backs affecting network convergence 511 time. 513 Moreover actual tools provided by OSPF-TE only allow advertising 514 signal types with fixed bandwidth and implicit hierarchy (e.g. SDH/ 515 SONET networks) or variable bandwidth with no hierarchy (e.g. packet 516 switching networks) but do not provide the means for advertising 517 networks with mixed approach (e.g. ODUflex CBR and ODUflex packet). 519 For example, advertising ODU0 as MIN LSP bandwidth and ODU4 as MAX 520 LSP bandwidth it is not possible to state whether the advertised link 521 supports ODU4 and ODUflex or ODU4, ODU3, ODU2, ODU1, ODU0 and 522 ODUflex. Such ambiguity is not present in SDH networks where the 523 hierarchy is implicit and flexible containers like ODUFlex do not 524 exist. The issue could be resolved by declaring 1 ISCD for each 525 signal type actually supported by the link. 527 Supposing for example to have an equivalent ODU2 unreserved bandwidth 528 in a TE-link (with bundling capability) distributed on 4 ODU1, it 529 would be advertised via the ISCD in this way: 531 MAX LSP Bw: ODU1 533 MIN LSP Bw: ODU1 535 - Maximum Reservable Bandwidth (of the bundle) set to ODU2 537 - Unreserved Bandwidth (of the bundle) set to ODU2 539 Moreover with the current IETF solutions, ([RFC4202], [RFC4203]) as 540 soon as no bandwidth is available for a certain signal type it is not 541 advertised into the related ISCD, losing also the related capability 542 until bandwidth is freed. 544 In conclusion, the OSPF-TE extensions defined in [RFC4203] require a 545 different ISCD per signal type in order to advertise each supported 546 container. This motivates attempting to look for a more optimized 547 solution, without proliferations of the number of ISCD advertised. 548 The OSPF LSA is required to stay within a single IP PDU; 549 fragmentation is not allowed. In a conforming Ethernet environment, 550 this limits the LSA to 1432 bytes (Packet_MTU (1500 Bytes) - 551 IP_Header (20 bytes) - OSPF_Header (28 bytes) - LSA_Header (20 552 bytes)). 554 With respect to link bundling, the utilization of the ISCD as it is, 555 would not allow precise advertising of spatial bandwidth allocation 556 information unless using only one component link per TE link. 558 On the other hand, from a singaling point of view, [RFC4328] 559 describes GMPLS signaling extensions to support the control for G.709 560 OTNs [G709-V1]. However,[RFC4328] needs to be updated because it 561 does not provide the means to signal all the new signal types and 562 related mapping and multiplexing functionalities. 564 4.4. Bit rate and tolerance 566 In the current traffic parameters signaling, bit rate and tolerance 567 are implicitly defined by the signal type. ODUflex CBR and Packet 568 can have variable bit rates and tolerances (please refer to [OTN-FWK] 569 table 2); it is thus needed to upgrade the signaling traffic 570 patameters so to specify requested bit rates and tolerance values 571 during LSP setup. 573 4.5. Unreserved Resources 575 Unreserved resources need to be advertised per priority and per 576 signal type in order to allow the correct functioning of the 577 restoration process. [RFC4203] only allows advertising unreserved 578 resources per priority, this leads not to know how many LSPs of a 579 specific signal type can be restored. As example it is possible to 580 consider the scenario depicted in the following figure. 582 +------+ component link 1 +------+ 583 | +------------------+ | 584 | | component link 2 | | 585 | N1 +------------------+ N2 | 586 | | component link 3 | | 587 | +------------------+ | 588 +------+ +---+--+ 590 Figure 6: Concurrent path computation 592 Suppose to have a TE link comprising 3 ODU3 component links with 593 32TSs available on the first one, 24TSs on the second, 24TSs on the 594 third and supporting ODU2 and ODU3 signal types. The node would 595 advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX 596 LSP bandwidth equal to 32 TSs. In case of restoration the network 597 could try to restore 2 ODU3 (64TSs) in such TE-link while only a 598 single ODU3 can be set up and a crank-back would be originated. In 599 more complex network scenarios the number of crank-backs can be much 600 higher. 602 4.6. Maximum LSP Bandwidth 604 Maximum LSP bandwidth is currently advertised in the common part of 605 the ISCD and advertised per priority, while in OTN networks it is 606 only required for ODUflex advertising. This leads to a significant 607 waste of bits inside each LSA. 609 4.7. Distinction between terminating and switching capability 611 The capability advertised by an interface needs further distinction 612 in order to separate termination and switching capabilities. Due to 613 internal constraints and/or limitations, the type of signal being 614 advertised by an interface could be just switched (i.e. forwarded to 615 switching matrix without multiplexing/demultiplexing actions), just 616 terminated (demuxed) or both of them. The following figures help 617 explainig the switching and terminating capabilities. 619 MATRIX LINE INTERFACE 620 +-----------------+ +-----------------+ 621 | +-------+ | ODU2 | | 622 ----->| ODU-2 |----|----------|--------\ | 623 | +-------+ | | +----+ | 624 | | | \__/ | 625 | | | \/ | 626 | +-------+ | ODU3 | | ODU3 | 627 ----->| ODU-3 |----|----------|------\ | | 628 | +-------+ | | \ | | 629 | | | \| | 630 | | | +----+ | 631 | | | \__/ | 632 | | | \/ | 633 | | | ---------> OTU-3 634 +-----------------+ +-----------------+ 636 Figure 7: Switching and Terminating capabilities 638 The figure in the example shows a line interface able to: 640 - Multiplex an ODU2 coming from the switching matrix into and ODU3 641 and map it into an OTU3 643 - Map an ODU3 coming from the switching matrix into an OTU3 645 In this case the interface bandwidth advertised is ODU2 with 646 switching capability and ODU3 with both switching and terminating 647 capabilities. 649 This piece of information needs to be advertised together with the 650 related unreserved bandwidth and signal type. As a consequence 651 signaling must have the possibility to setup an LSP allowing the 652 local selection of resources consistent with the limitations 653 considered during the path computation. 655 In figures 6 and 7 there are two examples of the need of termination/ 656 switching capability differentiation. In both examples all nodes are 657 supposed to support single-stage capability. The figure 6 addresses 658 a scenario in which a failure on link B-C forces node A to calculate 659 another ODU2 LSP path carrying ODU0 service along the nodes B-E-D. 660 Being D a single stage capable node, it is able to extract ODU0 661 service only from ODU2 interface. Node A has to know that from E to 662 D exists an available OTU2 link from which node D can extract the 663 ODU0 service. This information is required in order to avoid that 664 the OTU3 link is considered in the path computation. 666 ODU0 transparently transported 667 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 668 | ODU2 LSP Carrying ODU0 service | 669 | |'''''''''''''''''''''''''''''''''''''''''''| | 670 | | | | 671 | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | 672 ODU0 | | Link | | Link | | Link | | ODU0 673 ---->| A |_________| B |_________| C |_________| D |----> 674 | | | | | | | | 675 +-----+ +--+--+ +-----+ ++--+-+ 676 | | | 677 OTU3| | | 678 Link| +-----+__________________| | 679 | | | OTU3 Link | 680 |____| E | | 681 | |_____________________| 682 +-----+ OTU2 Link 684 Figure 8: Switching and Terminating capabilities - Example 1 686 Figure 7 addresses the scenario in which the restoration of the ODU2 687 LSP (ABCD) is required. The two bundled component links between B 688 and E could be used, but the ODU2 over the OTU2 component link can 689 only be terminated and not switched. This implies that it cannot be 690 used to restore the ODU2 LSP (ABCD). However such ODU2 unreserved 691 bandwidth must be advertised since it can be used for a different 692 ODU2 LSP terminating on E, e.g. (FBE). Node A has to know that the 693 ODU2 capability on the OTU2 link can only be terminated and that the 694 restoration of (ABCD) can only be performed using the ODU2 bandwidth 695 available on the OTU3 link. 697 ODU0 transparently transported 698 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 699 | ODU2 LSP Carrying ODU0 service | 700 | |'''''''''''''''''''''''''''''''''''''''''''| | 701 | | | | 702 | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | 703 ODU0 | | Link | | Link | | Link | | ODU0 704 ---->| A |_________| B |_________| C |_________| D |----> 705 | | | | | | | | 706 +-----+ ++-+-++ +-----+ +--+--+ 707 | | | | 708 OTU2| | | | 709 +-----+ Link| | | OTU3 +-----+ | 710 | | | | | Link | | | 711 | F |_______| | |___________| E |___________| 712 | | |_____________| | OTU2 Link 713 +-----+ OTU2 Link +-----+ 715 Figure 9: Switching and Terminating capabilities - Example 2 717 4.8. Priority Support 719 The IETF foresees that up to eight priorities must be supported and 720 that all of them have to be advertised independently on the number of 721 priorities supported by the implementation. Considering that the 722 advertisement of all the different supported signal types will 723 originate large LSAs, it is advised to advertise only the information 724 related to the really supported priorities. 726 4.9. Multi-stage multiplexing 728 With reference to the [OTN-FWK], introduction of multi-stage 729 multiplexing implies the advertisement of cascaded adaptation 730 capabilities together with the matrix access constraints. The 731 structure defined by IETF for the advertisement of adaptation 732 capabilities is ISCD/IACD as in [RFC4202] and [RFC5339]. 733 Modifications to ISCD/IACD, if needed, have to be addressed in the 734 releted encoding documents. 736 With respect to the routing, please note that in case of multi stage 737 muxing hierarchy (e.g. ODU1->ODU2->ODU3), not only the ODUk/OTUk 738 bandwidth (ODU3) and service layer bandwidth (ODU1) are needed, but 739 also the intermediate one (ODU2). This is a typical case of spatial 740 allocation problem. 742 Suppose in this scenario to have the following advertisement: 744 Hierarchy: ODU1->ODU2->ODU3 746 Number of ODU1==5 748 The number of ODU1 suggests that it is possible to have an ODU2 FA, 749 but it depends on the spatial allocation of such ODU1s. 751 It is possible that 2 links are bundled together and 3 752 ODU1->ODU2->ODU3 are available on a component link and 2 on the other 753 one, in such a case no ODU2 FA could be set up. The advertisement of 754 the ODU2 is needed because in case of ODU1 spatial allocation (3+2), 755 the ODU2 available bandwidth would be 0 (no ODU2 FA can be created), 756 while in case of ODU1 spatial allocation (4+1) the ODU2 available 757 bandwidth would be 1 (1 ODU2 FA can be created). 759 4.10. Generalized Label 761 The ODUk label format defined in [RFC4328] could be updated to 762 support new signal types defined in [G709-V3] but would hardly be 763 further enhanced to support possible new signal types. 765 Furthermore such label format may have scalability issues due to the 766 high number of labels needed when signaling large LSPs. For example, 767 when an ODU3 is mapped into an ODU4 with 1.25G tributary slots, it 768 would require the utilization of thirty-one labels (31*4*8=992 bits) 769 to be allocated while an ODUflex into an ODU4 may need up to eighty 770 labels (80*4*8=2560 bits). 772 A new flexible and scalable ODUk label format needs to be defined. 774 5. Security Considerations 776 TBD 778 6. IANA Considerations 780 TBD 782 7. Contributors 784 Jonathan Sadler, Tellabs 786 EMail: jonathan.sadler@tellabs.com 788 John Drake, Juniper 790 EMail: jdrake@juniper.net 792 8. Acknowledgements 794 The authors would like to thank Eve Varma and Sergio Lanzone for 795 their precious collaboration and review. 797 9. References 799 9.1. Normative References 801 [HIER-BIS] 802 K.Shiomoto, A.Farrel, "Procedure for Dynamically Signaled 803 Hierarchical Label Switched Paths", work in 804 progress draft-ietf-lsp-hierarchy-bis-08, February 2010. 806 [OTN-OSPF] 807 D.Ceccarelli,D.Caviglia,F.Zhang,D.Li,Y.Xu,P.Grandi,S.Belot 808 ti, "Traffic Engineering Extensions to OSPF for 809 Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN 810 Networks", work in 811 progress draft-ceccarelli-ccamp-gmpls-ospf-g709-03, August 812 2010. 814 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 815 Requirement Levels", BCP 14, RFC 2119, March 1997. 817 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 818 (TE) Extensions to OSPF Version 2", RFC 3630, 819 September 2003. 821 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 822 Support of Generalized Multi-Protocol Label Switching 823 (GMPLS)", RFC 4202, October 2005. 825 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 826 of Generalized Multi-Protocol Label Switching (GMPLS)", 827 RFC 4203, October 2005. 829 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 830 Switching (GMPLS) Signaling Extensions for G.709 Optical 831 Transport Networks Control", RFC 4328, January 2006. 833 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 834 OSPF Opaque LSA Option", RFC 5250, July 2008. 836 [RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing 837 GMPLS Protocols against Multi-Layer and Multi-Region 838 Networks (MLN/MRN)", RFC 5339, September 2008. 840 9.2. Informative References 842 [G.709-v1] 843 ITU-T, "Interface for the Optical Transport Network 844 (OTN)", G.709 Recommendation (and Amendment 1), 845 February 2001. 847 [G.709-v2] 848 ITU-T, "Interface for the Optical Transport Network 849 (OTN)", G.709 Recommendation (and Amendment 1), 850 March 2003. 852 [G.709-v3] 853 ITU-T, "Rec G.709, version 3", approved by ITU-T on 854 December 2009. 856 [G.872-am2] 857 ITU-T, "Amendment 2 of G.872 Architecture of optical 858 transport networks for consent", consented by ITU-T on 859 June 2010. 861 [OTN-FWK] F.Zhang, D.Li, H.Li, S.Belotti, "Framework for GMPLS and 862 PCE Control of G.709 Optical Transport Networks", work in 863 progress draft-ietf-ccamp-gmpls-g709-framework-00, April 864 2010. 866 Authors' Addresses 868 Sergio Belotti (editor) 869 Alcatel-Lucent 870 Via Trento, 30 871 Vimercate 872 Italy 874 Email: sergio.belotti@alcatel-lucent.com 876 Pietro Vittorio Grandi 877 Alcatel-Lucent 878 Via Trento, 30 879 Vimercate 880 Italy 882 Email: pietro_vittorio.grandi@alcatel-lucent.com 884 Daniele Ceccarelli (editor) 885 Ericsson 886 Via A. Negrone 1/A 887 Genova - Sestri Ponente 888 Italy 890 Email: daniele.ceccarelli@ericsson.com 892 Diego Caviglia 893 Ericsson 894 Via A. Negrone 1/A 895 Genova - Sestri Ponente 896 Italy 898 Email: diego.caviglia@ericsson.com 900 Fatai Zhang 901 Huawei Technologies 902 F3-5-B R&D Center, Huawei Base 903 Shenzhen 518129 P.R.China Bantian, Longgang District 904 Phone: +86-755-28972912 906 Email: zhangfatai@huawei.com 907 Dan Li 908 Huawei Technologies 909 F3-5-B R&D Center, Huawei Base 910 Shenzhen 518129 P.R.China Bantian, Longgang District 911 Phone: +86-755-28973237 913 Email: danli@huawei.com