idnits 2.17.1 draft-fuxh-ccamp-multi-stage-multiplex-config-fwk-01.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 : ---------------------------------------------------------------------------- ** There are 40 instances of too long lines in the document, the longest one being 14 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 (July 12, 2010) is 5031 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Max' is mentioned on line 530, but not defined == Missing Reference: 'Available' is mentioned on line 530, but not defined == Missing Reference: 'Allocated' is mentioned on line 530, but not defined == Missing Reference: 'MHF' is mentioned on line 523, but not defined == Missing Reference: 'MSMH' is mentioned on line 523, but not defined == Missing Reference: 'RFC3473' is mentioned on line 674, but not defined == Missing Reference: 'RFC4205' is mentioned on line 674, but not defined ** Obsolete undefined reference: RFC 4205 (Obsoleted by RFC 5307) == Missing Reference: 'RFC4204' is mentioned on line 675, but not defined == Missing Reference: 'RFC5440' is mentioned on line 675, but not defined == Missing Reference: 'GMPLS-SEC' is mentioned on line 675, but not defined == Unused Reference: 'RFC5212' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-gmpls-g709-framework' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-gmpls-mln-extensions' is defined on line 718, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5339 ** Downref: Normative reference to an Informational RFC: RFC 5212 == Outdated reference: A later version (-15) exists of draft-ietf-ccamp-gmpls-g709-framework-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-gmpls-g709-framework (ref. 'I-D.ietf-ccamp-gmpls-g709-framework') Summary: 5 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Fu 3 Internet-Draft M. Betts 4 Intended status: Standards Track ZTE Corporation 5 Expires: January 13, 2011 R. Jing 6 X. Huo 7 China Telecom 8 Y. Xu 9 CATR 10 July 12, 2010 12 Framework for Multi Stages Multiplexing Configuration in G.709 Optical 13 Transport Network 14 draft-fuxh-ccamp-multi-stage-multiplex-config-fwk-01 16 Abstract 18 Interworking between regions with 1.25G TS and 2.5G TS has been 19 considered in G.709. Multi stages multiplexing would be desirable to 20 facilitate the introduction of new ODU0 and ODUflex signals to an 21 existing network without having to upgrade every node in the network. 22 So ODU0/ODUflex can be mapped into ODU1/ODU2/ODU3 and transit across 23 the 2.5G TS region. Multi stages multiplexing are also used to 24 support the multi-domain OTN applications based on carrier-Carrier, 25 regional-national core interconnection or network tunnels design. 26 This document describes the framework for multi stages multiplexing 27 configuration in G.709 Optical Transport Network. 29 Conventions Used In This Document 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 13, 2011. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Multi Stages Multiplexing vs Single Stage Multiplexing . . . . 4 70 2.1. Bandwidth Fragmentation . . . . . . . . . . . . . . . . . 4 71 2.2. Integrated Line Card vs Cascade Line/Equipment . . . . . . 5 72 3. GMPLS and PCE Extension to Support Multi Stages 73 Multiplexing Configuration . . . . . . . . . . . . . . . . . . 6 74 3.1. Routing Extension to Support Multi Stages Multiplexing 75 Configuration . . . . . . . . . . . . . . . . . . . . . . 6 76 3.1.1. Multi Stages Multiplexing Capability . . . . . . . . . 7 77 3.1.2. Selection of Multi Stages Multiplexing Hierarchies . . 14 78 3.2. Signaling Extension to Support Multi Stages 79 Multiplexing Configuration . . . . . . . . . . . . . . . . 15 80 3.3. PCE Extension to Support Multi Stages Multiplexing 81 Configuration . . . . . . . . . . . . . . . . . . . . . . 15 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 6.1. Normative References . . . . . . . . . . . . . . . . . . . 16 86 6.2. Informative References . . . . . . . . . . . . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 89 1. Introduction 91 Multi stages multiplexing configuration requirement is defined in 92 [draft-fuxh-ccamp-multi-stage-multiplex-config-req-01] document. It 93 describes two typical use case of multi stages multiplexing 94 configuration. 96 The introduction of ODU0 and ODUflex to the OTN hierarchy creates the 97 requirement where multi stages of multiplexing would be desirable to 98 facilitate the introduction of these new ODU0 and ODUflex signals to 99 an existing 2.5G TS network without having to upgrade every node in 100 the network. 102 A second potential application for multi stages outside of an upgrade 103 scenario would be the carrier-carrier, regional-national core 104 interconnection cases or network design based on tunnels. Multi 105 stages multiplexing are used to support the multi-domain OTN 106 applications based on the tunnel design. If there are a large number 107 of circuits that share the same endpoints (or even part of an overall 108 path), it may be convenient from a management perspective to first 109 multiplex those ODU0, ODU1 and ODUflex into ODU2 or ODU3 to minimize 110 the number of connections that need to be made in intermediate nodes. 111 The ODU2/ODU3 effectively creates a tunnel through the ODU4 network 112 that the ODU0, ODU1 and ODUflex can use. 114 This document describes the framework for multi stages multiplex 115 configuration in G.709 Optical Transport Network. 117 2. Multi Stages Multiplexing vs Single Stage Multiplexing 119 2.1. Bandwidth Fragmentation 121 Single-stage ODU multiplexing can provide non-fragmented bandwidth, 122 maximizing the support of higher bit rate LO ODU signals. While two- 123 stage ODU multiplexing may introduce fragmented bandwidth into 124 smaller bandwidth subsets. Suppose 8 ODU0 service needs to be 125 created over ODU2 link by using ODU0-ODU1-ODU2 multiplexing. 127 o 1st ODU1 for 1st and 2nd ODU0 service. 129 o 2nd ODU1 for 3rd and 4th ODU0 service. 131 o 3th ODU1 for 5th and 6th ODU0 service. 133 o 4th ODU1 for 7th and 8th ODU0 service. 135 After 1st and 3rd ODU0 service is deleted and one new ODU1 service 136 needs to be created, there is no any avaible TS for the ODU1 service 137 creation. There will be some fragmented bandwidth within one ODU2 138 link. If ODU0-ODU2 multiplexing is used and TSs have not to be 139 sequential for ODU1 service in order to prevent further bandwidth 140 fragmentation, the fragmentation can be avoided. 142 GMPLS could defragment such fragmented ODU link by using make-before- 143 break method, for example by moving ODU0 connections from one (half 144 empty) ODU1 trail to another (half empty) ODU1 trail. An operator 145 may have a policy that allows GMPLS to perform such defragmentation. 146 How to deal with defragementation is out scope of this document. But 147 the bandwidth fragment should not be an obstacle for the multi stages 148 multiplexing application. 150 2.2. Integrated Line Card vs Cascade Line/Equipment 152 Figure 1 shows two models of multi stages multiplexing. But it 153 doesn't going to restrict the implementation of equipment. In the 154 cascade equipment or line card model, it require the operator to 155 backhaul service to other seperate equipments or line cards which can 156 support the re-multiplexing in order to follow the single stage 157 multiplexing. So it will introduces unnecessary network complexity, 158 power and cost. 160 2/2 2/3 161 ------ 162 | | 163 |----| |----| 164 2/0 0/2 | |______| | 3/2 2/3 165 ------ | | ------ 166 | | | | | | 167 ----| |--- ---| |---- 168 |______| |______| 170 1.25G TS 2.5G TS 171 Cascade Equipment 173 2/0 0/2 2/3 3/2 2/3 174 ______________ __________ 175 | _ _ _ | | _ _ | 176 || | | | | || || | | || 177 ____|| | \/ | |_| ||____|| | \/ | ||____ 178 || | /\ | | | || || | /\ | || 179 ||_| |_| |_|| ||_| |_|| 180 |______________| |__________| 182 1.25G TS 2.5G TS 183 Cascade Card 185 Figure 1 187 Figure 2 shows a different model of multi stages multiplexing. In 188 the integrated line card, it needs the multi stages multiplexing 189 within one single line card. One integrated equipment and line card 190 may be choosen to save on OPEX and CAPEX. 192 2/0 0/2/3 3/2 2/3 193 ___________ __________ 194 | _ _ | | _ _ | 195 || | | | | || | | || 196 ____|| | \/ | | |____|| | \/ | ||____ 197 || | /\ | | | || | /\ | || 198 ||_| |_| | ||_| |_|| 199 |___________| |__________| 201 1.25G TS 2.5G TS 202 Integrated Card 204 Figure 2 206 3. GMPLS and PCE Extension to Support Multi Stages Multiplexing 207 Configuration 209 From the perspective of Control Plane, path computation entity must 210 get multi stages multiplexing capability of each node to support 211 multi stages multiplexing for path computation. Path computation 212 entity can use the IGP protocol or configurations from Management 213 Plane to get this information. Path computation entity must select a 214 proper kind of multi stages multiplexing of nodes which may support 215 different multi stages multiplexing hierarchies along a specific end- 216 to-end connection. Signaling message must carry the multi stages 217 multiplexing hierarchy that has been determined by path computation 218 entity. Multi stages multiplexing for a specific service must be 219 configured after node receives the signaling of service creation. 221 The purpose of this section is to provide a framework for extensions 222 of the current GMPLS and PCE protocols for multi stages multiplexing 223 configuration in OTN network. 225 3.1. Routing Extension to Support Multi Stages Multiplexing 226 Configuration 228 Path computation entity needs to get the multi stages multiplexing 229 capability information of nodes which are designed to support multi 230 stages multiplexing. Multi stages multiplexing capability 231 information must be advertised into topology by the IGP protocol. 232 LSAs which are advertised must carry multi stages multiplexing 233 capability information. Multi stages multiplexing capability can be 234 configured into nodes by Management Plane (e.g., Network Planning 235 Tool) or discovered within nodes based on the switching and 236 adaptation capability of switching fabrics and cards. 238 3.1.1. Multi Stages Multiplexing Capability 240 The content of this section describes the information needed for path 241 computation. In terms of Figure 3, there is a network element 242 between the 1.25G TS and 2.5G TS network. In order to facilitate the 243 introduction of new ODU0 and ODUflex signals from 1.25G TS network 244 (i.e., 10G network), ODU0/ODUflex can be mapped into ODU1/ODU2 first 245 and transit across the 2.5G TS network (i.e., 40G network). 247 This document does not imply restrictions to the equipment 248 implementation. It just gives an info model of how the multi stage 249 multiplexing capability could be represented. Modeling of routing 250 information must be independent of equipment design. 252 G1 of Figure 3 supports the following single stage and multi stages 253 multiplexing capability when signal is mapped into ODU3. 255 o ODU1-ODU3 257 o ODU2-ODU3 259 o ODU0-ODU1-ODU3 261 o ODU0-ODU2-ODU3 263 o ODU1-ODU2-ODU3 265 o ODUflex-ODU2-ODU3 267 G1 of Figure 3 supports the following single stage multiplexing 268 capability when signal is mapped into ODU2. 270 o ODU0-ODU2 272 o ODUflex-ODU2 274 o ODU1-ODU2 276 NE G1 of Figure 3 can also add or drop the STM-16 (ODU1) and 10GigE 277 (ODU2). 279 Network Element G1 280 _____________________________________________________________ 281 | ______________ ______________________________ | 282 | | ___ | ___ | ___ | | 283 | | | | | | | | | | | | 284 | | | | --- | | | | -------- #2 | | | | 285 | | | | | O | | | | | | O |-------------| | | | 286 | | | |--| D |-|--| |--|-| D | | | | | 287 | | | | | U | | | | | | U | #3 --- | | | | 288 | | | | | 1 | | | | | | 1 |----| | | | | | 289 | | | | --- | | | | -------- | | | | | | 290 | | | | | | | | | | | | | | | 291 | | | | | | | | |#4 | | | | | | 292 | | | | --- | | | | --- | | | | | | | 293 OTU2 Port1 | | | O | | O | | | D | | | O |-- | O | #1 | O | | | OTU3 Port2 294 1.25G TS----|--|-| D |--| D |-|--| X |--|-| D |---------| D |----| D |-|--|----2.5G TS 295 Network | | | U | | U | | | C | | | U | #5 | U | | U | | | Network 296 | | | 2 | | 0 | | | | | | 0 | | 2 | | 3 | | | 297 | | | | --- | | | | --- | | | | | | 298 | | | | | | | | | | | | | | 299 | | | | --- | | | | --- | | | | | | 300 | | | | | f | | | | | | f | | | | | | | 301 | | | | | l | | | | | | l | | | | | | | 302 | | | |--| e |-|--| |--|-| e |---------| | | | | | 303 | | | | | x | | | | | | x | #6 | | | | | | 304 | | | | --- | | | | --- | | | | | | 305 | | | |--------|--| |--|---------------| | | | | | 306 | | |___| | |___| | |___| |___| | | 307 | |______________| | | |______________________________| | 308 | ___| |___ | 309 | | | | 310 | --- --- | 311 | | O | | O | | 312 | | D | | D | | 313 | | U | | U | | 314 | | 1 | | 2 | | 315 | --- --- | 316 |_________________|_________|_________________________________| 317 | | 318 | | 319 Add/Drop Add/Drop 320 (STM-16) (10GigE) 322 Figure 3 324 There should be some ISCDs [RFC4202][RFC4203] or IACDs 325 [RFC5339][draft-ietf-ccamp-gmpls-mln-extensions-12] to describe the 326 switching/adaptation capability of OTU2 and OTU3 TE Link. OTU2 TE 327 Link can directly support ODU0, ODU1, ODUflex and ODU2 switching 328 capability. OTU3 TE Link can directly support ODU1, ODU2 and ODU3 329 switching capability. OTU3 TE Link can support ODU0, ODU1 and 330 ODUflex by multi stages multiplexing hierarchies. In order for path 331 computation, following information needs to be advertised into 332 topology. 334 o ODUk Type (e.g., OTU3 and OTU2 of Figure 3). 336 o Tribute Slot Type: 1.25G TS or 2.5G TS. 338 o Supported ODUi: Max/Available/Allocated (k > i). 340 * Max: maximum numbers of ODUi which can be supported directly by 341 the ODUk link. 343 * Available: available numbers of ODUi which can be supported 344 directly by ODUk link. 346 * Allocated: the numbers of ODUi which has been allocated. This 347 information isn't necessary to be advertised. It may be 348 maintained in the control plane instance. 350 o Supported ODUflex: max/available/allocated. 352 * Max TSs: The maximum tribute slots that could be supported 353 directly for ODUflex by the ODUk (k=2, 3, 4). 355 * Available TSs: maximum numbers of tribute slots that are not 356 assigned for ODUflex. 358 * Allocated TSs: tribute slots that have been allocated for 359 ODUflex. This information isn't necessary to be advertised. 360 It may be maintained in the control plane instance. 362 We can only use ISCDs to represent single stage and multi stages 363 multiplexing capability. But other further information is necessary. 365 o Multiplexing Hierarchy Flag (MHF): single stage multiplexing or 366 multi stages multiplexing. When it is set to 0, ODUi (i < k) is 367 mapped into ODUk by single stage multiplexing. When it is set to 368 1, ODUi (i < k) is mapped into ODUk by multi stages multiplexing. 370 o Multi Stages Multiplexing Hierarchy (MSMH). 372 We would have the following TE link advertisements: 374 OTU2 TE Link (Port1): 375 - ISCD 1 sub-TLV: ODUk Type = 10G (ODU2), 376 Tribute Slot Type = 1.25G TS, 377 [Max] [Available] [Allocated] [MHF] [MSMH] 378 ODU0 8 8 0 0 / 379 ODU1 4 4 0 0 / 380 ODU2 1 1 0 0 / 381 ODUflex 8 8 0 0 / 383 OTU3 TE Link (Port2): 385 - ISCD 2 sub-TLV: ODUk Type = 40G (ODU3), 386 Tribute Slot Type = 2.5G TS, 387 [Max] [Available] [Allocated] [MHF] [MSMH] 388 ODU3 1 1 0 0 / 389 #1 ODU2 4 4 0 0 / 390 #2 ODU1 16 16 0 0 / 392 - ISCD 3 sub-TLV: ODUk Type = 40G (ODU3), 393 Tribute Slot Type = No Meaning, 394 [Max] [Available] [Allocated] [MHF] [MSMH] 395 #4 ODU0 32 32 0 1 ODU0-ODU1-ODU3 397 - ISCD 4 sub-TLV: ODUk Type = 40G (ODU3), 398 Tribute Slot Type = No Meaning, 399 [Max] [Available] [Allocated] [MHF] [MSMH] 400 #3 ODU1 16 16 0 1 ODU1-ODU2-ODU3 401 #5 ODU0 32 32 0 1 ODU0-ODU2-ODU3 402 #6 ODUflex 32 32 0 1 ODUflex-ODU2-ODU3 404 If there are three 10GigE (ODU2) services and one STM-16 service 405 which are added into NE G1 of Figure 3 accross the OTU3 link, 406 following ISCDs has to be changed. There is no any adaptation 407 capability between ODUflex, ODU0, ODU1 and ODU2. So ODUflex, ODU0 408 and ODU1 can not be mapped in ODU2 in ODU3 when they are going to 409 across the 2.5G TS network. There is no any changing for the 410 adaptation capability of ODU0 being mapped in ODU1 in ODU3. 412 OTU3 TE Link (Port2): 414 - ISCD 2 sub-TLV: ODUk Type = 40G (ODU3), 415 Tribute Slot Type = 2.5G TS, 416 [Max] [Available] [Allocated] [MHF] [MSMH] 417 ODU3 1 0 0 0 / 418 #1 ODU2 4 0 3 0 / 419 #2 ODU1 16 3 1 0 / 421 - ISCD 3 sub-TLV: ODUk Type = 40G (ODU3), 422 Tribute Slot Type = No Meaning, 423 [Max] [Available] [Allocated] [MHF] [MSMH] 424 #4 ODU0 32 6 0 1 ODU0-ODU1-ODU3 426 - ISCD 4 sub-TLV: ODUk Type = 40G (ODU3), 427 Tribute Slot Type = No Meaning TS, 428 [Max] [Available] [Allocated] [MHF] [MSMH] 429 #3 ODU1 16 0 0 1 ODU1-ODU2-ODU3 430 #5 ODU0 32 0 0 1 ODU0-ODU2-ODU3 431 #6 ODUflex 32 0 0 1 ODUflex-ODU2-ODU3 433 We could also combine ISCDs and IACDs to represent single stage and 434 multi stages multiplexing capability of OTU3 Port2. We would have 435 another TE link advertisements for single stage multiplexing. Only 436 ODUi which could be supported directly by ODUk TE Link is representd 437 in ISCD. 439 OTU3 TE Link (Port2): 440 - ISCD 1 sub-TLV: ODUk Type = 40G (ODU3), 441 Tribute Slot Type = 2.5G TS, 442 [Max] [Available] [Allocated] [MHF] [MSMH] 443 ODU1 16 16 0 0 / 444 ODU2 4 4 0 0 / 445 ODU3 1 1 0 0 / 447 In order to make path computation entity be aware of the multi stages 448 multiplexing capability information, following information needs to 449 be advertised into topology. 451 o Supported ODUj: max/available/allocated (k > i > j) 453 * Max: maximum numbers of ODUj which can be directly adapted into 454 ODUi. 456 * Available: available numvers of ODUj which can be directly 457 adapted into ODUi. 459 * Allocated: the numbers of ODUj which has been allocated for the 460 adaptation. This information doesn!_t need to be advertised. 461 It should be stored in the control plane instance. 463 o Supported ODUflex: max/available/allocated. 465 * Max TSs: The maximum tribute slots that could be mapped into 466 ODUi (i=2, 3, 4). 468 * Available TSs: maximum numbers of tribute slots that are not 469 assigned for ODUflex. 471 * Allocated TSs: tribute slots that have been allocated for 472 ODUflex. This information isn't necessary to be advertised. 473 It may be maintained in the control plane instance. 475 We would have the following TE link advertisements for the adaptation 476 capability between different ODUk containers: 478 OTU3 TE Link (Port2): 480 Supported ODU0 which is adapted into ODU1: 481 - IACD 1 sub-TLV: Type of ODUi: ODU1 482 [Max] [Available] [Allocated] 483 #4 ODU0 2 2 0 485 Supported ODU1 which is adapted into ODU2: 486 - IACD 2 sub-TLV: Type of ODUi: ODU2 487 [Max] [Available] [Allocated] 488 #3 ODU1 4 4 0 490 Supported ODU0 which is adapted into ODU2: 491 - IACD 3 sub-TLV: Type of ODUi: ODU2 492 [Max] [Available] [Allocated] 493 #5 ODU0 8 8 0 495 Supported ODUflex which is adapted into ODU2: 496 - IACD 4 sub-TLV: Type of ODUi: ODU2 497 #6 [Max] [Available] [Allocated] 498 ODUflex 8 8 0 500 In order to reduce the information which has to be advetised into 501 toplogy. IACD2, IACD3 and IACD4 could be combined into one IACD 502 (e.g., IACD5), as ODUflex, ODU0 and ODU1 are all adapted into the 503 same ODU2 container. 505 Supported ODUj (j=0, 1, flex) which is adapted into ODU2: 506 - IACD 5 sub-TLV: Type of ODUi: ODU2 507 [Max] [Available] [Allocated] 508 #3 ODU1 4 4 0 509 #5 ODU0 8 8 0 510 #6 ODUflex 8 8 0 512 If there are three 10GigE services and one STM-16 service which are 513 added into NE G1 of Figure 3 accross the OTU3 link, following IACD 514 and IACD has to be changed. There is no any adaptation capability 515 between ODUflex, ODU0, ODU1 and ODU2. So ODUflex and ODU0 can not be 516 mapped in ODU2 in ODU3 when they are going to across the 2.5G TS 517 network. There is no any changing for ISCD4 (i.e., adaptation 518 capability of ODU0 being mapped in ODU1 in ODU3). 520 OTU3 TE Link (Port2): 521 - ISCD 1 sub-TLV: ODUk Type = 40G (ODU3), 522 Tribute Slot Type = 2.5G TS, 523 [Max] [Available] [Allocated] [MHF] [MSMH] 524 ODU1 16 3 1 0 / 525 ODU2 4 0 3 0 / 526 ODU3 1 0 0 0 / 528 Supported ODUj (j=0, 1, flex) which is adapted into ODU2: 529 - IACD 5 sub-TLV: Type of ODUi: ODU2 530 [Max] [Available] [Allocated] 531 #3 ODU1 4 0 0 532 #5 ODU0 8 0 0 533 #6 ODUflex 8 0 0 535 The following multiplexing hierarchies matrix could be inferred by 536 path computation entity in terms of ISCD1, ISCD2, IACD1, IACD2, IACD3 537 and IACD4. So path computation entity will infer that ODU0-ODU1- 538 ODU2-ODU3 multi stages multplexing could be supported by the network 539 element. But the fact is that ODU0-ODU1-ODU2-ODU3 three stage 540 multiplexing hierarchy couldn't be supported within the NE G1 of 541 Figure 3. The constraint of prohibiting ODU0 in ODU1 in ODU2 must be 542 expressed in topology view and considered by path computation entity. 543 The allowable multi stages multiplexing hierarchies should be also 544 known by path computation entity. 546 ODU1 ODU2 ODU3 547 ODU0 * * 548 ODU1 * * 549 ODU2 * 550 ODUflex * 552 3.1.2. Selection of Multi Stages Multiplexing Hierarchies 554 The multi stages multiplexing capability information should be 555 discovered/enabled by the OSS and as described in the previous point 556 distributed via routing. Path computation entity can get multi 557 stages multiplexing capability of each nodes for path computation. 558 It must select some proper kinds of multi stages multiplexing 559 hierarchies for different nodes along a specific end-to-end 560 connection. For example, there are two multi stages multiplexing 561 hierarchies for ODU0 being mapped into ODU3 in NE G1 of Figure 3 562 (i.e., ODU0-ODU1-ODU3 and ODU0-ODU2-ODU3). So it has to determine 563 which kind of multi stages multiplexing hierarchies should be used 564 for the ODU0 service and the type of tunnel (FA-LSP). In Figure 4, 565 if path computation entity select the ODU0-ODU2-ODU3 multi stages 566 multiplexing hierarch in Node B and C for one end-to-end ODU0 service 567 from A to Z, there has to be an ODU2 tunnel between B and C. The 568 selection of multi stages multiplexing hierarchies is based on the 569 operator policy and the equipment capability. How to select the 570 multiplexing hierarchies is the internal behavior of path computation 571 entity. 573 ODU1-ODU3 574 ODU2-ODU3 575 ODU0-ODU2 ODU0-ODU1-ODU3 576 ODU1-ODU2 ODU0-ODU2-ODU3 577 ODUflex-ODU2 ODUflex-ODU2-ODU3 578 ___ _|______ _|_____ ___ 579 | A | | | B | | | C | | Z | 580 | o-|-------------|-o o-|-----------------|-o o-|-----------|-o | 581 |___| OTU2 Link |_____|__| OTU3 Link |_____|_| OTU3 Link |___| 582 | | 583 ODU0-ODU1-ODU3 ODU0-ODU2 584 ODU0-ODU2-ODU3 ODU1-ODU2 585 ODUflex-ODU2-ODU3 ODUflex-ODU2 586 ODU1-ODU2-ODU3 587 ODU1-ODU3 588 ODU2-ODU3 590 Figure 4 592 The routing protocol should be extended to convey the multi stages 593 multiplexing capability information and the multi stages multiplexing 594 hierarchies which are supported or prohibited. 595 [draft-fuxh-ccamp-multi-stage-multiplex-config-ospf-01] describes 596 OSPF-TE extension for multi stages multiplexing configuration. 598 3.2. Signaling Extension to Support Multi Stages Multiplexing 599 Configuration 601 All kinds of multi stages multiplexing hierarchies which has been 602 determined for all nodes along one end-to-end connection by path 603 computation entity must be carried with signaling message. For 604 example, if path computation entity select the ODU0-ODU2-ODU3 multi 605 stages multiplexing hierarch in Node B and C of Figure 4 for one end- 606 to-end ODU0 service from A to Z, the signalling message must carry 607 this ODU0-ODU2-ODU3 multi stages multiplexing hierarchy to inform 608 Node B and C. After one node which can support the flexible multi 609 stages multiplexing hierarchies receives the signaling message who 610 carries one kind of multi stages multiplexing hierarchy for it, it 611 must config this kind of multi stages multiplexing hierarchy to its 612 data plane. It needs to extend the signaling protocol to carry this 613 informationn. [draft-fuxh-ccamp-multi-stage-multiplex-config-rsvp-01] 614 describes RSVP-TE extension for multi stages multiplexing 615 configuration. 617 The ODU2 tunnel is signalled based on [RFC4328] signalling. It can 618 be resolved by using pre-established HO ODU2 or triggered by ODU0 619 connection signalling. After the ODU2 tunnel is created, one ODU2 620 link is added into the topology for other ODUflex/ODU0/ODU1 path 621 computation. When the "last" LO ODU type service (e.g. ODU0, ODU1 622 and ODUflex) removed, the ODU2 must be torn down and removed from the 623 ODU0 /ODU1/ODUflex topology; the timing for this should be set by a 624 policy e.g. immediately, after 10 days, or... 626 3.3. PCE Extension to Support Multi Stages Multiplexing Configuration 628 Based on the [draft-fuxh-ccamp-multi-stage-multiplex-config-ospf-01], 629 path computation entity can get multi stages multiplexing capability 630 of each nodes for path computation. Path computation entity in 631 Management Plane and/or Control Plane must support the path 632 computation by using the multi stages multiplexing capability and 633 supported or prohibited multi stages multiplexing hierarchies 634 information. It must determine some proper kinds of multi stages 635 multiplexing hierarchy for different nodes along the path. 637 A request from a PCC to a PCE MUST support the inclusion of an 638 optional indication of which kinds of multi stages multiplexing 639 hierarchy can be used for sepecific node or not. So the path 640 computation entity must consider these multi stage multiplexing 641 hierarchy constraints. In the absence of such an indication, the 642 default is that there is no any multi stage multiplexing hierarchy 643 constraint for path computation. 645 PCReq has a desire to be extended to carry some kindes of multi 646 stages multiplexing hierarchy constraints of some specific nodes for 647 path computation from PCC. PCRep also has a desire to be extended to 648 carry all kindes of multi stages multiplexing hierarchy which have 649 been selected by PCE for each nodes along the path. 651 PCEReq 652 (Including or excluding list of multi stages multiplexing hierarchies) 653 ------------------------------------------------------------ 654 | | 655 |______ _\|/___ 656 | | | | 657 | PCC |--------------------------------------------------| PCE | 658 |_______| |_______| 659 /|\ | 660 |____________________________________________________________| 661 PCERep 662 (selection of multi stages multiplexing hierarchies) 664 Figure 5 666 4. Security Considerations 668 The use of control plane protocols for signaling, routing, and path 669 computation opens an OTN to security threats through attacks on those 670 protocols. The data plane technology for an OTN does not introduce 671 any specific vulnerabilities, and so the control plane may be secured 672 using the mechanisms defined for the protocols discussed. For 673 further details of the specific security measures refer to the 674 documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], 675 [RFC4204], and [RFC5440]). [GMPLS-SEC] provides an overview of 676 security vulnerabilities and protection mechanisms for the GMPLS 677 control plane. 679 5. IANA Considerations 681 TBD 683 6. References 685 6.1. Normative References 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, March 1997. 690 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 691 Switching (GMPLS) Signaling Extensions for G.709 Optical 692 Transport Networks Control", RFC 4328, January 2006. 694 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 695 Support of Generalized Multi-Protocol Label Switching 696 (GMPLS)", RFC 4202, October 2005. 698 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 699 of Generalized Multi-Protocol Label Switching (GMPLS)", 700 RFC 4203, October 2005. 702 [RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing 703 GMPLS Protocols against Multi-Layer and Multi-Region 704 Networks (MLN/MRN)", RFC 5339, September 2008. 706 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 707 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 708 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 709 July 2008. 711 [I-D.ietf-ccamp-gmpls-g709-framework] 712 Zhang, F., Li, D., Li, H., Belotti, S., Han, J., Betts, 713 M., Grandi, P., and E. Varma, "Framework for GMPLS and PCE 714 Control of G.709 Optical Transport Networks", 715 draft-ietf-ccamp-gmpls-g709-framework-00 (work in 716 progress), April 2010. 718 [I-D.ietf-ccamp-gmpls-mln-extensions] 719 Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 720 D., and J. Roux, "Generalized Multi-Protocol Label 721 Switching (GMPLS) Protocol Extensions for Multi-Layer and 722 Multi-Region Networks (MLN/MRN)", 723 draft-ietf-ccamp-gmpls-mln-extensions-12 (work in 724 progress), February 2010. 726 6.2. Informative References 728 Authors' Addresses 730 Xihua Fu 731 ZTE Corporation 733 Email: fu.xihua@zte.com.cn 734 Malcolm Betts 735 ZTE Corporation 737 Email: malcolm.betts@zte.com.cn 739 Ruiquan Jing 740 China Telecom 742 Email: jingrq@ctbri.com.cn 744 Xiaoli Huo 745 China Telecom 747 Email: huoxl@ctbri.com.cn 749 Yunbin Xu 750 CATR 752 Email: xuyunbin@mail.ritt.com.cn