idnits 2.17.1 draft-ietf-ccamp-otn-g709-info-model-00.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 (April 18, 2011) is 4757 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3945' is mentioned on line 89, but not defined == Missing Reference: 'RFC3036' is mentioned on line 95, but not defined ** Obsolete undefined reference: RFC 3036 (Obsoleted by RFC 5036) == Missing Reference: 'RFC3212' is mentioned on line 95, but not defined == Missing Reference: 'RFC3209' is mentioned on line 95, but not defined == Missing Reference: 'RFC3471' is mentioned on line 96, but not defined == Missing Reference: 'RFC3473' is mentioned on line 100, but not defined == Missing Reference: 'G709-V3' is mentioned on line 592, but not defined == Missing Reference: 'OTN-RSVP' is mentioned on line 135, but not defined == Missing Reference: 'G.7715.1' is mentioned on line 161, but not defined == Missing Reference: 'G798-V3' is mentioned on line 340, but not defined == Missing Reference: 'RFC 4203' is mentioned on line 354, but not defined == Missing Reference: 'G709-V1' is mentioned on line 413, but not defined == Unused Reference: 'HIER-BIS' is defined on line 627, but no explicit reference was found in the text == Unused Reference: 'G.709-v1' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'G.709-v2' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'G.872-am2' is defined on line 682, 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: October 20, 2011 D. Ceccarelli, Ed. 6 D. Caviglia 7 Ericsson 8 F. Zhang 9 D. Li 10 Huawei Technologies 11 April 18, 2011 13 Information model for G.709 Optical Transport Networks (OTN) 14 draft-ietf-ccamp-otn-g709-info-model-00 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 October 20, 2011. 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 type . . . . . . . . . . . . . . . . . . . 8 68 4.2. Tributary Port Number . . . . . . . . . . . . . . . . . . 9 69 4.3. Signal type . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.4. Bit rate and tolerance . . . . . . . . . . . . . . . . . . 11 71 4.5. Unreserved Resources . . . . . . . . . . . . . . . . . . . 11 72 4.6. Maximum LSP Bandwidth . . . . . . . . . . . . . . . . . . 11 73 4.7. Distinction between terminating and switching 74 capability . . . . . . . . . . . . . . . . . . . . . . . . 12 75 4.8. Priority Support . . . . . . . . . . . . . . . . . . . . . 14 76 4.9. Multi-stage multiplexing . . . . . . . . . . . . . . . . . 14 77 4.10. Generalized Label . . . . . . . . . . . . . . . . . . . . 14 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 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 LSPs that span only interfaces recognizing 95 packet/cell boundaries is defined in [RFC3036, RFC3212, RFC3209]. 96 [RFC3471] presents a functional description of the extensions to 97 Multi-Protocol Label Switching (MPLS) signaling required to support 98 GMPLS. ReSource reserVation Protocol-Traffic Engineering (RSVP-TE) 99 -specific formats,mechanisms and technology specific details are 100 defined in [RFC3473]. 102 From a routing perspective, Open Shortest Path First-Traffic 103 Engineering (OSPF-TE) generates Link State Advertisements (LSAs) 104 carrying application-specific information and floods them to other 105 nodes as defined in [RFC5250]. Three types of opaque LSA are 106 defined, i.e. type 9 - link-local flooding scope, type 10 - area- 107 local flooding scope, type 11 - AS flooding scope. 109 Type 10 LSAs are composed of a standard LSA header and a payload 110 including one top-level TLV and possible several nested sub-TLVs. 111 [RFC3630] defines two top-level TLVs: Router Address TLV and Link 112 TLV; and nine possible sub-TLVs for the Link TLV, used to carry link 113 related TE information. The Link type sub-TLVs are enhanced by 114 [RFC4203] in order to support GMPLS networks and related specific 115 link information. In GMPLS networks each node generates TE LSAs to 116 advertise its TE information and capabilities (link-specific or node- 117 specific)through the network. The TE information carried in the LSAs 118 are collected by the other nodes of the network and stored into their 119 local Traffic Engineering Databases (TED). 121 In a GMPLS enabled G.709 Optical Transport Networks (OTN), routing 122 and signaling are fundamental in order to allow automatic calculation 123 and establishment of routes for ODUk LSPs. The recent revision of 124 ITU-T Recommendation G.709 [G709-V3] has introduced new fixed and 125 flexible ODU containers that augment those specified in foundation 126 OTN. As a result, it is necessary to provide OSPF-TE and RSVP-TE 127 extensions to allow GMPLS control of all currently defined ODU 128 containers. 130 This document provides the information model needed by the routing 131 and signaling processses in OTNs to allow GMPLS control of all 132 currently defined ODU containers. 134 OSPF-TE and RSVP-tE requirements are defined in [OTN-FWK], while 135 protocol extensions are defined in [OTN-OSPF] and [OTN-RSVP]. 137 1.1. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 2. OSPF-TE requirements overview 145 [OTN-FWK] provides a set of functional routing requirements 146 summarized below : 148 - Support for link multiplexing capability advertisement: The 149 routing protocol has to be able to carry information regarding the 150 capability of an OTU link to support different type of ODUs 152 - Support of any ODUk and ODUflex: The routing protocol must be 153 capable of carrying the required link bandwidth information for 154 performing accurate route computation for any of the fixed rate 155 ODUs as well as ODUflex. 157 - Support for differentiation between switching and terminating 158 capacity 160 - Support for the client server mappings as required by 161 [G.7715.1]. The list of different mappings methods is reported in 162 [G.709-v3]. Since different methods exist for how the same client 163 layer is mapped into a server layer, this needs to be captured in 164 order to avoid the set-up of connections that fail due to 165 incompatible mappings. 167 - Support different priorities for resource reservation. How many 168 priorities levels should be supported depends on operator 169 policies. Therefore, the routing protocol should be capable of 170 supporting either no priorities or up to 8 priority levels as 171 defined in [RFC4202]. 173 - Support link bundling either at the same line rate or different 174 line rates (e.g. 40G and 10G). Bundling links at different rates 175 makes the control plane more scalable and permits better 176 networking flexibility. 178 3. RSVP-TE requirements overview 180 [OTN-FWK] also provides a set of functional signaling requirements 181 summarized below : 183 - Support for LSP setup of new ODUk/ODUflex containers with 184 related mapping and multiplexing capabilities 186 - Support for LSP setup using different Tributary Slot granularity 188 - Support for Tributary Port Number allocation and negoziation 190 - Support for constraint signaling 192 4. G.709 Digital Layer Info Model for Routing and Signaling 194 The digital OTN layered structure is comprised of digital path layer 195 networks (ODU) and digital section layer networks (OTU). An OTU 196 section layer supports one ODU path layer as client and provides 197 monitoring capability for the OCh. An ODU path layer may transport a 198 heterogeneous assembly of ODU clients. Some types of ODUs (i.e., 199 ODU1, ODU2, ODU3, ODU4) may assume either a client or server role 200 within the context of a particular networking domain. ITU-T G.872 201 recommendation provides two tables defining mapping and multiplexing 202 capabilities of OTNs, which are reproduced below. 204 +--------------------+--------------------+ 205 | ODU client | OTU server | 206 +--------------------+--------------------+ 207 | ODU 0 | - | 208 +--------------------+--------------------+ 209 | ODU 1 | OTU 1 | 210 +--------------------+--------------------+ 211 | ODU 2 | OTU 2 | 212 +--------------------+--------------------+ 213 | ODU 2e | - | 214 +--------------------+--------------------+ 215 | ODU 3 | OTU 3 | 216 +--------------------+--------------------+ 217 | ODU 4 | OTU 4 | 218 +--------------------+--------------------+ 219 | ODU flex | - | 220 +--------------------+--------------------+ 222 Figure 1: OTN mapping capability 224 +=================================+=========================+ 225 | ODU client | ODU server | 226 +---------------------------------+-------------------------+ 227 | 1,25 Gbps client | | 228 +---------------------------------+ ODU 0 | 229 | - | | 230 +=================================+=========================+ 231 | 2,5 Gbps client | | 232 +---------------------------------+ ODU 1 | 233 | ODU 0 | | 234 +=================================+=========================+ 235 | 10 Gbps client | | 236 +---------------------------------+ ODU 2 | 237 | ODU0,ODU1,ODUflex | | 238 +=================================+=========================+ 239 | 10,3125 Gbps client | | 240 +---------------------------------+ ODU 2e | 241 | - | | 242 +=================================+=========================+ 243 | 40 Gbps client | | 244 +---------------------------------+ ODU 3 | 245 | ODU0,ODU1,ODU2,ODU2e,ODUflex | | 246 +=================================+=========================+ 247 | 100 Gbps client | | 248 +---------------------------------+ ODU 4 | 249 |ODU0,ODU1,ODU2,ODU2e,ODU3,ODUflex| | 250 +=================================+=========================+ 251 |CBR clients from greater than | | 252 |2.5 Gbit/s to 100 Gbit/s: or | | 253 |GFP-F mapped packet clients from | ODUflex | 254 |1.25 Gbit/s to 100 Gbit/s. | | 255 +---------------------------------+ | 256 | - | | 257 +=================================+=========================+ 259 Figure 2: OTN multiplexing capability 261 How an ODUk connection service is transported within an operator 262 network is governed by operator policy. For example, the ODUk 263 connection service might be transported over an ODUk path over an 264 OTUk section, with the path and section being at the same rate as 265 that of the connection service (see Table 1). In this case, an 266 entire lambda of capacity is consumed in transporting the ODUk 267 connection service. On the other hand, the operator might exploit 268 different multiplexing capabilities in the network to improve 269 infrastructure efficiencies within any given networking domain. In 270 this case, ODUk multiplexing may be performed prior to transport over 271 various rate ODU servers (as per Table 2) over associated OTU 272 sections. 274 From the perspective of multiplexing relationships, a given ODUk may 275 play different roles as it traverses various networking domains. 277 As detailed in [OTN-FWK], client ODUk connection services can be 278 transported over: 280 o Case A) one or more wavelength sub-networks connected by optical 281 links or 283 o Case B) one or more ODU links (having sub-lambda and/or lambda 284 bandwidth granularity) 286 o Case C) a mix of ODU links and wavelength sub-networks. 288 This document considers the TE information needed for ODU path 289 computation and parameters needed to be signaled for LSP setup. 291 The following sections list and analyze each type of data that needs 292 to be advertised and signaled in order to support path computation 293 and LSP setup. 295 4.1. Tributary Slot type 297 ITU-T recommendations define two types of TS but each link can only 298 support a single type at a given time. The rules to be followed when 299 selecting the TS to be used are: 301 - If both ends of a link can support both 2.5Gbps TS and 1.25Gbps 302 TS, then the link will work with 1.25Gbps TS. 304 - If one end can support the 1.25Gbps TS, and another end the 305 2.5Gbps TS, the link will work with 2.5Gbps TS. 307 In case the bandwidth accounting is provided in number of TSs, the 308 type of TS is needed to perform correct routing operations. 309 Currently such information is not provided by the routing protocol 310 and not taken into account during LSP signaling. 312 The tributary slot type information is one of the parameters needed 313 to correctly configure physical interfaces, therefore it has to be 314 signaled via RSVP-TE. This allows the end points of the FA knwo 315 which TS should be used. 317 [editor note]: SG15 ITU-T G.798 describes the so called PT=21-to- 318 PT=20 interworking process that explains how two equipments with 319 different PayloadType, and hence different TS granularity (1.25Gbps 320 vs. 2.5Gbps), can be coordinated so to permit the equipment with 1.25 321 TS granularity to adapt his TS allocation accordingly to the 322 different TS granularity (2.5Gbps) of a neighbour. Therefore, in 323 order to let the NE change TS granularity accordingly to the 324 nieghbour requirements, the AUTOpayloadtype needs to be configured 325 and the HO ODU source can be either not provisioned (i.e. TS not 326 allocated) or configured following a specific mapping depending of 327 the type of LO ODU carried. In this case the process of auto- 328 negotiation makes the system self consistent and the only reason for 329 signaling the TS granularity is to provide the correct label (i.e. 330 label for PT=21 has twice the TS number of PT=20). On the other 331 side, if the AUTOpayloadtype is not configured, the RSVP-TE 332 consequent actions in case of TS mismatch need to be defined. 334 4.2. Tributary Port Number 336 [RFC4328] supports only the deprecated auto-MSI mode which assumes 337 that the Tributary Port Number is automatically assigned in the 338 transmit direction and not checked in the receive direction. 340 As described in [G709-V3] and [G798-V3], the OPUk overhead in an OTUk 341 frame contains n (n = the total number of TSs of the ODUk) MSI 342 (Multiplex Structure Identifier) bytes (in the form of multi-frame), 343 each of which is used to indicate the association between tributary 344 port number and tributary slot of the ODUk. 346 The association between TPN and TS has to be configured by the 347 control plane and checked by the data plane on each side of the link. 348 (Please refer to [OTN-FWK] for further details). As a consequence, 349 the RSVP-TE signaling needs to be extended to support the TPN 350 assignment function. 352 4.3. Signal type 354 From a routing perspetive, [RFC 4203] allows advertising foundation 355 G.709 (single TS type) without the capability of providing precise 356 information about bandwidth specific allocation. For example, in 357 case of link bundling, dividing the unreserved bandwidth by the MAX 358 LSP bandwidth it is not possible to know the exact number of LSPs at 359 MAX LSP bandwidth size that can be set up. (see example fig. 3) 361 The lack of spatial allocation heavily impacts the restoration 362 process, because the lack of information of free resources highly 363 increases the number of crank-backs affecting network convergence 364 time. 366 Moreover actual tools provided by OSPF-TE only allow advertising 367 signal types with fixed bandwidth and implicit hierarchy (e.g. SDH/ 368 SONET networks) or variable bandwidth with no hierarchy (e.g. packet 369 switching networks) but do not provide the means for advertising 370 networks with mixed approach (e.g. ODUflex CBR and ODUflex packet). 372 For example, advertising ODU0 as MIN LSP bandwidth and ODU4 as MAX 373 LSP bandwidth it is not possible to state whether the advertised link 374 supports ODU4 and ODUflex or ODU4, ODU3, ODU2, ODU1, ODU0 and 375 ODUflex. Such ambiguity is not present in SDH networks where the 376 hierarchy is implicit and flexible containers like ODUFlex do not 377 exist. The issue could be resolved by declaring 1 ISCD for each 378 signal type actually supported by the link. 380 Supposing for example to have an equivalent ODU2 unreserved bandwidth 381 in a TE-link (with bundling capability) distributed on 4 ODU1, it 382 would be advertised via the ISCD in this way: 384 MAX LSP Bw: ODU1 386 MIN LSP Bw: ODU1 388 - Maximum Reservable Bandwidth (of the bundle) set to ODU2 390 - Unreserved Bandwidth (of the bundle) set to ODU2 392 Moreover with the current IETF solutions, ([RFC4202], [RFC4203]) as 393 soon as no bandwidth is available for a certain signal type it is not 394 advertised into the related ISCD, losing also the related capability 395 until bandwidth is freed. 397 In conclusion, the OSPF-TE extensions defined in [RFC4203] require a 398 different ISCD per signal type in order to advertise each supported 399 container. This motivates attempting to look for a more optimized 400 solution, without proliferations of the number of ISCD advertised. 401 The OSPF LSA is required to stay within a single IP PDU; 402 fragmentation is not allowed. In a conforming Ethernet environment, 403 this limits the LSA to 1432 bytes (Packet_MTU (1500 Bytes) - 404 IP_Header (20 bytes) - OSPF_Header (28 bytes) - LSA_Header (20 405 bytes)). 407 With respect to link bundling, the utilization of the ISCD as it is, 408 would not allow precise advertising of spatial bandwidth allocation 409 information unless using only one component link per TE link. 411 On the other hand, from a singaling point of view, [RFC4328] 412 describes GMPLS signaling extensions to support the control for G.709 413 OTNs [G709-V1]. However,[RFC4328] needs to be updated because it 414 does not provide the means to signal all the new signal types and 415 related mapping and multiplexing functionalities. 417 4.4. Bit rate and tolerance 419 In the current traffic parameters signaling, bit rate and tolerance 420 are implicitly defined by the signal type. ODUflex CBR and Packet 421 can have variable bit rates and tolerances (please refer to [OTN-FWK] 422 table 2); it is thus needed to upgrade the signaling traffic 423 patameters so to specify requested bit rates and tolerance values 424 during LSP setup. 426 4.5. Unreserved Resources 428 Unreserved resources need to be advertised per priority and per 429 signal type in order to allow the correct functioning of the 430 restoration process. [RFC4203] only allows advertising unreserved 431 resources per priority, this leads not to know how many LSPs of a 432 specific signal type can be restored. As example it is possible to 433 consider the scenario depicted in the following figure. 435 +------+ component link 1 +------+ 436 | +------------------+ | 437 | | component link 2 | | 438 | N1 +------------------+ N2 | 439 | | component link 3 | | 440 | +------------------+ | 441 +------+ +---+--+ 443 Figure 3: Concurrent path computation 445 Suppose to have a TE link comprising 3 ODU3 component links with 446 32TSs available on the first one, 24TSs on the second, 24TSs on the 447 third and supporting ODU2 and ODU3 signal types. The node would 448 advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX 449 LSP bandwidth equal to 32 TSs. In case of restoration the network 450 could try to restore 2 ODU3 (64TSs) in such TE-link while only a 451 single ODU3 can be set up and a crank-back would be originated. In 452 more complex network scenarios the number of crank-backs can be much 453 higher. 455 4.6. Maximum LSP Bandwidth 457 Maximum LSP bandwidth is currently advertised in the common part of 458 the ISCD and advertised per priority, while in OTN networks it is 459 only required for ODUflex advertising. This leads to a significant 460 waste of bits inside each LSA. 462 4.7. Distinction between terminating and switching capability 464 The capability advertised by an interface needs further distinction 465 in order to separate termination and switching capabilities. Due to 466 internal constraints and/or limitations, the type of signal being 467 advertised by an interface could be just switched (i.e. forwarded to 468 switching matrix without multiplexing/demultiplexing actions), just 469 terminated (demuxed) or both of them. The following figures help 470 explainig the switching and terminating capabilities. 472 MATRIX LINE INTERFACE 473 +-----------------+ +-----------------+ 474 | +-------+ | ODU2 | | 475 ----->| ODU-2 |----|----------|--------\ | 476 | +-------+ | | +----+ | 477 | | | \__/ | 478 | | | \/ | 479 | +-------+ | ODU3 | | ODU3 | 480 ----->| ODU-3 |----|----------|------\ | | 481 | +-------+ | | \ | | 482 | | | \| | 483 | | | +----+ | 484 | | | \__/ | 485 | | | \/ | 486 | | | ---------> OTU-3 487 +-----------------+ +-----------------+ 489 Figure 4: Switching and Terminating capabilities 491 The figure in the example shows a line interface able to: 493 - Multiplex an ODU2 coming from the switching matrix into and ODU3 494 and map it into an OTU3 496 - Map an ODU3 coming from the switching matrix into an OTU3 498 In this case the interface bandwidth advertised is ODU2 with 499 switching capability and ODU3 with both switching and terminating 500 capabilities. 502 This piece of information needs to be advertised together with the 503 related unreserved bandwidth and signal type. As a consequence 504 signaling must have the possibility to setup an LSP allowing the 505 local selection of resources consistent with the limitations 506 considered during the path computation. 508 In figures 6 and 7 there are two examples of the need of termination/ 509 switching capability differentiation. In both examples all nodes are 510 supposed to support single-stage capability. The figure 6 addresses 511 a scenario in which a failure on link B-C forces node A to calculate 512 another ODU2 LSP path carrying ODU0 service along the nodes B-E-D. 513 Being D a single stage capable node, it is able to extract ODU0 514 service only from ODU2 interface. Node A has to know that from E to 515 D exists an available OTU2 link from which node D can extract the 516 ODU0 service. This information is required in order to avoid that 517 the OTU3 link is considered in the path computation. 519 ODU0 transparently transported 520 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 521 | ODU2 LSP Carrying ODU0 service | 522 | |'''''''''''''''''''''''''''''''''''''''''''| | 523 | | | | 524 | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | 525 ODU0 | | Link | | Link | | Link | | ODU0 526 ---->| A |_________| B |_________| C |_________| D |----> 527 | | | | | | | | 528 +-----+ +--+--+ +-----+ ++--+-+ 529 | | | 530 OTU3| | | 531 Link| +-----+__________________| | 532 | | | OTU3 Link | 533 |____| E | | 534 | |_____________________| 535 +-----+ OTU2 Link 537 Figure 5: Switching and Terminating capabilities - Example 1 539 Figure 7 addresses the scenario in which the restoration of the ODU2 540 LSP (ABCD) is required. The two bundled component links between B 541 and E could be used, but the ODU2 over the OTU2 component link can 542 only be terminated and not switched. This implies that it cannot be 543 used to restore the ODU2 LSP (ABCD). However such ODU2 unreserved 544 bandwidth must be advertised since it can be used for a different 545 ODU2 LSP terminating on E, e.g. (FBE). Node A has to know that the 546 ODU2 capability on the OTU2 link can only be terminated and that the 547 restoration of (ABCD) can only be performed using the ODU2 bandwidth 548 available on the OTU3 link. 550 ODU0 transparently transported 551 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 552 | ODU2 LSP Carrying ODU0 service | 553 | |'''''''''''''''''''''''''''''''''''''''''''| | 554 | | | | 555 | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | 556 ODU0 | | Link | | Link | | Link | | ODU0 557 ---->| A |_________| B |_________| C |_________| D |----> 558 | | | | | | | | 559 +-----+ ++-+-++ +-----+ +--+--+ 560 | | | | 561 OTU2| | | | 562 +-----+ Link| | | OTU3 +-----+ | 563 | | | | | Link | | | 564 | F |_______| | |___________| E |___________| 565 | | |_____________| | OTU2 Link 566 +-----+ OTU2 Link +-----+ 568 Figure 6: Switching and Terminating capabilities - Example 2 570 4.8. Priority Support 572 The IETF foresees that up to eight priorities must be supported and 573 that all of them have to be advertised independently on the number of 574 priorities supported by the implementation. Considering that the 575 advertisement of all the different supported signal types will 576 originate large LSAs, it is advised to advertise only the information 577 related to the really supported priorities. 579 4.9. Multi-stage multiplexing 581 With reference to the [OTN-FWK], introduction of multi-stage 582 multiplexing implies the advertisement of cascaded adaptation 583 capabilities together with the matrix access constraints. The 584 structure defined by IETF for the advertisement of adaptation 585 capabilities is ISCD/IACD as in [RFC4202] and [RFC5339]. 586 Modifications to ISCD/IACD, if needed, have to be addressed in the 587 releted encoding documents. 589 4.10. Generalized Label 591 The ODUk label format defined in [RFC4328] could be updated to 592 support new signal types defined in [G709-V3] but would hardly be 593 further enhanced to support possible new signal types. 595 Furthermore such label format may have scalability issues due to the 596 high number of labels needed when signaling large LSPs. For example, 597 when an ODU3 is mapped into an ODU4 with 1.25G tributary slots, it 598 would require the utilization of thirty-one labels (31*4*8=992 bits) 599 to be allocated while an ODUflex into an ODU4 may need up to eighty 600 labels (80*4*8=2560 bits). 602 A new flexible and scalable ODUk label format needs to be defined. 604 5. Security Considerations 606 TBD 608 6. IANA Considerations 610 TBD 612 7. Contributors 614 Jonathan Sadler, Tellabs 616 EMail: jonathan.sadler@tellabs.com 618 8. Acknowledgements 620 The authors would like to thank Eve Varma and Sergio Lanzone for 621 their precious collaboration and review. 623 9. References 625 9.1. Normative References 627 [HIER-BIS] 628 K.Shiomoto, A.Farrel, "Procedure for Dynamically Signaled 629 Hierarchical Label Switched Paths", work in 630 progress draft-ietf-lsp-hierarchy-bis-08, February 2010. 632 [OTN-OSPF] 633 D.Ceccarelli,D.Caviglia,F.Zhang,D.Li,Y.Xu,P.Grandi,S.Belot 634 ti, "Traffic Engineering Extensions to OSPF for 635 Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN 636 Networks", work in 637 progress draft-ceccarelli-ccamp-gmpls-ospf-g709-03, August 638 2010. 640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 641 Requirement Levels", BCP 14, RFC 2119, March 1997. 643 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 644 (TE) Extensions to OSPF Version 2", RFC 3630, 645 September 2003. 647 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 648 Support of Generalized Multi-Protocol Label Switching 649 (GMPLS)", RFC 4202, October 2005. 651 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 652 of Generalized Multi-Protocol Label Switching (GMPLS)", 653 RFC 4203, October 2005. 655 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 656 Switching (GMPLS) Signaling Extensions for G.709 Optical 657 Transport Networks Control", RFC 4328, January 2006. 659 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 660 OSPF Opaque LSA Option", RFC 5250, July 2008. 662 [RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing 663 GMPLS Protocols against Multi-Layer and Multi-Region 664 Networks (MLN/MRN)", RFC 5339, September 2008. 666 9.2. Informative References 668 [G.709-v1] 669 ITU-T, "Interface for the Optical Transport Network 670 (OTN)", G.709 Recommendation (and Amendment 1), 671 February 2001. 673 [G.709-v2] 674 ITU-T, "Interface for the Optical Transport Network 675 (OTN)", G.709 Recommendation (and Amendment 1), 676 March 2003. 678 [G.709-v3] 679 ITU-T, "Rec G.709, version 3", approved by ITU-T on 680 December 2009. 682 [G.872-am2] 683 ITU-T, "Amendment 2 of G.872 Architecture of optical 684 transport networks for consent", consented by ITU-T on 685 June 2010. 687 [OTN-FWK] F.Zhang, D.Li, H.Li, S.Belotti, "Framework for GMPLS and 688 PCE Control of G.709 Optical Transport Networks", work in 689 progress draft-ietf-ccamp-gmpls-g709-framework-00, April 690 2010. 692 Authors' Addresses 694 Sergio Belotti (editor) 695 Alcatel-Lucent 696 Via Trento, 30 697 Vimercate 698 Italy 700 Email: sergio.belotti@alcatel-lucent.com 702 Pietro Vittorio Grandi 703 Alcatel-Lucent 704 Via Trento, 30 705 Vimercate 706 Italy 708 Email: pietro_vittorio.grandi@alcatel-lucent.com 710 Daniele Ceccarelli (editor) 711 Ericsson 712 Via A. Negrone 1/A 713 Genova - Sestri Ponente 714 Italy 716 Email: daniele.ceccarelli@ericsson.com 718 Diego Caviglia 719 Ericsson 720 Via A. Negrone 1/A 721 Genova - Sestri Ponente 722 Italy 724 Email: diego.caviglia@ericsson.com 725 Fatai Zhang 726 Huawei Technologies 727 F3-5-B R&D Center, Huawei Base 728 Shenzhen 518129 P.R.China Bantian, Longgang District 729 Phone: +86-755-28972912 731 Email: zhangfatai@huawei.com 733 Dan Li 734 Huawei Technologies 735 F3-5-B R&D Center, Huawei Base 736 Shenzhen 518129 P.R.China Bantian, Longgang District 737 Phone: +86-755-28973237 739 Email: danli@huawei.com