idnits 2.17.1 draft-fuxh-ccamp-gmpls-extension-for-evolutive-otn-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (November 9, 2009) is 5280 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 838, 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 858, but no explicit reference was found in the text == Unused Reference: 'RFC4203' is defined on line 862, but no explicit reference was found in the text == Unused Reference: 'RFC4206' is defined on line 866, but no explicit reference was found in the text == Unused Reference: 'RFC5150' is defined on line 874, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G709' Summary: 1 error (**), 0 flaws (~~), 12 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. Ke 4 Intended status: Standards Track Y. Bao 5 Expires: May 13, 2010 ZTE Corporation 6 November 9, 2009 8 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions 9 for Evolutive OTNs control 10 draft-fuxh-ccamp-gmpls-extension-for-evolutive-otn-02 12 Abstract 14 This document is a companion to the Generalized Multi-Protocol Label 15 Switching (GMPLS) signaling documents. It describes the technology- 16 specific information needed to extend GMPLS signaling to control 17 Optical Transport Networks (OTN) based on ITU-T G.709 Amendment 3 18 reccomandation. References also to G.sup43 are provided. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on May 13, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. GMPLS Extension for G.709 Amendment 3 . . . . . . . . . . . . 3 63 4. GMPLS Extensions for G.Sup43 . . . . . . . . . . . . . . . . . 4 64 5. Generalized Label Request . . . . . . . . . . . . . . . . . . 4 65 5.1. Traffic Parameters . . . . . . . . . . . . . . . . . . . . 4 66 5.1.1. Signal Type (ST) . . . . . . . . . . . . . . . . . . . 5 67 5.1.2. Number of Multiplexed Components (NMC) . . . . . . . . 6 68 6. Generalized Label . . . . . . . . . . . . . . . . . . . . . . 7 69 6.1. Label Space . . . . . . . . . . . . . . . . . . . . . . . 7 70 6.2. Label Distribution Rules . . . . . . . . . . . . . . . . . 11 71 7. RSVP-TE Signaling Protocol Extensions . . . . . . . . . . . . 11 72 8. Interworking Considerations . . . . . . . . . . . . . . . . . 11 73 9. Example of Generalized Label . . . . . . . . . . . . . . . . . 14 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 76 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 77 13. Normative References . . . . . . . . . . . . . . . . . . . . . 20 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 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 or directly mapping into OTU1, 481 OTU2 or OTU3, the format of Generalized Label must be based on 482 RFC4328. 484 * If the Signal Type is ODU1, ODU2 or ODU3 and the port is 485 operated only in 1.25G TS or 2.5G TS and 1.25G TS mode, the 486 format of Generalized Label is bases on the operated mode of 487 far-end interface port of this link. 489 The tributary slot size can be carried in the Interface 490 Switching Capability Descriptor(s) and one LSR can use its TED 491 to determine the ISCD of far-end. Then it can know the 492 tributary slot size of far-end. It shoud not depend on any 493 configuration and discovery function. 495 If the LSR could not know the tributary slot size of far-end, 496 it should try 1.25G TS mode firstly and the format of 497 Generalized Label is based on new format. 499 When a LSR receives a Generalized Label Request and could not 500 support the requested Signal Type and/or NMC values. It must 501 generate a PathErr including the crankback information with a 502 "Traffic Control Error/Service unsupported" indication. 504 Then the ingress node will attemp to singal again with the 505 same routing. So this node will try 2.5G TS operated mode and 506 the format of Generalized Label is based on RFC4328. 508 2. When a new Path (Resv) message is to be received on a upstream 509 (downstream) TE link, the Generalized Label format is identified 510 by the Signal Type and NMC pair in Traffic Parameters. 512 * When the Signal Type and NMC pair is (ODU1, 2), (ODU2, 8) or 513 (ODU3, 31), the format of Generalized Label should be based on 514 this document, the node must check the interface port mode. 515 If it can not support 1.25G TS mode or the Signal Type and 516 NMC, the Path (Resv) message will be terminated, and a PathErr 517 message including the crankback information with a "Traffic 518 Control Error/Service unsupported" indication must be 519 generated. 521 * When the Signal Type and NMC pair is (ODU1, 1), (ODU1, 0), 522 (ODU2, 4), (ODU2, 0), or (ODU3, 0), the format of Generalized 523 Label should be based on [RFC4328]. In this case the receiver 524 will always support this label format. If it can not support 525 this Signal Type and NMC, the Path (Resv) message will be 526 terminated, and a PathErr message including the crankback 527 information with a "Traffic Control Error/Service unsupported" 528 indication must be generated. 530 * When a downstream (upstream) node receives Path (Resv) message 531 in which Signal Type is ODU0, ODU2e, ODUflex and ODU4, it must 532 identify the Generalized Label format based on this document. 533 If it can not support this Signal Type, the Path (Resv) 534 message will be terminated, and a PathErr message including 535 the crankback information with a "Traffic Control Error/ 536 Service unsupported" indication must be generated. 538 Following figure is a interworking example between G.709(200303) and 539 G.709 Amd 3. 541 4*2.5G TS 32*1.25G TS 80*1.25G TS 16*2.5G TS 8*1.25G TS 542 | | | | | 543 | | | | | 544 \|/ \|/ \|/ \|/ \|/ 545 +----+ OTU2 +----+ OTU3 +----+ OTU4 +----+ OTU3 +----+ OTU2 +----+ 546 -|DXC1|------|DXC2|------|DXC3|------|DXC4|-------|DXC5|-------|DXC6|- 547 +----+ +----+ +----+ +----+ +----+ +----+ 549 Figure 2: Interworking Scenario between G.709(200303) and G.709 Amd3 551 When we need to setup a ODU2 (10G bandwidth) LSP between DXC1 and 552 DXC6, the path computation entiy may computate an DXC1-DXC2-DXC3- 553 DXC4-DXC5-DXC6 route. 555 1. In the case of one end-to-end session, the NMC has to be changed 556 in node where the TE link supporting 1.25G TS and the TE link 557 supporting 2.5G TS are connected (i.e., DXC2, DXC4, and DXC5). 559 +----+ +----+ +----+ +----+ +----+ +----+ 560 -|DXC1|------|DXC2|------|DXC3|------|DXC4|-------|DXC5|-------|DXC6|- 561 +----+ +----+ +----+ +----+ +----+ +----+ 562 Path Path Path Path Path 563 -------> ------> ------> -------> -------> 564 ST=ODU2 ST=ODU2 ST=ODU2 ST=ODU2 ST=ODU2 565 NMC=4 NMC=8 NMC=8 NMC=4 NMC=8 567 Resv Resv Resv Resv Resv 568 <------- <------ <------ <------- <------- 569 ST=ODU2 ST=ODU2 ST=ODU2 ST=ODU2 ST=ODU2 570 NMC=4 NMC=8 NMC=8 NMC=4 NMC=8 572 Figure 3: Contiguous TE LSP 574 2. The end-to-end connection also can be setuped with multiple 575 segment session (i.e., ODU1 LSP1, ODU1 LSP2, ODU1 LSP3, ODU1 576 LSP4). 578 +----+ +----+ +----+ +----+ +----+ +----+ 579 -|DXC1|------|DXC2|------|DXC3|------|DXC4|-------|DXC5|-------|DXC6|- 580 +----+ +----+ +----+ +----+ +----+ +----+ 581 | | | | | 582 |<-ODU1 LSP1->|<-----ODU1 LSP2------>|<-ODU1 LSP3->|<-ODU1 LSP4->| 584 Figure 4: Stitching TE LSP 586 if the segment LSP can be created and prepaired for stitching by 587 signaling, the end-to-end connection is stitched to several 588 segment LSPs (i.e., ODU1 LSP1, ODU1 LSP2, ODU1 LSP3, ODU1 LSP4). 589 The NMC in traffic parameters of this end-to-end session is no 590 meaning. 592 9. Example of Generalized Label 594 The following examples are given in order to illustrate the 595 processing described in this document. 597 1. ODU2e in OTU2e mapping or ODU4 in OTU4 mapping: when one ODU2e 598 (ODU4) signal is directly transported in an OTU2e (OTU4),the 599 upstream node requests results simply in an ODU2e (ODU4) signal 600 request. 602 In such conditions, the downstream node has to return a unique 603 label because the ODU2e (ODU4) is directly mapped into the 604 corresponding OTU2e (OTU4). Because a single ODUk signal is 605 requested, the downstream node has to return a single ODUk 606 label, which can be, for instance, one of the following: 608 - Signal type=ODU4, t4=1, t3=0, t2=0, t1=0; 609 indicates a single ODU4 mapped into an OTU4 611 - Signal type=ODU2e, t4=0, t3=0, t2=31, t1=0; 612 indicates a single ODU2e mapped into an OTU2e 614 2. ODU0 into ODUk multiplexing (k = 1, 2, 3 or 4): when one ODU0 is 615 multiplexed into the payload of a structured ODU1 (ODU2, ODU3 or 616 ODU4), the upstream node requests results simply in an ODU0 617 signal request. 619 In such conditions, the downstream node has to return a unique 620 label because the ODU0 is multiplexed into one ODTUG1 (ODTUG2, 621 ODTUG3 or OTDUG4). The latter is then mapped into the ODU1 622 (ODU2, ODU3 or ODU4) via OPU1 (OPU2, OPU3 or OPU4) and then 623 mapped into the corresponding OTU1 (OTU2, OTU3 or OTU4). 624 Because a single ODU0 multiplexed signal is requested (Signal 625 Type = ODU0 and NMC = 1), the downstream node has to return a 626 single ODU0 label, which can take, for instance, one of the 627 following values: 629 - t4=0, t3=0, t2=0, t1=1; 630 indicates the ODU0 in the 1st TS of the ODTUG1 632 - t4=0, t3=0, t2=4, t1=0; 633 indicates the ODU0 in the 4th TS of the ODTUG2 635 - t4=0, t3=26, t2=0, t1=0; 636 indicates the ODU0 in the 26th TS of the ODTUG3 638 - t4=69, t3=0, t2=0, t1=0; 639 indicates the ODU0 in the 68th TS of the ODTUG4 641 3. ODU1 into 1.25G tributary slots of OPUk (k = 2, 3, 4) 642 multiplexing: when one ODU1 is multiplexed into the payload of a 643 structured ODU2 (ODU3 or ODU4), the upstream node requests 644 results simply in an ODU1 signal request. 646 In such conditions, the downstream node has to return two labels 647 because the ODU1 is multiplexed into one ODTUG2 (ODTUG3 or 648 ODTUG4). The latter is then mapped into the ODU2 (ODU3 or ODU4) 649 via OPU2 (OPU3 or OPU4) and then mapped into the corresponding 650 OTU2 (OTU3 or OTU4). Because a single ODU1 multiplexed signal 651 is requested (Signal Type = ODU1 and NMC = 2), the downstream 652 node has to return two ODU1 labels, which can take, for 653 instance, the following values: 655 - t4=0, t3=0, t2=13, t1=0; 656 indicates the ODU1 in the 5th 1.25G TS of the ODTUG2 658 or 660 - t4=0, t3=58, t2=0, t1=0; 661 indicates the ODU1 in the 26th 1.25G TS of the ODTUG3 663 or 665 - t4=82, t3=0, t2=0, t1=0; 666 indicates the ODU1 in the 1st 1.25G TS of the ODTUG4 668 4. ODU2 into 1.25G tributary slots of OPU3: when one ODU2 is 669 multiplexed into the payload of a structured ODU3, the upstream 670 node requests results simply in an ODU2 signal request. 672 In such conditions, the downstream node has to return eight 673 labels because the ODU2 is multiplexed into one ODTUG3. The 674 latter is then mapped into the ODU3 via OPU3 and then mapped 675 into the corresponding OTU3. Because a single ODU1 multiplexed 676 signal is requested (Signal Type = ODU2 and NMC = 8), the 677 downstream node has to return eight ODU2 labels, which can take, 678 for instance, the following values: 680 - t4=0, t3=67, t2=0, t1=0; 681 indicates the ODU2 in the 3rd 1.25G TS of the ODTUG3 683 - t4=0, t3=73, t2=0, t1=0; 684 indicates the ODU2 in the 9th 1.25G TS of the ODTUG3 686 - t4=0, t3=82, t2=0, t1=0; 687 indicates the ODU2 in the 18th 1.25G TS of the ODTUG3 689 5. ODU2/ODU2e into ODU4 multiplexing: when one ODU2 (or ODU2e) is 690 multiplexed into the payload of a structured ODU4, the upstream 691 node requests results simply in an ODU2 (or ODU2e) signal 692 request. 694 In such conditions, the downstream node has to return eight 695 labels because the ODU2 (ODU2e) is multiplexed into one ODTUG4. 696 The latter is then mapped into the ODU4 via OPU4 and then mapped 697 into the corresponding OTU4. Because a single ODU2 (or ODU2e) 698 multiplexed signal is requested (Signal Type = ODU2 and NMC = 8 699 or Signal Type = ODU2e and NMC = 8), the downstream node has to 700 return eight ODU2 (or ODU2e) labels, one of which can take, for 701 instance, the following values: 703 - Signal type=ODU2, t4=182, t3=0, t2=0, t1=0; 704 indicates the ODU2 in the 21st TS of the ODTUG4 706 - Signal type=ODU2e, t4=320, t3=0, t2=0, t1=0; 707 indicates the ODU2e in the 79th TS of the ODTUG4 709 6. ODU3 into ODU4 multiplexing: when one ODU3 is multiplexed into 710 the payload of a structured ODU4, the upstream node requests 711 results simply in an ODU3 signal request. 713 In such conditions, the downstream node has to return thirty-two 714 labels because the ODU3 is multiplexed into one ODTUG4. The 715 latter is then mapped into the ODU4 via OPU4 and then mapped 716 into the corresponding OTU4. Because a single ODU3 multiplexed 717 signal is requested (Signal Type = ODU3 and NMC = 31), the 718 downstream node has to return thirty-one ODU3 labels, one of 719 which can take, for instance, the following values: 721 - t4=408, t3=0, t2=0, t1=0; 722 indicates the ODU3 in the 7th TS of the ODTUG4 724 - t4=449, t3=0, t2=0, t1=0; 725 indicates the ODU3 in the 48th TS of the ODTUG4 727 - t4=472, t3=0, t2=0, t1=0; 728 indicates the ODU3 in the 71st TS of the ODTUG4 730 7. ODU2e into 1.25G tributary slots of OPU3: when one ODU2e is 731 multiplexed into the payload of a structured ODU3, the upstream 732 node requests results simply in an ODU2e signal request. 734 In such conditions, the downstream node has to return nine 735 labels because the ODU2e is multiplexed into one ODTUG3. The 736 latter is then mapped into the ODU3 via OPU3 and then mapped 737 into the corresponding OTU3. Because a single ODU2e multiplexed 738 signal is requested (Signal Type = ODU2e and NMC = 9), the 739 downstream node has to return nine ODU2e labels, one of which 740 can take, for instance, the following values: 742 - t4=0, t3=100, t2=0, t1=0; 743 indicates the ODU2e in the 4th 1.25G TS of the ODTUG3 745 - t4=0, t3=112, t2=0, t1=0; 746 indicates the ODU2e in the 16th 1.25G TS of the ODTUG3 748 - t4=0, t3=120, t2=0, t1=0; 749 indicates the ODU2e in the 24th 1.25G TS of the ODTUG3 751 8. [NN]-ODU2e into ODU3e1 multiplexing: when one ODU2e is 752 multiplexed into the payload of a structured ODU3e1, the 753 upstream node requests results simply in an ODU2e signal 754 request. 756 In such conditions, the downstream node has to return four 757 labels because the ODU2e is multiplexed into one ODTUG3e1. The 758 latter is then mapped into the ODU3e1 via OPU3e1 and then mapped 759 into the corresponding OTU3e1. Because a single ODU2e 760 multiplexed signal is requested (Signal Type = ODU2e and NMC = 761 4), the downstream node has to return four ODU2e labels, which 762 can take, for instance, the following values: 764 - t4=0, t3=161, t2=0, t1=0; 765 indicates the ODU2e in the 1st TS of the ODTUG3e1 767 - t4=0, t3=166, t2=0, t1=0; 768 indicates the ODU2e in the 6th TS of the ODTUG3e1 770 - t4=0, t3=170, t2=0, t1=0; 771 indicates the ODU2e in the 10th TS of the ODTUG3e1 773 - t4=0, t3=175, t2=0, t1=0; 774 indicates the ODU2e in the 15th TS of the ODTUG3e1 776 9. [NN]-ODU2e into ODU3e2 multiplexing: when one ODU2e is 777 multiplexed into the payload of a structured ODU3e2, the 778 upstream node requests results simply in an ODU2e signal 779 request. 781 In such conditions, the downstream node has to return eight 782 labels because the ODU2e is multiplexed into one ODTUG3e2. The 783 latter is then mapped into the ODU3e2 via OPU3e2 and then mapped 784 into the corresponding OTU3e2. Because a single ODU2e 785 multiplexed signal is requested (Signal Type = ODU2e and NMC = 786 8), the downstream node has to return eight ODU2e labels, one of 787 which can take, for instance, the following values: 789 - t4=0, t3=181, t2=0, t1=0; 790 indicates the ODU2e in the 5th TS of the ODTUG3e2 792 - t4=0, t3=197, t2=0, t1=0; 793 indicates the ODU2e in the 21st TS of the ODTUG3e2 795 - t4=0, t3=207, t2=0, t1=0; 796 indicates the ODU2e in the 31st TS of the ODTUG3e2 798 10. ODUflex is mapped into 1.25G tributary slots of OPU2 (OPU3 or 799 OPU4). when one ODUflex is multiplexed into the payload of a 800 structured ODU2 (ODU3 or ODU4), the upstream node requests 801 results simply in an ODUflex signal request. 803 In such conditions, the downstream node has to return some 804 labels whose number is determined in terms of NMC value. 805 Because the ODUflex is multiplexed into one ODTUG2 (ODTUG3 or 806 ODTUG4). The latter is then mapped into the ODU2 (ODU3 or ODU4) 807 via OPU2 (OPU3 or OPU4) and then mapped into the corresponding 808 OTU2 (OTU3 or OTU4). Because a single ODUflex multiplexed 809 signal is requested (Signal Type = ODUflex), the downstream node 810 has to return some labels (i.e., the number of labels is NMC), 811 which can take, for instance, the following values: 813 - t4=0, t3=0, t2=21, t1=0; 814 indicates the ODUflex in the 5th 1.25G TS of the ODTUG2 816 or 818 - t4=0, t3=150, t2=0, t1=0; 819 indicates the ODUflex in the 22nd 1.25G TS of the ODTUG3 821 or 823 - t4=368, t3=0, t2=0, t1=0; 824 indicates the ODUflex in the 47th 1.25G TS of the ODTUG4 826 10. Security Considerations 828 The procedures described in this document rely completely on RSVP-TE 829 messages and mechanism. The use of H bit set in Admin Status Object 830 basically informs the receiving entity that no operations are to be 831 done over Data Plane as consequence of such special signaling flow. 832 Using specially flagged signaling messages we want to limit the 833 function of setup and tear down messages to Control Plane, making 834 them not effective over related Data Plane resource usage. So, no 835 additional or special issues are arisen by adopting this procedure, 836 that aren't already brought up by the use of the same messages, 837 without H bit setting, for LSP control. For RSVP-TE Security please 838 refer to [RFC3473]. 840 11. IANA Considerations 842 TBD. 844 12. Acknowledgments 846 The RFC text was produced using Marshall Rose's xml2rfc tool. 848 13. Normative References 850 [ITUT-G709] 851 ITU-T, "Interface for the Optical Transport Network 852 (OTN)", G.709 Recommendation (and Amendment 1) , 853 October 2001. 855 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 856 Requirement Levels", BCP 14, RFC 2119, March 1997. 858 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 859 (TE) Extensions to OSPF Version 2", RFC 3630, 860 September 2003. 862 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 863 of Generalized Multi-Protocol Label Switching (GMPLS)", 864 RFC 4203, October 2005. 866 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 867 Hierarchy with Generalized Multi-Protocol Label Switching 868 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 870 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 871 Switching (GMPLS) Signaling Extensions for G.709 Optical 872 Transport Networks Control", RFC 4328, January 2006. 874 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, 875 "Label Switched Path Stitching with Generalized 876 Multiprotocol Label Switching Traffic Engineering (GMPLS 877 TE)", RFC 5150, February 2008. 879 Authors' Addresses 881 Xihua Fu 882 ZTE Corporation 883 West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District 884 Xi An 710065 885 P.R.China 887 Phone: +8613798412242 888 Email: fu.xihua@zte.com.cn 889 URI: http://wwwen.zte.com.cn/ 891 Ming Ke 892 ZTE Corporation 893 3F,R&D Building 3,ZTE Industrial Park,XiLi LiuXian Road 894 Nanshan District,Shenzhen 518055 895 P.R.China 897 Phone: +86 755 26773914 898 Email: ke.ming@zte.com.cn 900 Yuanlin Bao 901 ZTE Corporation 902 5F,R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road 903 Nanshan District,Shenzhen 518055 904 P.R.China 906 Phone: +86 755 26773731 907 Email: bao.yuanlin@zte.com.cn