idnits 2.17.1 draft-ceccarelli-ccamp-gmpls-g709-am3-00.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 (June 27, 2009) is 5417 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: 'ITUT-G709' is mentioned on line 247, but not defined == Missing Reference: 'ITUT-G709-AMD3' is mentioned on line 387, but not defined == Unused Reference: 'RFC3209' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'ITUT-G.709' is defined on line 442, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group D. Ceccarelli 3 Internet-Draft D. Caviglia 4 Intended status: Standards Track F. Fondelli 5 Expires: December 29, 2009 Ericsson 6 M. Corsi 7 Altran 8 June 27, 2009 10 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions 11 for G.709 amendment 3 Optical Transport Networks Control 12 draft-ceccarelli-ccamp-gmpls-g709-am3-00 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 December 29, 2009. 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. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. GMPLS Extensions for G.709 amendment 3 - Overview . . . . . . 5 61 4. Generalized Label Request . . . . . . . . . . . . . . . . . . 6 62 4.1. G.709 Traffic Parameters . . . . . . . . . . . . . . . . . 6 63 4.1.1. Signal Type (ST) . . . . . . . . . . . . . . . . . . . 6 64 4.1.2. Number of Multiplexed Components (NMC) . . . . . . . . 7 65 4.1.3. Number of Virtual Components (NVC) . . . . . . . . . . 8 66 4.1.4. Multiplier (MT) . . . . . . . . . . . . . . . . . . . 8 67 5. Generalized Label . . . . . . . . . . . . . . . . . . . . . . 9 68 5.1. ODUk Label Space . . . . . . . . . . . . . . . . . . . . . 9 69 5.2. Label Distribution Rules . . . . . . . . . . . . . . . . . 11 70 6. RSVP-TE Signaling Protocol Extensions . . . . . . . . . . . . 12 71 7. Acknoledgments . . . . . . . . . . . . . . . . . . . . . . . . 13 72 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 74 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 77 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 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 specified in the ITU-T G.709 93 recommendation [ITUT-G709]. 95 This document extends the concepts presented in [RFC4328] with the 96 technology details introduced in G.709 Optical Transport Networks 97 (OTN) with ITU-T G.709 amendment 3 recommendation. 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 Extensions for G.709 amendment 3 - Overview 107 G.709 amendment 3 introduces new signals type in the two layers 108 constituting the digital transport hierarchy: 110 - Optical Channel Transport Unit (OTUk): 112 . OTU4 114 - Optical Channel Data Unit (ODUk): 116 . ODU0 117 . ODU2e 118 . ODU4 119 . ODUflex 121 It also add a new Tributary Slot (TS) granularity for both the new 122 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, flex) into an ODUk (k > 127 j) signal, in particular: 129 o ODU0 into ODU1 multiplexing 131 o ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS 132 granularity) 134 o ODU0, ODU1, ODUflex and ODU2 into ODU3 multiplexing (with 1.25Gbps 135 TS granularity) 137 o ODU2e into ODU3 multiplexing (with 2.5Gbps TS granularity) 139 o ODU0, ODU1, ODU2, ODU2e, ODUflex into ODU4 multiplexing (with 140 1.25Gbps TS granularity) 142 4. Generalized Label Request 144 The Generalized Label Request as defined in [RFC3471], includes a 145 common part (i.e. used for any switching technology) and a technology 146 dependent part (i.e. the traffic parameters). Both parts have been 147 extended by [RFC4328] in order to accommodate GMPLS signaling to the 148 G.709 transport plane recommendation (see [ITUT-G709]). 150 All these extensions are still valid for G.709 amendment 3 transport 151 plane recommendation and only the technology dependent part is 152 further extended to accommodate GMPLS signaling to the new signals 153 introduced by [ITUT-G709-AMD3]. 155 4.1. G.709 Traffic Parameters 157 The G.709 traffic parameters are defined as follows in [RFC4328] 158 Section 3.2: 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Signal Type | Reserved | NMC | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | NVC | Multiplier (MT) | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Reserved | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 In this frame, NMC stands for Number of Multiplexed Components, NVC 171 for Number of Virtual Components and MT for Multiplier. Each of 172 these fields is tailored to support G.709 LSP requests. The RSVP-TE 173 encoding of the G.709 traffic-parameters is detailed in [RFC4328] 174 Section 6. [ITUT-G709-AMD3] defines new signals and Digital Path 175 layer multiplexing combinations, therefore, the Signal Type and 176 Number of Multiplexed Components fields need to be extended. 178 4.1.1. Signal Type (ST) 180 This field (8 bits) indicates the type of G.709 Elementary Signal 181 that comprises the requested LSP. Since [ITUT-G709-AMD3] defines new 182 signals in both the ODUk layers and the OCh layer, additional Signal 183 Type code-points for G.709 amendment 3 is defined that enlarges the 184 existing ST code-point defined in [RFC4328]. 186 Consequently, the following additional code-points for the Signal 187 Type are defined: 189 Value Type 190 ----- ---- 191 4 ODU4 (i.e., 100 Gbps) 192 9 Och at 100 Gbps 193 10 ODU0 (i.e., 1.25 Gbps) 194 15 ODUflex (i.e., 1.25*ts Gbps) 195 47 ODU2e (i.e, 10,25 Gbps) 197 The same rules defined in [RFC4328] are still valid for the new 198 signals: 200 o if the LSP Encoding Type value is the G.709 Digital Path layer 201 then the valid values are the ODUk signals (k = 0, 1, 2, 2e, 3, 4 202 or flex) 204 o if the LSP Encoding Type value is the G.709 Optical Channel layer 205 then the valid values are the OCh at 2.5, 10, 40 or 100 Gbps 207 4.1.2. Number of Multiplexed Components (NMC) 209 The NMC field (16 bits) indicates the number of ODU tributary slots 210 used by an ODUj when multiplexed into an ODUk (k >= j) for the 211 requested LSP. [ITUT-G709-AMD3] defines new multiplexing cases for 212 ODUk, therefore new ST, NMC combinations needs to be introduced in 213 addition to those defined in [RFC4328] Section 3.2.2: 215 o ODU1 connections multiplexed into one ODU2, ODU3 or ODU4 payload 216 with 1.25Gbps TS granularity, the NMC field MUST be set to 2. 218 o ODU0 connections multiplexed into one ODU1, ODU2, ODU3 or ODU4 219 payload with 1.25Gbps TS granularity, the NMC field MUST be set to 220 1. 222 o ODU2 connections multiplexed into one ODU3 or ODU4 payload with 223 1.25Gbps TS granularity, the NMC field MUST be set to 8. 225 o ODU2e connections multiplexed into one ODU3 payload with 2.5Gbps 226 TS granularity, the NMC field MUST be set to 5. 228 o ODU2e connections multiplexed into one ODU4 payload with 1.25Gbps 229 TS granularity, the NMC field MUST be set to 10. 231 o ODUflex connection multiplexed into one ODUk (k > ts) payload with 232 1.25Gbps TS granularity, the NMC field MUST be set to ts. 234 4.1.3. Number of Virtual Components (NVC) 236 NVC field is the same of that defined in [RFC4328] Section 3.2.3. 238 4.1.4. Multiplier (MT) 240 MT field is the same of that defined in [RFC4328] Section 3.2.4. 242 5. Generalized Label 244 The Generalized Label is defined in [RFC3471]. The format of the 245 corresponding RSVP-TE GENERALIZED_LABEL object is specified in 246 [RFC3473] Section 2.2. The Generalized Label value space for Digital 247 Paths and Optical Channels based on [ITUT-G709] specification is 248 specified in [RFC4328] Section 4.1. This section describes the 249 Generalized Label value space for Digital Paths and Optical Channels 250 for the new signals and Digital Path layer multiplexing combinations 251 introduced in [ITUT-G709-AMD3]. 253 If the ST, NMC combination is one of those defined in Section 4.1.2, 254 then the new Generalized Label format MUST be used, otherwise the 255 [RFC4328] format MUST be used. 257 5.1. ODUk Label Space 259 At the Digital Path layer (i.e. ODUk layers), G.709 and G.709 260 amendment 3 defines seven different client payload bit rates. An 261 Optical Data Unit (ODU) frame has been defined for each of these bit 262 rates. ODUk refers to the frame at bit rate k, where k =0 (for 1.25 263 Gpbs), k = 1 (for 2.5 Gbps), 2 (for 10 Gbps), 2e for (10.25 Gbps), 3 264 (for 40 Gbps), 4 (for 100 Gbps) or flex (for 1.25*ts Gbps). 266 In addition to the support of ODUk mapping into OTUk, the G.709 label 267 space supports the sub-levels of ODUk multiplexing. ODUk 268 multiplexing refers to multiplexing of ODUj (j = 0, 1, 2, 2e, 3, 269 flex) into an ODUk (k > j). 271 More precisely, ODUj into ODUk multiplexing (k > j) is defined when 272 an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an 273 ODTUG constituted by ODU tributary slots) which is mapped into an 274 OPUk. The resulting OPUk is mapped into an ODUk and the ODUk is 275 mapped into an OTUk. Tributary slot granularity may be at 2.5 Gbps 276 or 1.25 Gbps. 278 Therefore, the label space structure is a tree whose root is an OTUk 279 signal and leaves the ODUj signals (k >= j) that can be transported 280 via the tributary slots and switched between these slots. A G.709 281 Digital Path layer label defined in [RFC4328] and a G.709 amd3 282 Digital Path Layer label identifies the exact position of a 283 particular ODUj signal in an ODUk multiplexing structure. 285 The G.709 amd3 Digital Path Layer label or ODUk amd3 label has the 286 following format: 288 0 1 2 3 289 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 290 +---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |t2e| Reserved | t4 | t3 | t2 |t1 | 292 +---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Reserved bits MUST be set to zero when sent and SHOULD be ignored 295 when received. 297 The specification of the fields t1, t2, t3 and t4 self-consistently 298 characterizes the ODUk label space. The value space for the t1, t2, 299 t3 and t4 fields is defined as follows: 301 1. t1 (2-bit): 303 * t1=[1..2] indicates the tributary slot (t1th) used by the ODU0 304 (via ODTU01) in an ODTUG1 mapped into an ODU1 (via OPU1). 306 * t1 is not significant for the other ODUk signal types (i.e., 307 t1 value MUST be set to 0 and ignored). 309 2. t2 (5-bit): 311 * t2=[1..8] indicates the tributary slot (t2th) used by the ODU0 312 (via ODTU02) in an ODTUG2 mapped into an ODU2 (via OPU2). 314 * t2=[9..16] indicates the tributary slot (t2th-8) used by the 315 ODU1 (via ODTU12) in an ODTUG2 mapped into an ODU2 (via OPU2). 317 * t2=[17..24] indicates the tributary slot (t2th-16) used by the 318 ODUflex (via ODTU2.ts) in an ODTUG2 mapped into an ODU2 (via 319 OPU2). 321 * t2 is not significant for the other ODUk signal types (i.e., 322 t2 value MUST be set to 0 and ignored). 324 3. t3 (8-bit): 326 * t3=[1..32] indicates the tributary slot (t3th) used by the 327 ODU0 (via ODTU03) in an ODTUG3 mapped into an ODU3 (via OPU3). 329 * t3=[33..64] indicates the tributary slot (t3th-32) used by the 330 ODU1 (via ODTU13) in an ODTUG3 mapped into an ODU3 (via OPU3). 332 * t3=[65..96] indicates the tributary slot (t3th-64) used by the 333 ODU2 (via ODTU23) in an ODTUG3 mapped into an ODU3 (via OPU3). 335 * t3=[97..128] indicates the tributary slot (t3th-96) used by 336 the ODUflex (via ODTU3.ts) in an ODTUG3 mapped into an ODU3 337 (via OPU3). 339 * t3=[129..144] indicates the tributary slot (t3th-128) used by 340 the ODU2e (via ODTU2e3) in an ODTUG3 mapped into an ODU3 (via 341 OPU3). 343 * t3 is not significant for the ODU4 signal type (i.e., t3 value 344 MUST be set to 0 and ignored). 346 4. t4 (9-bit): 348 * t4=1 indicates an ODU4 signal 350 * t4=[2..81] indicates the tributary slot (t4th-1) used by the 351 ODU0 (via ODTU4.1) in an ODTUG4 mapped into an ODU4 (via 352 OPU4). 354 * t4=[82..161] indicates the tributary slot (t4th-81) used by 355 the ODU1 (via ODTU4.2) in an ODTUG4 mapped into an ODU4 (via 356 OPU4). 358 * t4=[162..241] indicates the tributary slot (t4th-161) used by 359 the ODU2 (via ODTU4.8) in an ODTUG4 mapped into an ODU4 (via 360 OPU4). 362 * t4=[242..321] indicates the tributary slot (t4th-241) used by 363 the ODU3 via ODTU4.32) in an ODTUG4 mapped into an ODU4 (via 364 OPU4). 366 * t4=[322..401] indicates the tributary slot (t4th-321) used by 367 the ODUflex (via ODTU4.ts) in an ODTUG4 mapped into an ODU4 368 (via OPU4). 370 * t4=[402..481] indicates the tributary slot (t4th-401) used by 371 the ODU2e (via ODTU4.8) in an ODTUG4 mapped into an ODU4 (via 372 OPU4). 374 5.2. Label Distribution Rules 376 Label distribution rules are the same of those defined in [RFC4328] 377 Section 4.2. 379 6. RSVP-TE Signaling Protocol Extensions 381 RSVP-TE will reuse the protocol extensions defined in [RFC4328] 382 Section 6. and does not need to be further extended. 384 When a amendment 3 aware node receives a Generalized Label Request it 385 can infer the label format from the ST, NMC pair. Instead when a non 386 amendment 3 aware node receives a Generalized Label Request for a 387 signals introduced in [ITUT-G709-AMD3], it will not support the 388 requested Signal Type, NMC values. Then the receiver node MUST 389 generate a PathErr message with a "Traffic Control Error/Service 390 unsupported" indication (see [RFC2205]) as specified in [RFC4328]. 392 7. Acknoledgments 394 We wish to thank Attila Takacs and Andras Kern for their assistance 395 and precious advices to prepare this draft for publication. 397 8. Contributors 398 9. Security Considerations 400 The procedures described in this document rely completely on RSVP-TE 401 messages and mechanism. The use of H bit set in Admin Status Object 402 basically informs the receiving entity that no operations are to be 403 done over Data Plane as consequence of such special signaling flow. 404 Using specially flagged signaling messages we want to limit the 405 function of setup and tear down messages to Control Plane, making 406 them not effective over related Data Plane resource usage. So, no 407 additional or special issues are arisen by adopting this procedure, 408 that aren't already brought up by the use of the same messages, 409 without H bit setting, for LSP control. For RSVP-TE Security please 410 refer to [RFC3473]. 412 10. IANA Considerations 413 11. References 415 11.1. Normative References 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 421 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 422 Functional Specification", RFC 2205, September 1997. 424 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 425 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 426 Tunnels", RFC 3209, December 2001. 428 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 429 (GMPLS) Signaling Functional Description", RFC 3471, 430 January 2003. 432 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 433 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 434 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 436 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 437 Switching (GMPLS) Signaling Extensions for G.709 Optical 438 Transport Networks Control", RFC 4328, January 2006. 440 11.2. Informative References 442 [ITUT-G.709] 443 ITU-T, "Interface for the Optical Transport Network 444 (OTN)", G.709 Recommendation (and Amendment 1), 445 February 2001. 447 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 448 (GMPLS) Architecture", RFC 3945, October 2004. 450 Authors' Addresses 452 Daniele Ceccarelli 453 Ericsson 454 Via A. Negrone 1/A 455 Genova - Sestri Ponente 456 Italy 458 Email: daniele.ceccarelli@ericsson.com 460 Diego Caviglia 461 Ericsson 462 Via A. Negrone 1/A 463 Genova - Sestri Ponente 464 Italy 466 Email: diego.caviglia@ericsson.com 468 Francesco Fondelli 469 Ericsson 470 Via A. Negrone 1/A 471 Genova - Sestri Ponente 472 Italy 474 Email: francesco.fondelli@ericsson.com 476 Marco Corsi 477 Altran 478 Via A. Negrone 1/A 479 Genova - Sestri Ponente 480 Italy 482 Email: marco.corsi@altran.it