idnits 2.17.1 draft-fuxh-ccamp-multi-stage-multiplex-config-req-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 12, 2010) is 5036 days in the past. Is this intentional? 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: 'RFC3473' is mentioned on line 464, but not defined == Missing Reference: 'RFC4203' is mentioned on line 464, but not defined == Missing Reference: 'RFC4205' is mentioned on line 464, but not defined ** Obsolete undefined reference: RFC 4205 (Obsoleted by RFC 5307) == Missing Reference: 'RFC4204' is mentioned on line 465, but not defined == Missing Reference: 'RFC5440' is mentioned on line 465, but not defined == Missing Reference: 'GMPLS-SEC' is mentioned on line 465, but not defined == Unused Reference: 'I-D.ietf-ccamp-gmpls-g709-framework' is defined on line 480, but no explicit reference was found in the text == 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: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). 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 H. Li 9 China Mobile 10 G. Wang 11 China Unicom 12 G. Zhang 13 CATR 14 July 12, 2010 16 Requirement for Multi Stages Multiplexing Configuration in G.709 Optical 17 Transport Network 18 draft-fuxh-ccamp-multi-stage-multiplex-config-req-01 20 Abstract 22 Interworking between regions with 1.25G TS and 2.5G TS has been 23 considered in G.709. Multi stages multiplexing/demultiplexing would 24 be desirable to facilitate the introduction of new ODU0 and ODUflex 25 signals to an existing network without having to upgrade every node 26 in the network. So ODU0/ODUflex can be mapped into ODU1/ODU2/ODU3 27 and transit across the 2.5G TS region. 29 Multi stages multiplexing/demultiplexing are also used to support the 30 multi-domain OTN applications based on the tunnel design. If there 31 are a large number of circuits that share the same endpoints (or even 32 part of an overall path), it may be convenient from a management 33 perspective to first multiplex those ODU0, ODU1 and ODUflex into ODU2 34 or ODU3 to minimize the number of connections that need to be made in 35 intermediate nodes. The ODU2/ODU3 effectively creates a tunnel 36 through the ODU4 network that the ODU0, ODU1 and ODUflex can use. 38 This document describes the requirement of multi stages multiplexing 39 configuration assocaited with some specific scenarios in G.709 40 Optical Transport Network. 42 Conventions Used In This Document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119 [RFC2119]. 48 Status of this Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at http://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on January 13, 2011. 64 Copyright Notice 66 Copyright (c) 2010 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 2. Typical Use Case . . . . . . . . . . . . . . . . . . . . . . . 4 83 2.1. Multi Stages Multiplexing Configuration Requirement 84 for Interworking Between Regions with 1.25G TS and 85 2.5G TS . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 2.2. Multi Stages Multiplexing Configuration Requirement 87 for Multi-Domain OTN Applications . . . . . . . . . . . . 8 88 3. Requirement for Multi Stages Multiplexing Configuration . . . 11 89 3.1. Requirement in the level of the Data Plane . . . . . . . . 11 90 3.2. Requirement in the level of Control Plane and 91 Management Plane . . . . . . . . . . . . . . . . . . . . . 11 92 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 94 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 96 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 99 1. Introduction 101 G.709 has supported a single stage of ODU multiplexing. The 102 practical consequence of this in OTN v1 is an ODU1 can be mapped 103 directly to a tributary slot of an ODU3, without having to be first 104 mapped into an ODU2. The motivation for this architecture is 105 reducing complexity. In the normal progression of things, new 106 additions to the OTN were expected to be at faster bit rates, and 107 thus the single stage concept could be easily maintained going 108 forward. 110 The introduction of ODU0 and ODUflex to the OTN hierarchy creates a 111 situation where the newly added ODUk signals have a bit rate that is 112 lower than any of the existing signals, which presents some different 113 challenges because the new signals can be clients of the existing 114 signals. As a result, there are clear applications where multi 115 stages of multiplexing would be desirable to facilitate the 116 introduction of these new ODU0 and ODUflex signals to an existing 117 network without having to upgrade every node in the network. Using 118 multi stages of multiplexing allows the operator to confine the new 119 rates to only those nodes that need to support them. 121 A second potential application for multi stages outside of an upgrade 122 scenario would be the carrier-carrier, regional-national core 123 interconnection cases or network design based on tunnels. Multi 124 stages multiplexing are used to support these multi-domain OTN 125 applications. 127 This document describes the requirement for multi stages multiplex 128 configuration in G.709 Optical Transport Network. There are multi- 129 stage multiplexing application for some specific scenarios, but it is 130 not a general requirement. This document just havs to associate the 131 requirement with specific scenarios. 133 2. Typical Use Case 135 There may be two use cases to use multi stages multiplexing. But 136 this document doesn't imply restrictions to scenarios for multi 137 stages multiplexing. It just gives some examples of how the multi 138 stage multiplexing can be used in the OTN network. 140 o interworking 1.25G TS and 2.5G TS OTN networks. 142 o carrier-carrier and regional-national core interconnection cases, 143 or network design based on tunnels. 145 2.1. Multi Stages Multiplexing Configuration Requirement for 146 Interworking Between Regions with 1.25G TS and 2.5G TS 148 In Figure 1, node 4, 5, 6 and 7 have ODU1 and ODU2 switching 149 capability. All nodes only support 2.5G TS granularity. They can't 150 support ODU0/ODUflex directly. They could not have any visibility to 151 the ODU0/ODUflex. 153 - 154 /|5|\ 155 / - \ 156 / \ 157 - / ODU3 \ - 158 |4| Network 2 |7| 159 - \ / - 160 \ / 161 \ - / 162 \|6|/ 163 - 165 Figure 1 167 In Figure 2, operator deploys three new 10G OTN networks, such as 168 ODU2 Network 1, ODU 2 Network 3 and ODU2 Network 4. All ODU2 169 networks are interconnected with ODU3 network by OTU3 link. All 170 nodes of three ODU2 networks support the 1.25G TS granularity and are 171 based on G.709 v3. All nodes in ODU2 Network 1 and ODU2 Network 4 172 can support ODU0, ODU1 and ODUflex switching capability. ODU2 173 Network 3 is only desirable to support GigE and ODUflex services, so 174 all nodes in ODU2 Network 3 only support ODU0 and ODUflex for more 175 economical cost. It doesn't support ODU1 (e.g., STM-16) application. 177 -- 178 /|12|\ 179 / -- \ 180 / \ 181 -- / ODU2 \-- 182 |11| Network 4 |13| 183 -- \ / -- 184 \ / 185 \ - / 186 \| |/ 187 - G4 188 | 189 - - - 190 /|2|\ /|5|\ /|8|\ 191 / - \ / - \ / - \ 192 / \ / \ / \ 193 - / ODU2 \ - - / ODU3 \ - - / ODU2 \ -- 194 |1| Network 1 | |----|4| Network 2 |7|---- | | Network 3 |10| 195 - \ / - - \ / - - \ / -- 196 \ / G1 \ / G3 \ / 197 \ - / \ - / \ - / 198 \|3|/ \|6|/ \|9|/ 199 - - - 201 Figure 2 203 There are clear applications where 2 stages of multiplexing within 204 one port would be desirable to facilitate the introduction of these 205 new ODU0 and ODUflex signals to an existing network without having to 206 upgrade every node in the network. In order for the interworking 207 between 1.25G TS and 2.5G TS networks, there must be some nodes which 208 support multi stages multiplexing/demultiplexing to allow ODU0/ 209 ODUflex to be supported across the legacy network. For example, ODU0 210 is mapped first to ODU1 or ODU2, and that ODU1/2 is then mapped into 211 ODU3. Nodes in the legacy network switch the ODU1/ODU2 without 212 having any visibility to the ODU0/ODUflex. Whether ODU1 or ODU2 213 should be created for end-to-end ODU0 service depends on multi stages 214 multiplexing capability. Different nodes may support different multi 215 stages multiplexing capabilities based on the network planning and 216 the capability of network element. 218 G1 is supposed to support the following multi stages multiplexing/ 219 demultiplexing capability. 221 o ODU0-ODU1-ODU3 222 o ODU0-ODU2-ODU3 224 o ODU1-ODU2-ODU3 226 o ODUflex-ODU2-ODU3 228 G3 is supposed to support the following multi stages multiplexing/ 229 demultiplexing capability. 231 o ODU0-ODU2-ODU3 233 o ODUflex-ODU2-ODU3 235 G4 is supposed to support the following multi stages multiplexing/ 236 demultiplexing capability. The operator limits the ODUflex 237 application to the local network. There is no any multi-domain 238 ODUflex application which goes into ODU2 Network 4 and vice versa. 239 So it doesn't need to support the ODUflex-ODU2-ODU3 multiplexing. 241 o ODU0-ODU1-ODU3 243 o ODU0-ODU2-ODU3 245 There are several end-to-end services being provisioned by operator. 247 o E2E ODUflex 1 (e.g., 6*1.25G TS): It transit 1, 3, G1, 4, 6, 7, G3 248 and 8. 250 o E2E GigE 1: It transit 1, 3, G1, 4, 6, 7, G3, 9 and 10. 252 o E2E GigE 2: It transit 2, G1, 4, 5, G4, 11 and 12. 254 o E2E STM-16 1: It transit 1, 2, G1, 4, 5, G4 and 13. 256 The E2E ODUflex 1 (e.g., 6*1.25G TS) and GigE 1 services share the 257 same ODU2 tunnel between G1 and G3. Multi stages multiplexing/ 258 demultiplexing capability must be configured with ODU0-ODU2-ODU3 in 259 G1 and G3 for GigE 1 service. Multi stages multiplexing/ 260 demultiplexing capability must be configured with ODUflex-ODU2-ODU3 261 in G1 and G3 for ODUflex 1 service. There is an ODU 1 tunnel between 262 G4 and G1 for the E2E GigE 2 service. Multi stages multiplexing/ 263 demultiplexing capability must be configured with ODU0-ODU1-ODU3 in 264 G1 and G4 for GigE 2 service. There is no any need to configure 265 multi stages multiplexing/demultiplexing for E2E STM-16 1 service. 267 2.2. Multi Stages Multiplexing Configuration Requirement for Multi- 268 Domain OTN Applications 270 In Figure 3, operator deploys three new OTN networks again, such as 271 ODU2 Network 5, ODU3 Network 7 and ODU4 Network 6. ODU2 network 5 272 and ODU3 network 7 are interconnected with ODU4 network by OTU4 link. 273 All nodes of three new OTN networks support the 1.25G TS granularity 274 and are based on the G.709 v3. All nodes in ODU2 Network 5 support 275 ODU0, ODU1 and ODUflex switching capability. All nodes in ODU3 276 Network 7 support ODU0, ODU1, ODUflex and ODU2 switching capability. 277 All nodes in ODU4 Network 6 only support ODU2 and ODU3 switching 278 capability. 280 In an ODU4 network, there are 80 tributary slots per ODU4. Suppose 281 there are a large number of multi-domain ODU0 and ODUflex demands. 282 If these multi-domain service share the same endpoints (or even part 283 of an overall path), it may be convenient from a management 284 perspective to first multiplex those ODU0 and ODUflex into ODU2 or 285 ODU3 to minimize the number of connections that need to be made in 286 intermediate nodes. It also minimizes managed entities made in core 287 network and support carrier's carrier application. The ODU2/ODU3 288 effectively creates a tunnel through the ODU4 network that the ODU0, 289 ODU1 and ODUflex can use. 291 In order for the tunnel network design, there must be some nodes 292 which support ODU0, ODU1 and ODUflex to be mapped into ODU2/ODU3 293 first and that ODU2/ODU3 is then mapped into ODU4. 295 -- 296 /|12|\ 297 / -- \ 298 / \ 299 -- / ODU2 \-- 300 |11| Network 4 |13| 301 -- \ / -- 302 \ / 303 \ - / 304 \| |/ 305 - G4 306 | 307 | 308 - - - 309 /|2|\ /|5|\ /|8|\ 310 / - \ / - \ / - \ 311 / \ / \ / \ 312 - / ODU2 \ - - / ODU3 \ - - / ODU2 \ -- 313 |1| Network 1 | |----|4| Network 2 |7|---- | | Network 3 |10| 314 - \ / - - \ / - - \ / -- 315 \ /G1 \ / G3 \ / 316 \ - / \ - / \ - / 317 \|3|/ \|6|/ \|9|/ 318 - - - 319 | 320 -- 321 | |G2 322 -- 323 | 324 -- -- -- 325 /|15|\ /|18|\ /|21|\ 326 / -- \ / -- \ / -- \ 327 / \ / \ / \ 328 -- / ODU2 \ -- -- / ODU4 \-- -- / ODU3 \ -- 329 |14| Network 5 | |----|17| Network 6 |20|----| | Network 7 |23| 330 -- \ / -- -- \ /-- -- \ / -- 331 \ /G5 \ / G7 \ / 332 \ -- / \ -- / \ -- / 333 \|16|/ \|19|/ \|22|/ 334 -- -- -- 336 Figure 3 338 G5 is supposed to support the following multi stages multiplexing/ 339 demultiplexing capability. 341 o ODU0-ODU2-ODU4 343 o ODU0-ODU3-ODU4 345 o ODU1-ODU2-ODU4 347 o ODU1-ODU3-ODU4 349 o ODUflex-ODU2-ODU4 351 o ODUflex-ODU3-ODU4 353 G7 is supposed to support the following multi stages multiplexing/ 354 demultiplexing capability. The operator limits the ODU1 application 355 to the local network. There is no any multi-domain ODU1 application 356 which goes into ODU3 Network 7 and vice versa. It doesn't need to 357 support the ODU1-ODU2-ODU4 and ODU1-ODU3-ODU4 multiplexing. 359 o ODU0-ODU2-ODU4 361 o ODU0-ODU3-ODU4 363 o ODUflex-ODU2-ODU4 365 o ODUflex-ODU3-ODU4 367 G2 provides demultiplexing to recover the ODU2 from ODU4 and an 368 additional multiplexing of the ODU2 to ODU3 and vice versa. 370 There are several E2E services. 372 o E2E ODUflex 2 (e.g., 10*1.25G TS): It transit 16, G5, 17, 19, 20, 373 G7, 22 and 23. 375 o E2E GigE 3: It transit 14, 15, G5, 17, 19, 20, G7 and 21. 377 o E2E GigE 4: It transit 15, G5, 17, 18, G2, 6, 7, G3, 9 and 10. 379 o E2E STM-16 2: It transit 15, G5, 17, 18, G2, 6, 4, G1, 3. 381 In Figure 3, the E2E ODUflex 2 (e.g., 10*1.25G TS) and GigE 3 382 services share the same ODU3 tunnel between G5 and G7. Multi stages 383 multiplexing/demultiplexing capability must be configured with ODU0- 384 ODU3-ODU4 in G5 and G7 for GigE 3 service. Multi stages 385 multiplexing/demultiplexing capability must be configured with 386 ODUflex-ODU3-ODU4 in G5 and G7 for ODUflex 2 service. 388 There is an ODU 2 tunnel between G5 and G3 for the E2E GigE 4 389 service. Multi stages multiplexing/demultiplexing capability must be 390 configured with ODU0-ODU2-ODU4 in G5 for GigE 4 service. Multi 391 stages multiplexing/demultiplexing capability must be configured with 392 ODU0-ODU2-ODU3 in G3 for GigE 4 service. 394 There is an ODU 2 tunnel between G5 and G1 for the E2E STM-16 2 395 service. Multi stages multiplexing/demultiplexing capability must be 396 configured with ODU1-ODU2-ODU4 in G5 for STM-16 2 service. Multi 397 stages multiplexing/demultiplexing capability must be configured with 398 ODU1-ODU2-ODU3 in G1 for STM-16 2 service. 400 3. Requirement for Multi Stages Multiplexing Configuration 402 3.1. Requirement in the level of the Data Plane 404 This section describes the basic requirements in the Data Plane to 405 support the multi stages multiplexing configuration functions of this 406 document. In order to introduce new ODU0 and ODUflex signals to an 407 existing network and support multi-domain OTN application based on 408 network tunnel design, if some nodes are designed to support multi 409 stages multiplexing capability, following requirement for these node 410 should be satisfied. 412 o If these nodes can support different multi stages multiplexing 413 hierarchy (e.g., two or three stages, and so on) and multiple 414 multi stages multiplexing capabilities. They must support the 415 multi stages multiplexing configuration from Management Plane 416 and/or Control Plane. They must support to check the local data 417 plane capability to see if this kind of multi stages multiplexing/ 418 demultiplexing from MP and/or CP is acceptable on specific 419 interface. 421 3.2. Requirement in the level of Control Plane and Management Plane 423 This section describes the basic requirements for MP and CP to 424 perform the multi stages multiplexing configuration. 426 o Management Plane: 428 * From the perspective of Management Plane, it must get multi 429 stages multiplexing/demultiplexing capability of each nodes for 430 the service provision. 432 * Management Plane must support to config the multi stages 433 multiplexing hierarchy which is determined by path computation 434 entity into the Data Plane for the E2E service. 436 o Control Plane: 438 * From the perspective of Control Plane, it must get multi stages 439 multiplexing/demultiplexing capability of each nodes for path 440 computation. It can get multi stages multiplexing/ 441 demultiplexing information by Management Plane configuration. 442 Path computation entity can also use the IGP protocol or 443 configurations from Management Plane to get these information. 445 * Path computation element must select a proper kind of multi 446 stages multiplexing/demultiplexing hierarchy of nodes along a 447 specific E2E connection. 449 * Signaling message must carry the multi stages multiplexing/ 450 demultiplexing hierarchy that has been determined by path 451 computation entity. Multi stages multiplexing/demultiplexing 452 hierarchy for a specific service must be configured to data 453 plane after the node which needs to be support multi stages 454 multiplexing receives the signaling of service creation. 456 4. Security Considerations 458 The use of control plane protocols for signaling, routing, and path 459 computation opens an OTN to security threats through attacks on those 460 protocols. The data plane technology for an OTN does not introduce 461 any specific vulnerabilities, and so the control plane may be secured 462 using the mechanisms defined for the protocols discussed. For 463 further details of the specific security measures refer to the 464 documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], 465 [RFC4204], and [RFC5440]). [GMPLS-SEC] provides an overview of 466 security vulnerabilities and protection mechanisms for the GMPLS 467 control plane. 469 5. IANA Considerations 471 TBD 473 6. References 475 6.1. Normative References 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, March 1997. 480 [I-D.ietf-ccamp-gmpls-g709-framework] 481 Zhang, F., Li, D., Li, H., Belotti, S., Han, J., Betts, 482 M., Grandi, P., and E. Varma, "Framework for GMPLS and PCE 483 Control of G.709 Optical Transport Networks", 484 draft-ietf-ccamp-gmpls-g709-framework-00 (work in 485 progress), April 2010. 487 6.2. Informative References 489 Authors' Addresses 491 Xihua Fu 492 ZTE Corporation 494 Email: fu.xihua@zte.com.cn 496 Malcolm Betts 497 ZTE Corporation 499 Email: malcolm.betts@zte.com.cn 501 Ruiquan Jing 502 China Telecom 504 Email: jingrq@ctbri.com.cn 506 Xiaoli Huo 507 China Telecom 509 Email: huoxl@ctbri.com.cn 511 Han Li 512 China Mobile 514 Email: lihan@chinamobile.com 516 Guangquan Wang 517 China Unicom 519 Email: wanggq@dimpt.com 520 Guoying Zhang 521 CATR 523 Email: zhangguoying@mail.ritt.com.cn