idnits 2.17.1 draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 date (October 26, 2009) is 5267 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: 'RFC3945' is mentioned on line 82, but not defined == Missing Reference: 'RFC3471' is mentioned on line 151, but not defined == Missing Reference: 'RFC3473' is mentioned on line 879, but not defined == Missing Reference: 'RFC4328' is mentioned on line 518, but not defined == Missing Reference: 'ITUT-G709-AMD3' is mentioned on line 446, but not defined == Missing Reference: 'NN' is mentioned on line 366, but not defined == Missing Reference: 'ITUT-G.709' is mentioned on line 155, but not defined == Missing Reference: 'RFC2205' is mentioned on line 450, but not defined == Unused Reference: 'RFC3630' is defined on line 899, but no explicit reference was found in the text == Unused Reference: 'RFC4003' is defined on line 903, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 906, but no explicit reference was found in the text == Unused Reference: 'RFC4206' is defined on line 910, but no explicit reference was found in the text == Unused Reference: 'RFC5150' is defined on line 914, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G709' Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Fu, Ed. 3 Internet-Draft ZTE 4 Intended status: Standards Track D. Ceccarelli, Ed. 5 Expires: April 29, 2010 Ericsson 6 M. Corsi, Ed. 7 Altran 8 October 26, 2009 10 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions 11 for evolutive OTNs control 12 draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-01 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 29, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document is a companion to the Generalized Multi-Protocol Label 51 Switching (GMPLS) signaling documents. It describes the technology- 52 specific information needed to extend GMPLS signaling to control 53 Optical Transport Networks (OTN) based on ITU-T G.709 Amendment 3 54 reccomandation. References also to G.sup43 are provided. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. GMPLS Extension for G.709 Amendment 3 . . . . . . . . . . . . 3 61 4. GMPLS Extensions for G.Sup43 . . . . . . . . . . . . . . . . . 4 62 5. Generalized Label Request . . . . . . . . . . . . . . . . . . 4 63 5.1. Traffic Parameters . . . . . . . . . . . . . . . . . . . . 4 64 5.1.1. Signal Type (ST) . . . . . . . . . . . . . . . . . . . 5 65 5.1.2. Number of Multiplexed Components (NMC) . . . . . . . . 6 66 6. Generalized Label . . . . . . . . . . . . . . . . . . . . . . 7 67 6.1. Label Space . . . . . . . . . . . . . . . . . . . . . . . 7 68 6.2. Label Distribution Rules . . . . . . . . . . . . . . . . . 11 69 7. RSVP-TE Signaling Protocol Extensions . . . . . . . . . . . . 11 70 8. Interworking Considerations . . . . . . . . . . . . . . . . . 11 71 9. Example of Generalized Label . . . . . . . . . . . . . . . . . 14 72 10. Acknoledgments . . . . . . . . . . . . . . . . . . . . . . . . 19 73 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 74 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 75 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 76 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 77 15. Normative References . . . . . . . . . . . . . . . . . . . . . 21 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 80 1. Introduction 82 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends 83 MPLS from supporting Packet Switching Capable (PSC) interfaces and 84 switching to include support of four new classes of interfaces and 85 switching: Layer-2 Switching (L2SC), Time-Division Multiplex (TDM), 86 Lambda Switch (LSC), and Fiber-Switch (FSC) Capable. A functional 87 description of the extensions to MPLS signaling that are needed to 88 support these new classes of interfaces and switching is provided in 89 [RFC3471]. [RFC3473] describes the RSVP-TE-specific formats and 90 mechanisms needed to support all four classes of interfaces. 91 [RFC4328] describes the technology details that are specific to G.709 92 Optical Transport Networks (OTN) as defined in ITU-T G.709 93 recommendation [ITUT-G709]. 95 This document extends the concepts presented in [RFC4328] with the 96 technology details introduced by ITU-T G.709 Amendment 3 and G.sup43 97 supplement. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 3. GMPLS Extension for G.709 Amendment 3 107 G.709 Amendment 3 and G.sup43 introduce new signal types in the two 108 layers constituting the digital transport hierarchy: 110 - Optical Channel Transport Unit (OTUk): 111 . OTU4 113 - Optical Channel Data Unit (ODUk): 114 . ODU0 115 . ODU2e 116 . ODU3e1 117 . ODU3e2 118 . ODU4 119 . ODUflex 121 It also adds a new 1,25 Gbps Tributary Slot (TS) granularity for both 122 the new and the old ODUk signals. 124 [ITUT-G709-AMD3] introduces ODU4 mapping into OTU4 (and its related 125 100Gbps optical channel), and new ODUk multiplexing. It refers to 126 the multiplexing of ODUj (j = 0, 1, 2, 2e, 3, and flex) into an ODUk 127 (k > j) signal, in particular: 129 o ODU0 into ODU1 multiplexing 130 o ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS 131 granularity) 132 o ODU0, ODU1, ODUflex, ODU2 and ODU2e into ODU3 multiplexing (with 133 1.25Gbps TS granularity) 134 o ODU0, ODU1, ODU2, ODU3, ODU2e, ODUflex into ODU4 multiplexing 135 (with 1.25Gbps TS granularity) 136 o ODU2e into ODU3e1 multiplexing (with 2,5Gbps TS granularity) 137 o ODU2e into ODU3e2 multiplexing (with 1,25Gbps TS granularity) 139 4. GMPLS Extensions for G.Sup43 141 G.Sup43 introduces two new types of signal: ODU3e1 and ODU3e2. These 142 extension are not normative with respect the ITU-T standardization 143 process. IETF needs to decide if these non normative ITU-T 144 extensions need to be included in the scope of IETF works. In the 145 rest of this ID we will highlight what is normative and what is not 146 with respect to ITU-T process. What is referred to G.Sup43 will be 147 indicated with [NN] tag in the text. 149 5. Generalized Label Request 151 The Generalized Label Request as defined in [RFC3471], includes a 152 common part (i.e. used for any switching technology) and a technology 153 dependent part (i.e. the traffic parameters). Both parts have been 154 extended by [RFC4328] in order to accommodate GMPLS signaling to the 155 G.709 transport plane recommendation (see [ITUT-G.709]) 157 All these extensions are still valid for G.709 Amendment 3 and 158 G.Sup43 and only the technology dependent part is further extended to 159 accommodate GMPLS signaling to the new signals introduced by G.709 160 Amendment 3 and G.Sup43. 162 5.1. Traffic Parameters 164 The G.709 traffic parameters are defined as follows in [RFC4328] 165 Section 3.2: 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Signal Type | Reserved | NMC | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | NVC | Multiplier (MT) | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Reserved | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Generalized label request and traffic parameters 179 In this frame, NMC stands for Number of Multiplexed Components, NVC 180 for Number of Virtual Components and MT for Multiplier. Each of 181 these fields is tailored to support G.709 LSP requests. 183 The RSVP-TE encoding of the G.709 traffic-parameters is detailed in 184 [RFC4328] Section 6. [ITUT-G709-AMD3] defines new signals and 185 Digital Path layer multiplexing combinations, therefore, the Signal 186 Type and Number of Multiplexed Components fields need to be extended. 188 5.1.1. Signal Type (ST) 190 This field (8 bits) indicates the type of G.709 Elementary Signal 191 that comprises the requested LSP. Since G.709 Amendment 3 and 192 G.Sup43 defines new ODUk and OCh layers, additional Signal Type code- 193 points for G.709 Amendment 3 are defined to enlarge the existing ST 194 code-point defined in [RFC4328]. 196 Following is the Signal Type extended for G.709 Amendment 3 and 197 G.sup43. Values from 0 to 8 are defined in [RFC4328]. The size of 198 OPU2 and OPU3 tributary slots which are define in [RFC4328] is 2.5G. 200 Value Type 201 ----- ---- 202 0 Not significant 203 1 ODU1 (i.e., 2.5 Gbps) 204 2 ODU2 (i.e., 10 Gbps) 205 3 ODU3 (i.e., 40 Gbps) 206 4 Reserved (for future use) 207 5 Reserved (for future use) 208 6 OCh at 2.5 Gbps 209 7 OCh at 10 Gbps 210 8 OCh at 40 Gbps 211 9 OCh at 100 Gbps 212 10 ODU0 213 11 ODU2e 214 12 ODUflex 215 13 ODU4 216 14-255 Reserved (for future use) 218 5.1.2. Number of Multiplexed Components (NMC) 220 The NMC values difined for G.709 Amendment 3 and G.sup43 are as 221 follows: 223 NMC Description 224 --- ----------- 225 1 ODU0 is mapped into 1.25G tributary slots of OPU1. 226 1 ODU0 is mapped into 1.25G tributary slots of OPU2. 227 1 ODU0 is mapped into 1.25G tributary slots of OPU3. 228 1 ODU0 is mapped into 1.25G tributary slots of OPU4. 230 1 ODU1 is mapped into 2.5G tributary slots of OPU2. 231 1 ODU1 is mapped into 2.5G tributary slots of OPU3. 232 2 ODU1 is mapped into 1.25G tributary slots of OPU2. 233 2 ODU1 is mapped into 1.25G tributary slots of OPU3. 234 2 ODU1 is mapped into 1.25G tributary slots of OPU4. 236 4 ODU2 is mapped into 2.5G tributary slots of OPU3. 237 8 ODU2 is mapped into 1.25G tributary slots of OPU3. 238 8 ODU2 is mapped into 1.25G tributary slots of OPU4. 240 9 ODU2e is mapped into 1.25G tributary slots of OPU3. 241 8 ODU2e is mapped into 1.25G tributary slots of OPU4. 242 8 ODU2e is mapped into 1.25G tributary slots of OPU3e2. 243 4 ODU2e is mapped into 2.5G tributary slots of OPU3e1. 245 31 ODU3 is mapped into 1.25G tributary slots of OPU4. 247 1-8 ODUflex is mapped into 1.25G tributary slots of OPU2. 248 1-32 ODUflex is mapped into 1.25G tributary slots of OPU3. 249 1-80 ODUflex is mapped into 1.25G tributary slots of OPU4. 251 6. Generalized Label 253 6.1. Label Space 255 At the Digital Path layer (i.e. ODUk layers), G.709, G.709 Amendment 256 3 and G.sup43 define seven different client payload bit rates. An 257 Optical Data Unit (ODU) frame has been defined for each of these bit 258 rates. ODUk refers to the frame at bit rate k, where k =0 (for 1.25 259 Gpbs), k = 1 (for 2.5 Gbps), 2 (for 10 Gbps), 2e for (10.25 Gbps), 3 260 (for 40 Gbps), 4 (for 100 Gbps) or flex (for 1.25*ts). 262 In addition to the support of ODUk mapping into OTUk, the G.709 label 263 space supports the sub-levels of ODUk multiplexing. ODUk 264 multiplexing refers to multiplexing of ODUj (j = 0, 1, 2, 2e, 3, 265 3e1,3e2 and flex) into an ODUk (k > j). 267 Following is the ODUk label format for the G.709 Amendment 3 and 268 G.sup43. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | reserve | t4 | t3 | t2 |t1 | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 1: Label Format for G.709 Amendment 3 and G.sup43 278 The specification of the fields t1, t2, t3 and t4 self-consistently 279 characterizes the ODUk label space. The value space for the t1, t2, 280 t3 and t4 fields is defined as follows: 282 1. t1 (2-bit): 284 * t1=[1..2] indicates the tributary slot (t1th) used by the ODU0 285 in an ODTUG1 (via ODTU01) mapped into an ODU1 (via OPU1). 286 ODU0 is mapped into 1.25G tributary slots of OPU1. 288 * t1 is not significant for the other ODUk signal types (i.e., 289 t1 value MUST be set to 0 and ignored). 291 2. t2 (5-bit): 293 * t2=[1..8] indicates the tributary slot (t2th) used by the ODU0 294 in an ODTUG2 (via ODTU02) mapped into an ODU2 (via OPU2). 295 ODU0 is mapped into 1.25G tributary slots of OPU2. 297 * t2=[9..16] indicates the tributary slot (t2th-8) used by the 298 ODU1 in an ODTUG2 (via ODTU12) mapped into an ODU2 (via OPU2). 299 ODU1 is mapped into 1.25G tributary slots of OPU2. Two labels 300 need to be allocated for one ODU1 connection. They may be 301 continuous or non-continuous. 303 * t2=[17..24] indicates the tributary slot (t2th-16) used by the 304 ODUflex in an ODTUG2 (via ODTU2.ts) mapped into an ODU2 (via 305 OPU2). ODUflex is mapped into 1.25G tributary slots of OPU2. 306 How many labels need to be allocated for one ODUflex 307 connection is based on transport of a particular physical 308 layer client. The number of label is determined by the NMC 309 value. They may be continuous or non-continuous. 311 * t3=31 indicates an ODU2e sinal that is not further sub- 312 divided. Two control planes controlling G.sup43 network 313 elements which will be interworked should base on this 314 Generalized Label format. 316 * t2 is not significant for the other ODUk signal types (i.e., 317 t2 value MUST be set to 0 and ignored). 319 3. t3 (8-bit): 321 * t3=[1..32] indicates the tributary slot (t3th) used by the 322 ODU0 in an ODTUG3 (via ODTU03) mapped into an ODU3 (via OPU3). 323 ODU0 is mapped into 1.25G tributary slots of OPU3. 325 * t3=[33..64] indicates the tributary slot (t3th-32) used by the 326 ODU1 in an ODTUG3 (via ODTU13) mapped into an ODU3 (via OPU3). 327 ODU1 is mapped into 1.25G tributary slots of OPU3. Two labels 328 need to be allocated for one ODU1 connection. They may be 329 continuous or non-continuous. 331 * t3=[65..96] indicates the tributary slot (t3th-64) used by the 332 ODU2 in an ODTUG3 (via ODTU23) mapped into an ODU3 (via OPU3). 333 ODU2 is mapped into 1.25G tributary slots of OPU3. Eight 334 labels need to be allocated for one ODU2 connection. They may 335 be continuous or non-continuous. 337 * t3=[97..128] indicates the tributary slot (t3th-96) used by 338 the ODU2e in an ODTUG3 (via ODTU3.ts) mapped into an ODU3 (via 339 OPU3). ODU2e is mapped into 1.25G tributary slots of OPU3. 340 Nine labels need to be allocated for one ODU2e connection. 341 They may be continuous or non-continuous. 343 * t3=[129..160] indicates the tributary slot (t3th-128) used by 344 the ODUflex in an ODTUG3 (via ODTU3.ts) mapped into an ODU3 345 (via OPU3). ODUflex is mapped into 1.25G tributary slots of 346 OPU3. How many labels needs to be allocated for one ODUflex 347 connection is based on transport of a particular physical 348 layer client. The number of label is determined by the NMC 349 value. They may be continuous or non-continuous. 351 * t3=[161..176] indicates the tributary slot (t5th-160) used by 352 the ODU2e in an ODTUG3e1 (via ODTU2e3e1) mapped into an ODU3e1 353 (via OPU3e1). ODU2e is mapped into 2.5G tributary slots of 354 OPU3e1. Four labels need to be allocated for one ODU2e 355 connection. They may be continuous or non-continuous. [NN] 357 The mapping of ODU2e into four 2.5G tributary slots is defined 358 in the non normative G.sup43. Two control planes controlling 359 G.sup43 network elements which will be interworked should base 360 on this Generalized Label format. 362 * t3=[177..208] indicates the tributary slot (t5th-176) used by 363 the ODU2e in an ODTUG3e2 (via ODTU2e3e2) mapped into an ODU3e2 364 (via OPU3e2). ODU2e is mapped into 1.25G tributary slots of 365 OPU3e2. Eight labels need to be allocated for one ODU2e 366 connection.[NN] 367 The mapping of ODU2e into eight 1.25G tributary slots is 368 defined in the non normative G.sup43. Two control planes 369 controlling G.sup43 network elements which will be interworked 370 should base on this Generalized Label format. 372 * t3 is not significant for the other ODUk signal types (i.e., 373 t3 value MUST be set to 0 and ignored). 375 4. t4 (9-bit): 377 * t4=1 indicates an ODU4 signal that is not further sub-divided. 379 * t4=[2..81] indicates the tributary slot (t4th-1) used by the 380 ODU0 in an ODTUG4 (via ODTU4.1) mapped into an ODU4 (via 381 OPU4). ODU0 is mapped into 1.25G tributary slots of OPU4. 383 * t4=[82..161] indicates the tributary slot (t4th-81) used by 384 the ODU1 in an ODTUG4 (via ODTU4.2) mapped into an ODU4 (via 385 OPU4). ODU1 is mapped into 1.25G tributary slots of OPU4. 386 Two labels need to be allocated for one ODU1 connection. They 387 may be continuous or non-continuous. 389 * t4=[162..241] indicates the tributary slot (t4th-161) used by 390 the ODU2 in an ODTUG4 (via ODTU4.8) mapped into an ODU4 (via 391 OPU4). ODU2 is mapped into 1.25G tributary slots of OPU4. 392 Eight labels need to be allocated for one ODU2 connection. 393 They may be continuous or non-continuous. 395 * t4=[242..321] indicates the tributary slot (t4th-241) used by 396 the ODU2e in an ODTUG4 mapped into an ODU4 (via OPU4). ODU2e 397 is mapped into 1.25G tributary slots of OPU4. Eight labels 398 need to be allocated for one ODU2e connection. They may be 399 continuous or non-continuous. 401 * t4=[322..401] indicates the tributary slot (t4th-321) used by 402 the ODUflex (via ODTU4.ts) in an ODTUG4 mapped into an ODU4 403 (via OPU4). ODUflex is mapped into 1.25G tributary slots of 404 OPU4. How many labels needs to be allocated for one ODUflex 405 connection is based on transport of a particular physical 406 layer client. The number of label is determined by the NMC 407 value. They may be continuous or non-continuous. 409 * t4=[402..481] indicates the tributary slot (t4th-401) used by 410 the ODU3 (via ODTU4.32) in an ODTUG4 mapped into an ODU4 (via 411 OPU4). ODU3 is mapped into 1.25G tributary slots of OPU4. 412 Tirty-one labels need to be allocated for one ODU3 connection. 413 They may be continuous or non-continuous. 415 * t4 is not significant for the other ODUk signal types (i.e., 416 t4 value MUST be set to 0 and ignored). 418 6.2. Label Distribution Rules 420 Label distribution rules are defined in [RFC4328] Section 4.2. 422 7. RSVP-TE Signaling Protocol Extensions 424 RSVP-TE will reuse the protocol extensions defined in [RFC4328] 425 Section 6 and does not need to be further extended. When a node 426 receives a Generalized Label Request, it can infer the label format 427 from the Signal Type and NMC pair. It don't need to depend on any 428 other means (e.g., management configuration or auto-discocvery). 429 Following is the example how to infer label format. 431 Signal Type NMC Label Format 432 ODU0 * [New Label Format] 433 ODU2e * [New Label Format] 434 ODUflex * [New Label Format] 435 ODU4 * [New Label Format] 436 ODU1 2 ----->[New Label Format] 437 ODU2 8 [New Label Format] 438 ODU3 31 [New Label Format] 439 ODU1 1 [RFC4328] 440 ODU2 4 [RFC4328] 441 ODU1 0 [RFC4328] 442 ODU2 0 [RFC4328] 443 ODU3 0 [RFC4328] 445 Instead when a non G.709 Amendment 3 aware node receives a 446 Generalized Label Request for a signals introduced in [ITUT-G709- 447 AMD3], it will not support the requested Signal Type and/or NMC 448 values. Then the receiver node MUST generate a PathErr message with 449 a "Traffic Control Error/Service unsupported" indication (see 450 [RFC2205]) as specified in [RFC4328]. 452 8. Interworking Considerations 454 ODU multiplex structure of G.709(200303) only supports 2.5G TS. ODU 455 multiplex structure of G.709 Amd3 can support 1.25G TS or 2.5G TS and 456 1.25G TS. In terms of G.709 Amd 3, HO OPU2 and HO OPU3 interface 457 ports supporting 1.25 TS must also support the 2.5 TS mode for 458 interworking with interface ports supporting only the 2.5G TS mode. 459 When a 1.25G TS capable equipment receive the OPUk signal whose 460 Payload Type is 2.5G TS multiplex structure from the far end, it 461 shall operate in 2.5G TS mode. It should be an automatic adaptataion 462 process. 464 There must be some considerations on interworking between 465 G.709(200303) and G.709 Amd3 in the perspective of control plane. 466 Control plane designed for G.709 Amendment 3 should have the ability 467 to synchronously process the different Generalized Label format of 468 ODU1, ODU2 and ODU3 defined in [RFC4328] and this document. The 469 extension defined in this document is a supplement and extension of 470 [RFC4328]. 472 1. When a new Path (Resv) message is to be sent for a downstream 473 (upstream) TE link, the format of Generalized Label is determined 474 by the Signal Type and/or multiplex structure of this port. 476 * If the Signal Type is ODU0, ODU2e, ODUflex or ODU4, the format 477 of Generalized Label must be based on this document. 479 * If the Signal Type is ODU1, ODU2 or ODU3 and the port is 480 operated only in 2.5G TS mode, the format of Generalized Label 481 must be based on [RFC4328]. 483 * If the Signal Type is ODU1, ODU2 or ODU3 and the port supports 484 mapping directly into OTU1, OTU2 or OTU3, the format of 485 Generalized Label must be based on [RFC4328]. 487 * If the Signal Type is ODU1, ODU2 or ODU3 and the port is 488 operated only in 1.25G TS or 2.5G TS and 1.25G TS mode, it 489 should try 1.25G TS mode firstly and the format of Generalized 490 Label must be based on this document. 492 If the interface port of downstream node can not support this 493 multiplex structure, the Path (Resv) message will be 494 terminated, and a PathErr message will be sent to the ingress, 495 or a ResvErr sent to the egress. The PathErr or ResvErr 496 including the IF_ID and ERROR_SPEC object should carry the 497 crankback information with a "Traffic Control Error/Service 498 unsupported" indication. 500 The ingress node will attemp to singal again with the same 501 routing. So this node will try 2.5G TS mode and the format of 502 Generalized Label must be based on [RFC4328]. 504 2. When a new Path (Resv) message is to be received on a upstream 505 (downstream) TE link, the Generalized Label format is identified 506 by the Signal Type and NMC pair in Traffic Parameters. 508 * When the Signal Type and NMC pair is (ODU1, 2), (ODU2, 8) or 509 (ODU3, 31), the format of Generalized Label should be based on 510 this document, the node must check the interface port mode. 511 If it can not support 1.25G TS mode or the Signal Type, the 512 Path (Resv) message will be terminated, and a PathErr message 513 with a "Traffic Control Error/Service unsupported" indication 514 will be generated. 516 * When the Signal Type and NMC pair is (ODU1, 1), (ODU1, 0), 517 (ODU2, 4), (ODU2, 0), or (ODU3, 0), the format of Generalized 518 Label should be based on [RFC4328]. In this case the receiver 519 will always support this label format. If it can not support 520 this Signal Type, the Path (Resv) message will be terminated, 521 and a PathErr message with a "Traffic Control Error/Service 522 unsupported" indication will be generated. 524 * When a downstream (upstream) node receives Path (Resv) message 525 in which Signal Type is ODU0, ODU2e, ODUflex and ODU4, it must 526 identify the Generalized Label format based on this document. 527 If it can not support this Signal Type, the Path (Resv) 528 message will be terminated, and a PathErr message with a 529 "Traffic Control Error/Service unsupported" indication will be 530 generated. 532 Following figure is a interworking example between G.709(200303) and 533 G.709 Amd 3. 535 4*2.5G TS 32*1.25G TS 80*1.25G TS 16*2.5G TS 8*1.25G TS 536 | | | | | 537 | | | | | 538 \|/ \|/ \|/ \|/ \|/ 539 +----+ OTU2 +----+ OTU3 +----+ OTU4 +----+ OTU3 +----+ OTU2 +----+ 540 -|DXC1|------|DXC2|------|DXC3|------|DXC4|-------|DXC5|-------|DXC6|- 541 +----+ +----+ +----+ +----+ +----+ +----+ 543 Figure 2: Interworking Scenario between G.709(200303) and G.709 Amd3 545 When we need to setup a ODU2 (10G bandwidth) LSP between DXC1 and 546 DXC6, the path computation entiy may computate an DXC1-DXC2-DXC3- 547 DXC4-DXC5-DXC6 route. 549 1. In the case of one end-to-end session, the NMC has to be changed 550 in node where the TE link supporting 1.25G TS and the TE link 551 supporting 2.5G TS are connected (i.e., DXC2, DXC4, and DXC5). 553 +----+ +----+ +----+ +----+ +----+ +----+ 554 -|DXC1|------|DXC2|------|DXC3|------|DXC4|-------|DXC5|-------|DXC6|- 555 +----+ +----+ +----+ +----+ +----+ +----+ 556 Path Path Path Path Path 557 -------> ------> ------> -------> -------> 558 ST=ODU2 ST=ODU2 ST=ODU2 ST=ODU2 ST=ODU2 559 NMC=4 NMC=8 NMC=8 NMC=4 NMC=8 561 Resv Resv Resv Resv Resv 562 <------- <------ <------ <------- <------- 563 ST=ODU2 ST=ODU2 ST=ODU2 ST=ODU2 ST=ODU2 564 NMC=4 NMC=8 NMC=8 NMC=4 NMC=8 566 Figure 3: Contiguous TE LSP 568 2. The end-to-end connection also can be setuped with multiple 569 segment session (i.e., ODU1 LSP1, ODU1 LSP2, ODU1 LSP3, ODU1 570 LSP4). 572 +----+ +----+ +----+ +----+ +----+ +----+ 573 -|DXC1|------|DXC2|------|DXC3|------|DXC4|-------|DXC5|-------|DXC6|- 574 +----+ +----+ +----+ +----+ +----+ +----+ 575 | | | | | 576 |<-ODU1 LSP1->|<-----ODU1 LSP2------>|<-ODU1 LSP3->|<-ODU1 LSP4->| 578 Figure 4: Stitching TE LSP 580 if the segment LSP can be created and prepaired for stitching by 581 signaling, the end-to-end connection is stitched to several 582 segment LSPs (i.e., ODU1 LSP1, ODU1 LSP2, ODU1 LSP3, ODU1 LSP4). 583 The NMC in traffic parameters of this end-to-end session is no 584 meaning. 586 9. Example of Generalized Label 588 The following examples are given in order to illustrate the 589 processing described in this document. 591 1. ODU2e in OTU2e mapping or ODU4 in OTU4 mapping: when one ODU2e 592 (ODU4) signal is directly transported in an OTU2e (OTU4),the 593 upstream node requests results simply in an ODU2e (ODU4) signal 594 request. 596 In such conditions, the downstream node has to return a unique 597 label because the ODU2e (ODU4) is directly mapped into the 598 corresponding OTU2e (OTU4). Because a single ODUk signal is 599 requested, the downstream node has to return a single ODUk 600 label, which can be, for instance, one of the following: 602 - Signal type=ODU4, t4=1, t3=0, t2=0, t1=0; 603 indicates a single ODU4 mapped into an OTU4 605 - Signal type=ODU2e, t4=0, t3=0, t2=31, t1=0; 606 indicates a single ODU2e mapped into an OTU2e 608 2. ODU0 into ODUk multiplexing (k = 1, 2, 3 or 4): when one ODU0 is 609 multiplexed into the payload of a structured ODU1 (ODU2, ODU3 or 610 ODU4), the upstream node requests results simply in an ODU0 611 signal request. 613 In such conditions, the downstream node has to return a unique 614 label because the ODU0 is multiplexed into one ODTUG1 (ODTUG2, 615 ODTUG3 or OTDUG4). The latter is then mapped into the ODU1 616 (ODU2, ODU3 or ODU4) via OPU1 (OPU2, OPU3 or OPU4) and then 617 mapped into the corresponding OTU1 (OTU2, OTU3 or OTU4). 618 Because a single ODU0 multiplexed signal is requested (Signal 619 Type = ODU0 and NMC = 1), the downstream node has to return a 620 single ODU0 label, which can take, for instance, one of the 621 following values: 623 - t4=0, t3=0, t2=0, t1=1; 624 indicates the ODU0 in the 1st TS of the ODTUG1 626 - t4=0, t3=0, t2=4, t1=0; 627 indicates the ODU0 in the 4th TS of the ODTUG2 629 - t4=0, t3=26, t2=0, t1=0; 630 indicates the ODU0 in the 26th TS of the ODTUG3 632 - t4=69, t3=0, t2=0, t1=0; 633 indicates the ODU0 in the 68th TS of the ODTUG4 635 3. ODU1 into 1.25G tributary slots of OPUk (k = 2, 3, 4) 636 multiplexing: when one ODU1 is multiplexed into the payload of a 637 structured ODU2 (ODU3 or ODU4), the upstream node requests 638 results simply in an ODU1 signal request. 640 In such conditions, the downstream node has to return two labels 641 because the ODU1 is multiplexed into one ODTUG2 (ODTUG3 or 642 ODTUG4). The latter is then mapped into the ODU2 (ODU3 or ODU4) 643 via OPU2 (OPU3 or OPU4) and then mapped into the corresponding 644 OTU2 (OTU3 or OTU4). Because a single ODU1 multiplexed signal 645 is requested (Signal Type = ODU1 and NMC = 2), the downstream 646 node has to return two ODU1 labels, which can take, for 647 instance, the following values: 649 - t4=0, t3=0, t2=13, t1=0; 650 indicates the ODU1 in the 5th 1.25G TS of the ODTUG2 652 or 654 - t4=0, t3=58, t2=0, t1=0; 655 indicates the ODU1 in the 26th 1.25G TS of the ODTUG3 657 or 659 - t4=82, t3=0, t2=0, t1=0; 660 indicates the ODU1 in the 1st 1.25G TS of the ODTUG4 662 4. ODU2 into 1.25G tributary slots of OPU3: when one ODU2 is 663 multiplexed into the payload of a structured ODU3, the upstream 664 node requests results simply in an ODU2 signal request. 666 In such conditions, the downstream node has to return eight 667 labels because the ODU2 is multiplexed into one ODTUG3. The 668 latter is then mapped into the ODU3 via OPU3 and then mapped 669 into the corresponding OTU3. Because a single ODU1 multiplexed 670 signal is requested (Signal Type = ODU2 and NMC = 8), the 671 downstream node has to return eight ODU2 labels, which can take, 672 for instance, the following values: 674 - t4=0, t3=67, t2=0, t1=0; 675 indicates the ODU2 in the 3rd 1.25G TS of the ODTUG3 677 - t4=0, t3=73, t2=0, t1=0; 678 indicates the ODU2 in the 9th 1.25G TS of the ODTUG3 680 - t4=0, t3=82, t2=0, t1=0; 681 indicates the ODU2 in the 18th 1.25G TS of the ODTUG3 683 5. ODU2/ODU2e into ODU4 multiplexing: when one ODU2 (or ODU2e) is 684 multiplexed into the payload of a structured ODU4, the upstream 685 node requests results simply in an ODU2 (or ODU2e) signal 686 request. 688 In such conditions, the downstream node has to return eight 689 labels because the ODU2 (ODU2e) is multiplexed into one ODTUG4. 690 The latter is then mapped into the ODU4 via OPU4 and then mapped 691 into the corresponding OTU4. Because a single ODU2 (or ODU2e) 692 multiplexed signal is requested (Signal Type = ODU2 and NMC = 8 693 or Signal Type = ODU2e and NMC = 8), the downstream node has to 694 return eight ODU2 (or ODU2e) labels, one of which can take, for 695 instance, the following values: 697 - Signal type=ODU2, t4=182, t3=0, t2=0, t1=0; 698 indicates the ODU2 in the 21st TS of the ODTUG4 700 - Signal type=ODU2e, t4=320, t3=0, t2=0, t1=0; 701 indicates the ODU2e in the 79th TS of the ODTUG4 703 6. ODU3 into ODU4 multiplexing: when one ODU3 is multiplexed into 704 the payload of a structured ODU4, the upstream node requests 705 results simply in an ODU3 signal request. 707 In such conditions, the downstream node has to return thirty-two 708 labels because the ODU3 is multiplexed into one ODTUG4. The 709 latter is then mapped into the ODU4 via OPU4 and then mapped 710 into the corresponding OTU4. Because a single ODU3 multiplexed 711 signal is requested (Signal Type = ODU3 and NMC = 31), the 712 downstream node has to return thirty-one ODU3 labels, one of 713 which can take, for instance, the following values: 715 - t4=408, t3=0, t2=0, t1=0; 716 indicates the ODU3 in the 7th TS of the ODTUG4 718 - t4=449, t3=0, t2=0, t1=0; 719 indicates the ODU3 in the 48th TS of the ODTUG4 721 - t4=472, t3=0, t2=0, t1=0; 722 indicates the ODU3 in the 71st TS of the ODTUG4 724 7. ODU2e into 1.25G tributary slots of OPU3: when one ODU2e is 725 multiplexed into the payload of a structured ODU3, the upstream 726 node requests results simply in an ODU2e signal request. 728 In such conditions, the downstream node has to return nine 729 labels because the ODU2e is multiplexed into one ODTUG3. The 730 latter is then mapped into the ODU3 via OPU3 and then mapped 731 into the corresponding OTU3. Because a single ODU2e multiplexed 732 signal is requested (Signal Type = ODU2e and NMC = 9), the 733 downstream node has to return nine ODU2e labels, one of which 734 can take, for instance, the following values: 736 - t4=0, t3=100, t2=0, t1=0; 737 indicates the ODU2e in the 4th 1.25G TS of the ODTUG3 739 - t4=0, t3=112, t2=0, t1=0; 740 indicates the ODU2e in the 16th 1.25G TS of the ODTUG3 742 - t4=0, t3=120, t2=0, t1=0; 743 indicates the ODU2e in the 24th 1.25G TS of the ODTUG3 745 8. [NN]-ODU2e into ODU3e1 multiplexing: when one ODU2e is 746 multiplexed into the payload of a structured ODU3e1, the 747 upstream node requests results simply in an ODU2e signal 748 request. 750 In such conditions, the downstream node has to return four 751 labels because the ODU2e is multiplexed into one ODTUG3e1. The 752 latter is then mapped into the ODU3e1 via OPU3e1 and then mapped 753 into the corresponding OTU3e1. Because a single ODU2e 754 multiplexed signal is requested (Signal Type = ODU2e and NMC = 755 4), the downstream node has to return four ODU2e labels, which 756 can take, for instance, the following values: 758 - t4=0, t3=161, t2=0, t1=0; 759 indicates the ODU2e in the 1st TS of the ODTUG3e1 761 - t4=0, t3=166, t2=0, t1=0; 762 indicates the ODU2e in the 6th TS of the ODTUG3e1 764 - t4=0, t3=170, t2=0, t1=0; 765 indicates the ODU2e in the 10th TS of the ODTUG3e1 767 - t4=0, t3=175, t2=0, t1=0; 768 indicates the ODU2e in the 15th TS of the ODTUG3e1 770 9. [NN]-ODU2e into ODU3e2 multiplexing: when one ODU2e is 771 multiplexed into the payload of a structured ODU3e2, the 772 upstream node requests results simply in an ODU2e signal 773 request. 775 In such conditions, the downstream node has to return eight 776 labels because the ODU2e is multiplexed into one ODTUG3e2. The 777 latter is then mapped into the ODU3e2 via OPU3e2 and then mapped 778 into the corresponding OTU3e2. Because a single ODU2e 779 multiplexed signal is requested (Signal Type = ODU2e and NMC = 780 8), the downstream node has to return eight ODU2e labels, one of 781 which can take, for instance, the following values: 783 - t4=0, t3=181, t2=0, t1=0; 784 indicates the ODU2e in the 5th TS of the ODTUG3e2 786 - t4=0, t3=197, t2=0, t1=0; 787 indicates the ODU2e in the 21st TS of the ODTUG3e2 789 - t4=0, t3=207, t2=0, t1=0; 790 indicates the ODU2e in the 31st TS of the ODTUG3e2 792 10. ODUflex is mapped into 1.25G tributary slots of OPU2 (OPU3 or 793 OPU4). when one ODUflex is multiplexed into the payload of a 794 structured ODU2 (ODU3 or ODU4), the upstream node requests 795 results simply in an ODUflex signal request. 797 In such conditions, the downstream node has to return some 798 labels whose number is determined in terms of NMC value. 799 Because the ODUflex is multiplexed into one ODTUG2 (ODTUG3 or 800 ODTUG4). The latter is then mapped into the ODU2 (ODU3 or ODU4) 801 via OPU2 (OPU3 or OPU4) and then mapped into the corresponding 802 OTU2 (OTU3 or OTU4). Because a single ODUflex multiplexed 803 signal is requested (Signal Type = ODUflex), the downstream node 804 has to return some labels (i.e., the number of labels is NMC), 805 which can take, for instance, the following values: 807 - t4=0, t3=0, t2=21, t1=0; 808 indicates the ODUflex in the 5th 1.25G TS of the ODTUG2 810 or 812 - t4=0, t3=150, t2=0, t1=0; 813 indicates the ODUflex in the 22nd 1.25G TS of the ODTUG3 815 or 817 - t4=368, t3=0, t2=0, t1=0; 818 indicates the ODUflex in the 47th 1.25G TS of the ODTUG4 820 10. Acknoledgments 822 We wish to thank Attila Takacs and Andras Kern for their assistance 823 and precious advices to prepare this draft for publication. 825 11. Contributors 827 Diego Caviglia 828 Ericsson 829 Via A. Negrone 1/A 830 Genova - Sestri Ponente 831 Italy 833 Email: diego.caviglia@ericsson.com 835 Francesco Fondelli 836 Ericsson 837 Via A. Negrone 1/A 838 Genova - Sestri Ponente 839 Italy 841 Email: francesco.fondelli@ericsson.com 843 Ming Ke 844 ZTE Corporation 845 3F,R&D Building 3,ZTE Industrial Park,XiLi LiuXian Road 846 Nanshan District,Shenzhen 518055 847 P.R.China 849 Email: ke.ming@zte.com.cn 851 Yuanlin Bao 852 ZTE Corporation 853 5F,R&D Building 3,ZTE Industrial Park,XiLi LiuXian Road 854 Nanshan District,Shenzhen 518055 855 P.R.China 857 Email: bao.yuanlin@zte.com.cn 859 Lizhong Jin 860 Nokia Siemens Networks 861 Building 89, 1122 North QinZhou Road, 862 Shanghai, 200211 863 P.R.China 865 Email: lizhong.jin@nsn.com 867 12. Security Considerations 869 The procedures described in this document rely completely on RSVP-TE 870 messages and mechanism. The use of H bit set in Admin Status Object 871 basically informs the receiving entity that no operations are to be 872 done over Data Plane as consequence of such special signaling flow. 873 Using specially flagged signaling messages we want to limit the 874 function of setup and tear down messages to Control Plane, making 875 them not effective over related Data Plane resource usage. So, no 876 additional or special issues are arisen by adopting this procedure, 877 that aren't already brought up by the use of the same messages, 878 without H bit setting, for LSP control. For RSVP-TE Security please 879 refer to [RFC3473]. 881 13. IANA Considerations 883 TBD. 885 14. Acknowledgments 887 The RFC text was produced using Marshall Rose's xml2rfc tool. 889 15. Normative References 891 [ITUT-G709] 892 ITU-T, "Interface for the Optical Transport Network 893 (OTN)", G.709 Recommendation (and Amendment 1) , 894 October 2001. 896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 897 Requirement Levels", BCP 14, RFC 2119, March 1997. 899 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 900 (TE) Extensions to OSPF Version 2", RFC 3630, 901 September 2003. 903 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 904 Control", RFC 4003, February 2005. 906 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 907 of Generalized Multi-Protocol Label Switching (GMPLS)", 908 RFC 4203, October 2005. 910 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 911 Hierarchy with Generalized Multi-Protocol Label Switching 912 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 914 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, 915 "Label Switched Path Stitching with Generalized 916 Multiprotocol Label Switching Traffic Engineering (GMPLS 917 TE)", RFC 5150, February 2008. 919 Authors' Addresses 921 Xihua Fu 922 ZTE 923 West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District 924 Xi An 710065 925 P.R.China 927 Phone: +8613798412242 928 Email: fu.xihua@zte.com.cn 929 URI: http://wwwen.zte.com.cn/ 931 Daniele Ceccarelli 932 Ericsson 933 Via A. Negrone 1/A 934 Genova - Sestri Ponente 935 Italy 937 Phone: 938 Email: daniele.ceccarelli@ericsson.com 940 Marco Corsi 941 Altran 942 Via A. Negrone 1/A 943 Genova - Sestri Ponente 944 Italy 946 Phone: 947 Email: marco.corsi@altran.it