idnits 2.17.1 draft-bcg-ccamp-gmpls-ml-implications-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 document seems to lack a Security Considerations section. ** There are 8 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 4078 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3945' is mentioned on line 86, but not defined == Missing Reference: 'RFC5339' is mentioned on line 92, but not defined == Unused Reference: 'G.709' is defined on line 919, but no explicit reference was found in the text == Unused Reference: 'G.709-v3' is defined on line 923, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-ccamp-gmpls-ospf-g709v3-03 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group D. Ceccarelli, Ed. 3 Internet-Draft F. Fondelli 4 Intended status: Informational Ericsson 5 Expires: August 29, 2013 S. Belotti 6 D. Papadimitriou, Ed. 7 Alcatel-Lucent 8 February 25, 2013 10 Multi layer implications in GMPLS controlled networks 11 draft-bcg-ccamp-gmpls-ml-implications-04 13 Abstract 15 This document describes requirements for MRN application to multiple 16 hierarchies of technologies (e.g. OTN, SDH, ETH). For this purpose, 17 after summarizing MRN definitions, rationales and currently supported 18 applications, a problem statement is introduced together with its 19 implications on GMPLS routing and signaling. New functional 20 requirements are derived and MRN extensions required to address them 21 are identified. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 29, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. MLN and MRN networks: relationship and rationale . . . . . . . 3 60 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Applicability Scenarios . . . . . . . . . . . . . . . . . . . 8 64 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5.1. Multiple internal matrices with different inter-link 66 types . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 5.2. Multiple internal matrices with different inter-link 68 types and shared server layer capacity . . . . . . . . . . 12 69 5.3. Multistage multiplexing at different levels . . . . . . . 13 70 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 7. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 8. Missing information . . . . . . . . . . . . . . . . . . . . . 20 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 74 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 75 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 77 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 78 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 81 1. Introduction 83 Generalized MPLS (GMPLS) supports the control of multiple switching 84 technologies: packet switching, Layer-2 switching, TDM (Time-Division 85 Multiplexing) switching, wavelength switching, and fiber switching 86 ([RFC3945]). 88 The Interface Switching Capability concept has been defined for the 89 advertisement of the Switching Capabilities of the different 90 interfaces of a node [RFC4202], while in the context of Multi Region 91 Networks (MRN) the Interface Adjustment Capabiltiy concept has been 92 introduced [RFC5339] for the advertisement of adjustment capacity 93 within an hybrid node. 95 With the introduction of G709v3 networks, a new Switching Capability 96 (OTN-TDM) has been defined [OSPF-OTN] and the ISCD updated in order 97 to cope with the OTN specific multi stage multiplexing capabilities. 98 The new Switching Capability Specific Information (SCSI) field 99 provides information about the bandwidth availability at each layer 100 of the OTN hierarchy and about the operations that can be performed 101 on the different layers, in terms of termination and switching 102 capabilities. 104 These issues have been addressed in the OTN documents within the OTN 105 multi layer scope but need to be extended to MRNs, where the 106 termination of a hierarchical LSP leads to the need of properly 107 managing different switching capabilities and different adaptation 108 functions. 110 The scope of this document is to describe requirements when MRN is 111 applied to multiple hierarchies of technologies (OTN, SDH, ETH). For 112 this purpose, after summarizing MRN definitions, rationales and 113 currently supported applications, a problem statement is introduced 114 together with its implications on GMPLS routing and signaling. We 115 derive new functional requirements and determine the corresponding 116 MRN extensions that may be required to address them. 118 1.1. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 2. MLN and MRN networks: relationship and rationale 126 As per [RFC5212], the definition of MLNs and MRNs is as follows: 128 - MLN: "a Traffic Engineering (TE) domain comprising multiple data 129 plane switching layers either of the same ISC (e.g., TDM) or 130 different ISC (e.g., TDM and PSC) and controlled by a single GMPLS 131 control plane instance" 133 - MRN: "is defined as a TE domain supporting at least two 134 different switching types (e.g., PSC and TDM), either hosted on 135 the same device or on different ones, and under the control of a 136 single GMPLS control plane instance" 138 A network which is an MLN but not an MRN (i.e. multiple layers but a 139 single switching capability), like for example an OTN domain, can be 140 advertised via the utilization of the Interface Switching Capability 141 Descriptor (ISCD). The ISCD is defined in [RFC4202] and its 142 technology specific extensions (SCSI) are defined in different memos 143 depending on the technology, e.g. the OTN ones in [OSPF-OTN] and the 144 SDH ones in [RFC4203]. 146 On the other side MRNs (i.e. multiple layers with multiple switching 147 capabilities), like for example an OTN data plane (with one or more 148 layers) over a WDM data plane (with one or more layers) controlled by 149 a single GMPLS instance, need the utilization of an ISCD for each 150 technology and an Interface Adjustment Capability Descriptor (IACD) 151 [RFC6001] for the advertisement of the internal links providing 152 adjustment between the switching capabilities. A node able to 153 terminate data links (over the same interface) with different 154 switching capabilities is called hybrid node. [RFC5212]. For more 155 details please see Section 7. 157 Hybrid nodes have been introduced not only to address the case of 158 nodes able to switch/terminate LSPs from different switching 159 capability but also to perform for instance: 161 - Traffic-grooming: base GMPLS doesn't enable insertion of traffic 162 at an intermediate point along an established LSP, i.e., the 163 control plane limits the flexibility of nesting LSP only at the 164 head-end of the underlying LSP. MRN extensions enable to 165 multiplex and demultiplex e.g. PSC LSP into LSC LSP even if the 166 LSC LSP does not originate or end at the nodes where the PSC LSP 167 are multiplexed or demultiplexed. 169 - Transparent regeneration: enables certain nodes equipped with 170 PSC + LSC capability to regenerate the photonic signal without 171 interrupting the LSC LSP. This functionality enables to setup 172 end-to-end LSC even if certain intermediate nodes are being used 173 to regenerate the signal at the PSC level. 175 This means that MRN extends the node functionality beyond "terminate 176 or switch". 178 The central notion in MRN is "adjustment capability". Adjustment 179 capability assumes the availability of adjustment capacity or 180 adjustment pool at given SC (say SC Z, in the following). An 181 adjustment capability is the mean by mean which LSPs can be adapted/ 182 mapped from one SC X to SC Y via Z, translated from one SC X to SC Y 183 via Z or inserted (e.g., multiplexed or demultiplexed) from SC X to 184 SC Y via Z. Note that SC X value MAY be identical to SC Y value and 185 that SC Z value MAY be identical to SC X or Y value. 187 For instance, when referring to transparent regeneration SC X = LSC = 188 SC Y and SC Z = PSC and when referring to traffic grooming SC X = PSC 189 and SC Y = LSC and SC Z = resource pool enabling the insertion of 190 packet LSP into a lambda LSP. 192 Advertisement of adjustment capacity by a given node assumes the 193 functionality of adjustment is locally supported. 195 3. Problem Statement 197 The MRN architectural framework as specified in [RFC6001] models the 198 internal properties of the nodes by its internal switching 199 capabilities (referred to as resource pools) and their 200 interconnection, i.e. single and multiple pool models. However, it 201 assumed that i) the internals properties of (logical) resource pools 202 were left uncovered to external nodes, i.e., the technology specific 203 details composing pools were not part of the IACD advertisement, and 204 ii) the topology defined by the interconnection of resource pools is 205 not defining any cycle, i.e., resource pools were not meshed 206 (following the SC value hierarchy). 208 The below describes in more details the underlying consequences for 209 what concerns "routing" and "signaling". Note that beside listing 210 the SC that have an internal multiplexing / encapsulation tructure we 211 omit technology specific details to keep the problem description as 212 generic as possible and thus applicable to Ethernet (C-VID, S-VID, 213 I-SID, B-VID), SDH, OTN, and future technologies. 215 3.1. Routing 217 When referring to routing, two specific elements are to be 218 considered: representation (information) and exchange. The latter is 219 not different from any other information exchange detailed in GMPLS 220 RFCs; hence, not further discussed in the context of this document. 221 The former raises however the following point: how to represent the 222 relations between resource pools and their capabilities (beyond un/ 223 used capacity). 225 The example of Fig.1 is illustrative. A,B,C,D and E represent the 226 external interfaces of the node, while W,X,Y and Z the internal 227 switching capacities. If the internal switching capabilities are 228 associated to the same SC (SC W = SC X = SC Y = SC Z), they could 229 either be represented as a single (logical) resource pool or be kept 230 separated into different resource pools at the condition that their 231 ingress and egress relations does not lead to any loop, i.e., there 232 is no "X-Y" direct relationship. 234 ***A*******B*C*D*** 235 * | | | | * 236 * | | | W * 237 * | | | | * 238 * | / \|/ * 239 * | XxxxY * 240 * | | / | * 241 * ---- Z | * 242 * \ / * 243 * | * 244 ***********E******* 246 Figure 1: Problem statement - Routing 248 Moreover, assuming that X and Y are part of the same logical resource 249 pool (SC X = SC Y) but different from the two others, the properties 250 of the two relationships between the resource pool (associated to SC 251 Z) and the upper one (SC X = SC Y) may be not identical. In 252 particular, the encoding associated to each relationship can be 253 different (while there is only one encoding field per IACD sub-TLV), 254 for example we could have an L2SC (for SC Z) with two different 255 encapsulation method GFP-F or GFP-T towards common resource pool TDM 256 (= SC X = SC Y). 258 3.2. Signaling 260 Initially GMPLS signaling relies on link property inference for label 261 allocation. This technique has been progressively complemeted by 262 technology specific information encoded as part of the label request. 263 In the present case, multiplexing hierarchies are interconnected but 264 there is no (TE) link describing these interconnections. Hence, a 265 mechanism is to be found by which the relationships between them have 266 to be locally accommodated at provisioning time. 268 ***A*******B*C*D*** 269 * | | | | * 270 * | | | W * 271 * | | | | * 272 * | / \|/ * 273 * | X Y * 274 * | | / | * 275 * ---- Z | * 276 * \ / * 277 * | * 278 ***********E******* 280 Figure 2: Problem statement - Signaling 282 The case depicted in the above Figure 2 provides a simple 283 illustration. Let's assume that X, Y, and Z are internal switching 284 capabilities each defining a multiplexing structure. Let's further 285 consider that X and Z are part of the same logical resource pool (SC 286 X = SC Z). Hence, an external node receives the routing information 287 from which it can derive as depicted in Fig.3 the relations between 288 i) resource pools O, W, Y and ii) resource pools O, W, Y and 289 "external" interfaces A, B, C, D, E. 291 ***A*******B*C*D*** 292 * | | | | * 293 * | | | W * 294 * | | | | * 295 * | / \|/ * 296 * -----O - Y * 297 * \ / * 298 * | * 299 ***********E******* 301 Figure 3: Problem statement - Relationship between resource pools 303 There are four ways to reach interface (I/F) B from I/F E: 304 E->O->Y->B, E->Y->O->B, E->O->B, E->Y->B. Hence, each time there is 305 possible choice to pass from one SC to another SC (which is not 306 associated to an "external" interface), there should be a mean by 307 which the requester can indicate which SC it would like to make use 308 of or equivalently exclude. In the present case, needs to have the 309 mean by which it can select if the incoming/outgoing signal will go 310 through O or Y. MRN signaling (see Section 4.1 of RFC 6001) enables 311 such choice but only if SC O =/= SC Y. 313 In other terms, MRN signaling provides the mean to prevent selection/ 314 exclude certain SC (see Section 4.1 of RFC 6001) along signaled path, 315 but it doesn't allow to select among two resource pools associated to 316 the same SC. 318 4. Applicability Scenarios 320 When moving from OTN MLNs to general MRNs, the multiplexing tree 321 concept introduced in [OSPF-OTN] needs to be extended so to take into 322 account both different switching capabilities within the same muxing 323 tree and adaptations between client hierarchies and server 324 hierarchies. 326 In the following figure an example of muxing tree supporting TDM, 327 PSC, OTN-TDM and LSC hierarchies mixed together is shown. 329 VC-4 330 | 331 ODU1 STM-16 PSC L2SC 332 | | | | 333 | | | | 334 ODU2 ODU2 ODU1 | 335 \ \ / / 336 \ \ / / 337 \ \ / / 338 \ \ / / 339 \ \/ / 340 \_ _ODU3__/ 341 | 342 OCh 344 Figure 4: Muxing tree 346 As it is possible to understand from the figure above, an MRN 347 equipment can host a variety of client-server relationships. Four 348 different scenarios can be identified: 350 - A signal type X is a client to a Signal type Y (1:1) - e.g. 351 Ethernet over WDM 353 - A signal type X is a client to a Intra switching technology 354 Hierarchy Y (1:N) - e.g. Ethernet over OTN 356 - An Intra switching technology Hierarchy X is a client to a 357 Signal Type Y (M:1) - e.g. ODU over WDM 358 - An Intra switching technology Hierarchy X is a client to an 359 Intra switching technology Hierarchy Y (M:N) - e.g. SDH over OTN 361 Being the first three scenarios a particular case of the fourth one, 362 in the following only the general case of M:N relationship will be 363 addressed. 365 This kind of client-server hierarchy can be achieved, depending on 366 the impelemntation, via single board or a cascade of them. In the 367 latter case boards are connected via internal links, which can be 368 either intra or inter switching capaility (e.g. ODU2->ODU3 or 369 PSC->LSC). Those links should not be modeled as external TE links, 370 but there is the need to advertise their characteristics and 371 availability in terms of bandwidth and optical parameters. 373 +--------------------------------------------------------+ 374 | +------------+ Eth +------------+ | 375 | | | | | | | 376 | OTU-1 +----+ | | +----+ | | 377 | +----+ | | +--> + | | | 378 | | 8 | | | 4 | | | 379 | OTU-1 |ODU1+------+| |ODU2+------+| OTU-3 | 380 | +----+ |ODU-2 |..........>+ |ODU-3 |+----------|--> 381 | | +------+|Internal | +------+| | 382 | OTU-1| | |Physical | | | | 383 | +----+ | | Link + | | | 384 | +----+ | (OTU-2) +----+ | | 385 | | | | | | 386 | +------------+ +------------+ | 387 +--------------------------------------------------------+ 389 Figure 5: Cascaded muxponder 391 Moreover, as described in [RFC5212], in a hybrid node there is the 392 need to take into account also the node's internal adjustment 393 capabilities between the switching technologies supported. An 394 example of hybrid node with different switching matrices is shown in 395 the following figure, where both an SDH and OTN matrix are available 396 and the two switching elements are internally interconnected so that 397 it is possible to terminate some resources (e.g. OTN interface Y1) 398 or provide adjustment for the SDH traffic (e.g. OTN interface Y2 399 toward the SDH matrix). In addition to the internal links between 400 matrices it is possible to have internal links between matrices and 401 cascaded cards for the creation of the muxing hierarchy. In the 402 example below both the SDH and OTN matrices are client to an 403 ODU2->ODU3 muxponder (through interfaces Y4 and Y5), which in turn is 404 client to an OCh WSS. 406 | 10GbE 407 +-------------------------+-------------+ 408 | | | 409 | | | 410 +-+ | +---------+ | | 411 |X| | X1 | | | | 412 __+-+__|__________| \ / | | | 413 | ` \/ | X3 | | 414 | X2 | /\ '''| | ODU2 | 415 | |''''' / \ | | | Y6+---+ | +---------+ 416 | | | +---+ | | +---+ | | | | 417 | | | |SDH| + | Y5 | | ODU3| | | 418 | | |__+---+__| +-----+ +----+| | | 419 | | | | || OTU3/OCH| +---+ | 420 | | | | ++----------+ |WSS| +--- 421 | | Y4 | | || Y7 | +---+ |Y8 422 | | +----------+ ...... +----+| | | 423 +-+ | | | \ / | | ___| |+--+ | | | 424 |Y| | |Y2 | \/ | | | +---+|OT| | | | 425 +-+ | .....| /\ |Y3| | +--+ | +---------+ 426 -------+----------+ / \ | | | | 427 | Y1 | .... | | 428 | | +---+ | | + | 429 | | |OTN| | | ODU2 | 430 | |__+---+___| | 431 +---------------------------------------+ 433 Figure 6: Hybrid node with optical muxponder and different switching 434 matrices 436 5. Use Cases 438 5.1. Multiple internal matrices with different inter-link types 439 PT21 440 +-----------+ `-.._ OTU2 +------------+ 441 '''' TDM | | `-+.._+ NRZ,RS-FEC | | 442 | Switch#1 +----+ +---+ | _:----------------| | 443 '''' | | | |.+-' | | 444 +-----------+ |.-' | | 445 | | 446 PT20 `-.._ OTU3,coherent, | | 447 | | `-+.._+ HD-FEC | | 448 .' ---+ | _-----------------| LSC | 449 +-----------+ .' | | |.+-' | Switch | 450 '''| TDM .' |.-' | | 451 | Switch#2 `. `-.._ OTU3 ,coherent_| |OTS line 452 '''| | `. | | `-+.._+ SD-FEC | +-------- 453 +-----------+ `. +---+ | _:----------------| | 454 | | |.+-' | | 455 OTU,Eth, PT21|.-' | | 456 FC, SDH, Sonet | | 457 lines as input `-.._ OTU4, coherent,| | 458 PT21| | `-+.._+ HD-FEC | | 459 .' +---+ | _:----------------| | 460 +-----------+ .' | | |.+-' | | 461 '''| TDM |' |.-' | | 462 | Switch#3 | UTU2 , NRZ | | 463 '''| | `. | | |-+.._+ RS-FEC | | 464 +-----------+ `. +---+ | _:----------------| | 465 PT21| | |.+-' | | 466 |.-' +------------+ 468 Figure 7: Multiple internal matrices with different inter-link types 470 A single IACD sub-TLV is associated to describe all the 1:1 471 relationships TDM_i (i = 1,2,3) - LSC. 473 When TDM-LSC has multiple relations, the following alternatives are 474 possible: 476 - the IACD sub-TLV aggregates information (assuming multiple LSP 477 encodings could be listed in a single IACD sub-TLV) 479 - a dedicated IACD sub-TLV describes each 1:1 relation TDM_ij - 480 LSC (i=1,2,3; j=1,2) 482 Note: one ISCD sub-TLV is associated to each TDM_i interface (left 483 part of the figure) or a single ISCD sub-TLV (bundle) can describe 484 all TDM interfaces 486 5.2. Multiple internal matrices with different inter-link types and 487 shared server layer capacity 489 PT21 490 +-----------+ `-.._ OTU2 +------------+ 491 '''' OTN | | `-+.._+ NRZ,RS-FEC | | 492 | Switch#1 \----+ +---+ | _:----------------| | 493 '''' |\ | | |.+-' | | 494 +-----------\ \ |.-' | | 495 | \ PT20 | | 496 \ \`-.._ OTU3,coherent, | | 497 \ + | `-+.._+ HD-FEC | | 498 |.' ---+ | _-----------------| LSC | 499 +-----------+ .\ | | |.+-' | Switch | 500 '''| SDH .' \|.-' | | 501 | Switch#2 `. |-..PT21 OTU3 ,coherent_| |OTS line 502 '''| | `. + | `-+.._+ SD-FEC | +-------- 503 +-----------+ +-- +---+ | _:----------------| | 504 | | .' |.+-' | | 505 OTU,Eth, | .-' | | 506 FC, SDH, Sonet +-++ | | 507 lines as inp / \ +| | 508 +---+--+GFP-F | | 509 | | | 510 +-----------+ | + | | 511 '''| Ethernet '''| | | 512 | Switch#3 | `. OTU4,coherent | | 513 '''| | | `-. `-+.._+ HD-FEC | | 514 +----------- `.. . +---+ | _:----------------| | 515 | +-+ | |.+-' | | 516 GFP-T | | |.-' +------------+ 517 |-' PT21 519 Figure 8: Multiple internal matrices with different inter-link types 520 and shared server layer capacity 522 + Like in the previous example, a single IACD sub-TLV is associated 523 that describes each 1:1 relation (i.e., OTN_i-LSC, ETH_i -LSC) (note 524 that in this figure i=1). 526 The 1:N relation between the LSC switch and the SDH - OTN - ETH 527 switches is decomposed as follows: 529 - A single IACD sub-TLV describes the 1:1 relation between the LSC 530 switch and the PTx 532 - A single IACD sub-TLV describes the 1:1 relation between the PTx 533 and the ETH, SDH, or OTN switch (one single IACD sub-TLV 534 independently from the number of legs between the switches and 535 PTx) 537 If the hub-and-spoke/star relationships is limited and the PTx 538 capability "static", then each OTN-LSC, SDH-LSC, ETH-LSC 1:1 539 relationship can be described by a dedicated IACD sub-TLV (like in 540 Fig.1). 542 Note_2: one ISCD sub-TLV is associated to each ETH, SDH, OTN 543 interfaces (left part of the figure) 545 5.3. Multistage multiplexing at different levels 546 +------------+ 547 | | 548 | | 549 | | 550 | | 551 PT20 | | 552 | `-.._ OTU3,coherent, | | 553 | OTN/FC/SDH/ETH + | `-+.._+ HD-FEC | | 554 | client ' ---+ | _-----------------| LSC | 555 +--------------------+ | |.+-' | Switch | 556 +--. |.-' | | 557 | | `-. `-+.._ |-..PT21 OTU3 ,coherent_| |OTS line 558 +-- +---+ | _-----+ | `-+.._+ SD-FEC | +-------- 559 +-+ | |.+-' - +---+ | _:----------------| | 560 | |.-' | .' |.+-' | | 561 ' PT21 .-' | | 562 ETH client | | 563 +| | 564 FC client | | 565 +------------ | | 566 | |. PT21 + | | 567 +-+ `-. `-+.._ | | 568 . | +---+ | _:-----. OTU4,coherent | | 569 +-+ | |.+-' | `-. `-+.._+ HD-FEC | | 570 | |.-' . . +---+ | _:----------------| | 571 ' +-+ | |.+-' | | 572 OTN client | |.-' +------------+ 573 ETH ' PT21 574 + 576 Figure 9: Multistage multiplexing at different levels 578 A single IACD sub-TLV is associated that describes each 1:1 relation 579 between the ISCD sub-TLV associated to each interface and the LSC 580 switch. 582 In case, the PTx tree structure and associated un/used capacity 583 varies over time the MAX LSP Bandwidth value(s) is/are to be tuned 584 accordingly. Advertising the PTx tree structure (which actually 585 instantiates each 1:1 relation) requires structuring the "Adjustment 586 Capability-specific information" of the corresponding IACD sub-TLV. 588 6. Requirements 590 In order to deal with all the scenarios depiscted in the previous 591 sections, protocol extensions need to take into account the following 592 set of requirements. 594 1. It must be possible to identify from which branch of X to 595 which branch of Y the mapping is performed. Due to a restricted 596 connectivity to a given switching layer, not all the indicated 597 branches are really available. An example of such limitations can 598 be seen in figure Figure 6, where for example the SDH client can 599 be mapped only on itnerface Y5 of the muxponder board or the 600 10GbEth on interface Y6. In figure Figure 4 it is also possible 601 to see that the OTN has a hierarchy with 3 branches (i.e. 602 ODU1->ODU2->ODU3, ODU2->ODU3 and ODU1->ODU3) and an SDH signal can 603 be mapped only over the ODU2->ODU3 branch while an Ethernet one 604 can be mapped only on the ODU1->ODU3). So it is not eough to say 605 that SDH can be mapped over ODU or Eth over ODU as further info is 606 needed. Moreover it is also not enough to say that Eth is mapped 607 over ODU1 because in the same example 2 different branches have 608 the ODU1 as the top most layer (i.e. ODU1->ODU2->ODU3 and 609 ODU1->ODU3) and not both of them can support Eth mapping. 611 2. Adaptation information from X to Y to be used both in case of 612 Y being switched and X mapped over it or in case of both X and Y 613 being switched. Please note that more than one type of adaptation 614 might be availble. 616 3. Amount of available bandwidth in the mapping between X and Y 617 (as per actual IACD definition) 619 4. It must be possible to advertise intra-switching capability 620 associated to internal links. A typical case is a hierarchy 621 gained through the cascade of multiple cards (e.g. trasnponders, 622 muxponders) and the link from one board to the other one has a 623 given bandwidth. 625 5. It must be possible to advertise inter-switching capability 626 associated to internal links. A typical case is a M:N client- 627 layer hierarchy gained through the cascade of multiple cards (e.g. 628 SDH client to a muxponder card) and the link from one board to the 629 other one has a given bandwidth. 631 7. Evaluation 633 [RFC6001] defined the Interface Adjustment Capability Descriptor 634 (IACD) for the advertisement of internal adjustment capability of 635 hybrid nodes [RFC5212]. 637 A common adjustment pool is a pool of reservable and sharable 638 resources that are i) allocated on demand/dynamically and ii) either 639 assigned to a single SC (single adjustment pool model) or multiple SC 640 (multiple adjustment pool model) or possibly their combination. 642 In the former case (single pool model), the "lower SC" value of the 643 IACD sub-TLV (associated to the adjustment pool) is set to the SC 644 value of ISCD sub-TLV of the interface that interfaces with the 645 adjustment pool. The "upper" SC value of the IACD (associated to the 646 adjustment pool) determines the SC capability of the resource pool 647 itself. In this case the (upper) encoding is set to 0xFF. In other 648 terms, the capacity of the adjustment pool is not directly accessible 649 - over the wire - by other nodes belonging to the same TE domain 650 (assuming homogeneous LSP encoding type along the LSP path). This 651 model (see Example 1) is typically used when the node matrix 652 switching capability is not terminating/initiating any LSP (the node 653 only exposes the capability associated to its I/O) but nodes part of 654 the same TE domain can still take into account the adjustment 655 capacity usage on that node. 657 In the latter case (multiple pool model), the "lower SC" value of the 658 IACD sub-TLV (associated to the adjustment pool) is set to the SC 659 value of ISCD sub-TLV of the interface(s) that interfaces with the 660 adjustment pool. The "upper" SC value of the IACD sub-TLV 661 (associated to the adjustment pool) determines the SC capability of 662 the adjustment pool itself. However, the (upper) SC value of the 663 IACD sub-TLV shall correspond to at least one of the SC values 664 associated to one of the ISCD sub-TLVs, i.e., the adjustment pool SC 665 value shall be covered by at least one of the SC values associated to 666 the ISCD sub-TLVs. In other terms, the capacity of the adjustment 667 pool is directly accessible compared to the single pool model. This 668 model (see Example 2) is typically used when nodes expose their full 669 (multi-level) grooming and initiation/ termination capacity. 671 Example of single pool model: in the IACD sub-TLV the "upper" SC type 672 = TDM/HO-SDH, and the "lower" SC type being respectively "L2SC" and 673 "OTH/TDM". In this example, the capacity associated to the IACD 674 represents the "interconnection capacity" between the interface X 675 (L2SC or OTH) to Y = (HO-SDH/TDM). The encoding type associated to 676 the upper SC is set to 0xFF. 678 ^ ^ ^ 679 | | | 680 +-------------------------------------+ 681 | Network | | ... | | 682 | element | | | | 683 | +---------+ | 684 | +------| L2SC |<----+ | 685 | | | | | | 686 | | +---------+ | | 687 | | | | 688 | | +---------+ | | 689 | +----->| HO-SDH |-----+ | 690 | +------| |<----+ | 691 | | +---------+ | | 692 | | | | 693 | | +---------+ | | 694 | +----->| |-----+ | 695 | _ | | _ | 696 | / | | | | \ | 697 Fiber 1 | / |-----| OTH |-----| \ | Fiber 1 698 -----|---| |-----| |-----| |---|---- 699 ... | | |-----| |-----| |...| 700 -----|---| |-----| |-----| |---|---- 701 Fiber N | \ |-----| |-----| / | Fiber N 702 | \_| +---------+ |_/ | 703 +-------------------------------------+ 705 Figure 10: Example of single pool model 707 The advertisement for the node interfaces will be: 709 + L2SC interfaces 711 - ISCD sub_TLV 1 for L2SC interface 713 - IACD sub_TLV 1 for L2SC to HO-SDH (1) in figure above 715 + OTH inferfaces 717 - ISCD sub_TLV 1 for OTH interface 719 - IACD sub_TLV 1 for OTH to HO-SDH (2) in figure above 721 Example of multiple pool model: In this case we will show two 722 examples, the first of which does not foresee any interconnection 723 between the L2SC and the HO-SDH matrices, while the second one does. 725 In the former case there is at least one ISCD sub-TLV of SC = X 726 corresponding to the lower SC value (HO-SDH/TDM) of the IACD sub-TLV 727 associated to the first adjustment pool (HO-SDH/TDM), and one ISCD 728 sub-TLV of type SC = Y corresponding to the lower SC value (L2SC) of 729 the IACD sub-TLV associated to the second adjustment pool Y (L2SC). 730 In this example, the capacity associated to the IACD represents the 731 "interconnection capacity" between the pool of SC = X (HO-SDH/TDM) to 732 Y (L2SC). Each TE Link 1...N is able to get access to this 733 adjustment capacity. 735 +------------------------------------------------+ 736 | Network | 737 | element | 738 | +---------+ | 739 | +---------| L2SC |<---------+ | 740 | | **| |** | | 741 | | * +---------+ * | | 742 | | * * | | 743 | | * +---------+ * | | 744 | | **| |** | | 745 | | +-------| HO-SDH |<-------+ | | 746 | | | | | | | | 747 | | | +---------+ | | | 748 | | | | | | 749 | | | +---------+ | | | 750 | | | | | | | | 751 | _ | | | | | | _ | 752 | / |<- | | | | +| \ | 753 Fiber 1 | / |<--+ | OTH | +--| \ | Fiber 1 754 -----|--| |-----------| |-----------| |---|---- 755 ... | | |-----------| |-----------| |...| 756 -----|--| |-----------| |-----------| |---|---- 757 Fiber N | \ |-----------| |-----------| / | Fiber N 758 | \_| +---------+ |_/ | 759 +------------------------------------------------+ 761 Figure 11: Example of multiple pool model - No interconnection 762 between OTH and HO-SDH 764 In this case the advertisement, which is the same for each of the N 765 TE Link is: 767 - ISCD sub_TLV for LSC 769 - ISCD sub_TLV for HO-SDH 770 - ISCD sub_TLV for OTH 772 - IACD sub_TLV for LSC to HO-SDH (starred link) 774 On the other side, if we consider the same scenario including the 775 inteconnection between the OTH and HO-SDH matrices, as shown in 776 figure below, the advertisement changes as follows. 778 +------------------------------------------------+ 779 | Network | 780 | element | 781 | +---------+ | 782 | +---------| L2SC |<---------+ | 783 | | **| |** | | 784 | | * +---------+ * | | 785 | | * * | | 786 | | * +---------+ * | | 787 | | **| |** | | 788 | | +-------| HO-SDH |<-------+ | | 789 | | | ..| |.. | | | 790 | | | : +---------+ . | | | 791 | | | : : | | | 792 | | | : +---------+ : | | | 793 | | | : | | : | | | 794 | _ | | :.| |.: | | _ | 795 | / |<- | | | | +| \ | 796 Fiber 1 | / |<--+ | OTH | +--| \ | Fiber 1 797 -----|--| |-----------| |-----------| |---|---- 798 ... | | |-----------| |-----------| |...| 799 -----|--| |-----------| |-----------| |---|---- 800 Fiber N | \ |-----------| |-----------| / | Fiber N 801 | \_| +---------+ |_/ | 802 +------------------------------------------------+ 804 Figure 12: Example of multiple pool model - With interconnection 805 between OTH and HO-SDH 807 This time the advertisement is modified as follows: 809 - ISCD sub_TLV 1 for LSC 811 - ISCD sub_TLV 2 for HO-SDH 813 - ISCD sub_TLV 3 for OTH 814 - IACD sub_TLV 1 for LSC to HO-SDH (starred link) 816 - IACD sub_TLV 2 for HO-SDH to OTH (dotted link) 818 The IACD is the only object defined in routing for the management of 819 hybrid nodes. It provides the information for the forwarding/ 820 switching capability and is used in addition to the ISCD. 822 0 1 2 3 823 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Lower SC | Lower Encoding| Upper SC | Upper Encoding| 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Max LSP Bandwidth at priority 0 | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Max LSP Bandwidth at priority 1 | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Max LSP Bandwidth at priority 2 | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Max LSP Bandwidth at priority 3 | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Max LSP Bandwidth at priority 4 | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Max LSP Bandwidth at priority 5 | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Max LSP Bandwidth at priority 6 | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Max LSP Bandwidth at priority 7 | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Adjustment Capability-specific information | 844 | (variable) | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 Figure 13: IACD format 849 8. Missing information 851 The pieces of information needed for addressing the requirements 852 listed in Section 6 are: 854 - Mapping information from a client to a server layer. E.g. an 855 ethernet client could be mapped over and OTN hierarchy using a 856 GFP-F or GFP-T adaptation. 858 - Connectivity constraints: need to describe optical transponder 859 muxing scheme with positioning and restricted connectivity in 860 order to provide end to end connectivity. In the example shown in 861 picture Figure 4, the capability of muxing an SDH hierarchy is 862 shown, but the SDH cannot be injected in any branch of the OTN 863 hierarchy. There is the need to specify that the SDH hierarchy 864 can be only muxed into the ODU->ODU3 branch of the OTN hierarchy 865 and not in all of them. 867 - Multistage interswitching capability: The IACD already allows 868 advertising the multiplexing of single and multi-stage muxing 869 scenarios like the one in the reference muxing tree, where an SDH 870 hierarchy is muxed over an OTN hierarchy, which is againg muxed 871 over an OCh (two levels of muxing). 873 9. IANA Considerations 875 TBD 877 10. Contributors 879 TBD 881 11. Acknowledgements 883 TBD 885 12. References 887 12.1. Normative References 889 [OSPF-OTN] 890 D.Ceccarelli, D.Caviglia, F.Zhang, D.Li, S.Belotti, 891 P.Grandi, R.Rao, K.Pithewan, J.Drake, "Traffic Engineering 892 Extensions to OSPF for Generalized MPLS (GMPLS) Control of 893 Evolving G.709 OTN Networks, work in progress 894 draft-ietf-ccamp-gmpls-ospf-g709v3-03", August 2012. 896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 897 Requirement Levels", BCP 14, RFC 2119, March 1997. 899 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 900 Support of Generalized Multi-Protocol Label Switching 901 (GMPLS)", RFC 4202, October 2005. 903 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 904 of Generalized Multi-Protocol Label Switching (GMPLS)", 905 RFC 4203, October 2005. 907 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 908 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 909 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 910 July 2008. 912 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 913 D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol 914 Extensions for Multi-Layer and Multi-Region Networks (MLN/ 915 MRN)", RFC 6001, October 2010. 917 12.2. Informative References 919 [G.709] ITU-T, "Interface for the Optical Transport Network 920 (OTN)", G.709 Recommendation (and Amendment 1), 921 February 2001. 923 [G.709-v3] 924 ITU-T, "Draft revised G.709, version 3", consented 925 by ITU-T on Oct 2009. 927 Authors' Addresses 929 Daniele Ceccarelli (editor) 930 Ericsson 931 Via Melen 77 932 Genova - Sestri Ponente 933 Italy 935 Email: daniele.ceccarelli@ericsson.com 937 Francesco Fondelli 938 Ericsson 939 Via Moruzzi 1 940 Pisa 941 Italy 943 Email: francesco.fondelli@ericsson.com 944 Sergio Belotti 945 Alcatel-Lucent 946 Via Trento, 30 947 Vimercate 948 Italy 950 Email: sergio.belotti@alcatel-lucent.com 952 Dimitri Papadimitriou (editor) 953 Alcatel-Lucent 954 Copernicuslaan 50 955 Antwerpen B-2018 956 Belgium 958 Email: dimitri.papadimitriou@alcatel-lucent.be