idnits 2.17.1 draft-ietf-ccamp-gmpls-signaling-g709v3-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 4 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([G709-2012]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC4328, but the abstract doesn't seem to directly say this. It does mention RFC4328 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4328, updated by this document, for RFC5378 checks: 2002-04-08) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 13, 2013) is 3870 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'G709-2012' -- Possible downref: Non-RFC (?) normative reference: ref. 'G7044' -- Possible downref: Non-RFC (?) normative reference: ref. 'G7041' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Fatai Zhang, Ed. 2 Internet Draft Huawei 3 Updates: 4328 Guoying Zhang 4 Category: Standards Track CATR 5 Sergio Belotti 6 Alcatel-Lucent 7 D. Ceccarelli 8 Ericsson 9 Khuzema Pithewan 10 Infinera 11 Expires: March 13, 2014 September 13, 2013 13 Generalized Multi-Protocol Label Switching (GMPLS) Signaling 14 Extensions for the evolving G.709 Optical Transport Networks Control 16 draft-ietf-ccamp-gmpls-signaling-g709v3-12.txt 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with 21 the provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on March 13, 2014. 41 Abstract 43 ITU-T Recommendation G.709 [G709-2012] has introduced new Optical 44 channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e and ODUflex) 45 and enhanced Optical Transport Networking (OTN) flexibility. 47 This document updates the ODU-related portions of RFC4328 to provide 48 the extensions to the Generalized Multi-Protocol Label Switching 49 (GMPLS) signaling to control the full set of OTN features including 50 ODU0, ODU4, ODU2e and ODUflex. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC2119]. 58 Table of Contents 60 1. Introduction ................................................. 3 61 2. Terminology .................................................. 3 62 3. GMPLS Extensions for the Evolving G.709 - Overview ........... 3 63 4. Generalized Label Request .................................... 4 64 5. Extensions for Traffic Parameters for the Evolving G.709 ..... 6 65 5.1. Usage of ODUflex(CBR) Traffic Parameters ................ 8 66 5.2. Usage of ODUflex(GFP) Traffic Parameters ................ 10 67 5.3. Notification on Errors of OTN-TDM Traffic Parameters .... 10 68 6. Generalized Label ............................................ 11 69 6.1. OTN-TDM Switching Type Generalized Label ................ 11 70 6.2. Procedures .............................................. 14 71 6.2.1. Notification on Label Error ........................ 15 72 6.3. Supporting Virtual Concatenation and Multiplication ..... 16 73 6.4. Examples ................................................ 17 74 7. Supporting Hitless Adjustment of ODUflex (GFP) ............... 18 75 8. Operations, Administration and Maintenance (OAM) Considerations19 76 9. Control Plane Backward Compatibility Considerations........... 20 77 10. Security Considerations .................................... 20 78 11. IANA Considerations.......................................... 20 79 12. References .................................................. 22 80 12.1. Normative References ................................... 22 81 12.2. Informative References ................. ............... 23 82 13. Contributors ................................................ 24 83 14. Authors' Addresses .......................................... 26 84 15. Acknowledgment .............................................. 27 86 1. Introduction 88 With the evolution and deployment of Optical Transport Network (OTN) 89 technology, it is necessary that appropriate enhanced control 90 technology support be provided for [G709-2012]. 92 [OTN-FWK] provides a framework to allow the development of protocol 93 extensions to support GMPLS and Path Computation Element (PCE) 94 control of OTN as specified in [G709-2012]. Based on this framework, 95 [OTN-INFO] evaluates the information needed by the routing and 96 signaling process in OTNs to support GMPLS control of OTN. 98 [RFC4328] describes the control technology details that are specific 99 to the 2001 revision of the G.709 specification. This document 100 updates the ODU-related portions of [RFC4328] to provide Resource 101 ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions to 102 support of control for [G709-2012]. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. GMPLS Extensions for the Evolving G.709 - Overview 112 New features for the evolving OTN, for example, new ODU0, ODU2e, ODU4 113 and ODUflex containers are specified in [G709-2012]. The 114 corresponding new Signal Types are summarized below: 116 - Optical Channel Transport Unit (OTUk): 117 . OTU4 119 - Optical Channel Data Unit (ODUk): 120 . ODU0 121 . ODU2e 122 . ODU4 123 . ODUflex 125 A new Tributary Slot granularity (i.e., 1.25Gbps) is also described 126 in [G709-2012]. Thus, there are now two Tributary Slot (TS) 127 granularities for the foundation OTN ODU1, ODU2 and ODU3 containers. 128 The TS granularity at 2.5Gbps is used on the legacy interfaces while 129 the new 1.25Gbps is used on the new interfaces. 131 In addition to the support of ODUk mapping into OTUk (k = 1, 2, 3, 132 4), [G709-2012] encompasses the multiplexing of ODUj (j = 0, 1, 2, 133 2e, 3, flex) into an ODUk (k > j), as described in Section 3.1.2 of 134 [OTN-FWK]. 136 Virtual Concatenation (VCAT) of Optical channel Payload Unit-k (OPUk) 137 (OPUk-Xv, k = 1/2/3, X = 1...256) is also supported by [G709-2012]. 138 Note that VCAT of OPU0 / OPU2e / OPU4 / OPUflex is not supported per 139 [G709-2012]. 141 [RFC4328] describes GMPLS signaling extensions to support the control 142 for the 2001 revision of the G.709 specification. However, [RFC4328] 143 does not provide the means to signal all the new Signal Types and 144 related mapping and multiplexing functionalities. Moreover, it 145 supports only the deprecated auto- Multiframe Structure Identifier 146 (MSI) mode which assumes that the Tributary Port Number (TPN) is 147 automatically assigned in the transmit direction and not checked in 148 the receive direction. 150 This document extends the G.709 Traffic Parameters described in 151 [RFC4328] and presents a new flexible and scalable OTN-TDM 152 Generalized Label format. Additionally, procedures about Tributary 153 Port Number assignment through control plane are also provided in 154 this document. 156 4. Generalized Label Request 158 The GENERALIZED_LABEL_REQUEST object, as described in [RFC3471], 159 carries the Label Switched Path (LSP) Encoding Type, the Switching 160 Type and the Generalized Protocol Identifier (G-PID). 162 [RFC4328] extends the GENERALIZED_LABEL_REQUEST object, introducing 163 two new code-points for the LSP Encoding Type (i.e., G.709 ODUk 164 (Digital Path) and G.709 Optical Channel) and adding a list of G-PID 165 values in order to accommodate the 2001 revision of the G.709 166 specification. 168 This document follows these extensions and a new Switching Type is 169 introduced to indicate the ODUk switching capability [G709-2012] in 170 order to support backward compatibility with [RFC4328], as described 171 in [OTN-FWK]. The new Switching Type (OTN-TDM Switching Type) is 172 defined in [OTN-OSPF]. 174 This document also updates the G-PID values defined in [RFC4328]: 176 Value G-PID Type 177 ----- ---------- 178 47 Type field updated from "G.709 ODUj" to "ODU-2.5G" to 179 indicate transport of Digital Paths (e.g., at 2.5, 10 and 180 40Gbps) via 2.5Gbps TS granularity. 182 56 Type field updated from "ESCON" to "SBCON/ESCON" to align 183 with [G709-2012] payload type 0x1A. 185 Note: Value 47 includes mapping of Synchronous Digital Hierarchy 186 (SDH). 188 In the case of ODU multiplexing, the Lower Order ODU (LO ODU) (i.e., 189 the client signal) may be multiplexed into Higher Order ODU (HO ODU) 190 via 1.25G TS granularity, 2.5G TS granularity or ODU-any defined 191 below. Since the G-PID type "ODUk" defined in [RFC4328] is only used 192 for 2.5Gbps TS granularity, two new G-PID types are defined as 193 follows: 195 - ODU-1.25G: Transport of Digital Paths at 1.25, 2.5, 10, 40 and 100 196 Gbps via 1.25Gbps TS granularity. 198 - ODU-any: Transport of Digital Paths at 1.25, 2.5, 10, 40 and 100 199 Gbps via 1.25 or 2.5Gbps TS granularity (i.e., the 200 fallback procedure is enabled and the default value of 201 1.25Gbps TS granularity can be fallen back to 2.5Gbps 202 if needed). 204 The full list of payload types defined in [G709-2012] and their 205 mapping to existing and new G-PID types are as follows: 207 G.709 208 Payload 209 Type G-PID Type/Comment LSP Encoding 210 ==== ===== ===================== =================== 211 0x01 No standard value 212 0x02 49 CBRa G.709 ODUk 213 0x03 50 CBRb G.709 ODUk 214 0x04 32 ATM G.709 ODUk 215 0x05 59(TBA) Framed GFP G.709 ODUk 216 54 Ethernet MAC (framed GFP) G.709 ODUk 217 70(TBA) 64B/66B GFP-F Ethernet G.709 ODUk (k=2) 218 0x06 Not signaled 219 0x07 55 Ethernet PHY G.709 ODUk (k=0,3,4) 220 (transparent GFP) 221 0x08 58 Fiber Channel G.709 ODUk (k=2e) 222 0x09 59(TBA) Framed GFP G.709 ODUk (k=2) 223 70(TBA) 64B/66B GFP-F Ethernet G.709 ODUk (k=2) 224 0x0A 60(TBA) STM-1 G.709 ODUk (k=0) 225 0x0B 61(TBA) STM-4 G.709 ODUk (k=0) 226 0x0C 58 Fiber Channel G.709 ODUk (k=0) 227 0x0D 58 Fiber Channel G.709 ODUk (k=1) 228 0x0E 58 Fiber Channel G.709 ODUflex 229 0x0F 58 Fiber Channel G.709 ODUflex 230 0x10 51 BSOT G.709 ODUk 231 0x11 52 BSNT G.709 ODUk 232 0x12 62(TBA) InfiniBand G.709 ODUflex 233 0x13 62(TBA) InfiniBand G.709 ODUflex 234 0x14 62(TBA) InfiniBand G.709 ODUflex 235 0x15 63(TBA) Serial Digital Interface G.709 ODUk (k=0) 236 0x16 64(TBA) Serial Digital G.709 ODUk (k=1) 237 Interface/1.001 238 0x17 63(TBA) Serial Digital Interface G.709 ODUk (k=1) 239 0x18 64(TBA) Serial Digital G.709 ODUflex 240 Interface/1.001 241 0x19 63(TBA) Serial Digital Interface G.709 ODUflex 242 0x1A 56 SBCON/ESCON G.709 ODUk (k=0) 243 (IANA to update Type field) 244 0x1B 65(TBA) DVB_ASI G.709 ODUk (k=0) 245 0x1C 58 Fiber Channel G.709 ODUk 246 0x20 47 G.709 ODU-2.5G G.709 ODUk (k=2,3) 247 (IANA to update Type field) 248 66(TBA) G.709 ODU-1.25G G.709 ODUk (k=1) 249 0x21 66(TBA) G.709 ODU-1.25G G.709 ODUk (k=2,3,4) 250 67(TBA) G.709 ODU-Any G.709 ODUk (k=2,3) 251 0x55 No standard value 252 0x66 No standard value 253 0x80-0x8F No standard value 254 0xFD 68(TBA) Null Test G.709 ODUk 255 0xFE 69(TBA) Random Test G.709 ODUk 256 0xFF No standard value 258 Note: Values 59 and 70 include mapping of SDH. 260 Note that the mapping types for ODUj into OPUk are unambiguously per 261 Table 7-10 of [G709-2012], so it does not need to carry mapping type 262 information in the signaling. 264 Note also that additional information on G.709 client mapping can be 265 found in [G7041]. 267 5. Extensions for Traffic Parameters for the Evolving G.709 269 The Traffic Parameters for OTN-TDM capable Switching Type are carried 270 in the OTN-TDM SENDER_TSPEC object in the Path message and the OTN- 271 TDM FLOWSPEC object in the Resv message. The objects have the 272 following class and type: 274 - OTN-TDM SENDER_TSPEC object: Class = 12, C-Type = 7 (TBA) 275 - OTN-TDM FLOWSPEC object: Class = 9, C-Type = 7 (TBA) 277 The format of Traffic Parameters in these two objects is defined as 278 follows: 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Signal Type | Reserved | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | NVC | Multiplier (MT) | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Bit_Rate | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Signal Type: 8 bits 292 As defined in [RFC4328] Section 3.2.1, with the following 293 additional values: 295 Value Type 296 ----- ---- 297 4 ODU4 (i.e., 100Gbps) 298 9 OCh at 100Gbps 299 10 ODU0 (i.e., 1.25Gbps) 300 11 ODU2e (i.e., 10Gbps for FC1200 and GE LAN) 301 12~19 Reserved (for future use) 302 20 ODUflex(CBR) (i.e., 1.25*N Gbps) 303 21 ODUflex(Generic Framing Procedure-Framed (GFP-F)), 304 resizable (i.e., 1.25*N Gbps) 305 22 ODUflex(GFP-F), non resizable (i.e., 1.25*N Gbps) 306 23~255 Reserved (for future use) 308 NVC (Number of Virtual Components): 16 bits 310 As defined in [RFC4328] Section 3.2.3. This field MUST be set to 311 0 for ODUflex Signal Types. 313 Multiplier (MT): 16 bits 315 As defined in [RFC4328] Section 3.2.4. This field MUST be set to 316 1 for ODUflex Signal Types. 318 Bit_Rate: 32 bits 320 In case of ODUflex including ODUflex(CBR) and ODUflex(GFP) Signal 321 Types, this field indicates the nominal bit rate of ODUflex 322 expressed in bytes per second, encoded as a 32-bit IEEE single- 323 precision floating-point number (referring to [RFC4506] and 324 [IEEE]). For other Signal Types, this field MUST be set to zero 325 on transmission and MUST be ignored on receipt and SHOULD be 326 passed unmodified by transit nodes. 328 5.1. Usage of ODUflex(CBR) Traffic Parameters 330 In case of ODUflex(CBR), the information of Bit_Rate carried in the 331 ODUflex Traffic Parameters MUST be used to determine the actual 332 bandwidth of ODUflex(CBR) (i.e., Bit_Rate * (1 +/- Tolerance)). 333 Therefore the total number of tributary slots N in the HO ODUk link 334 can be reserved correctly. Where: 336 N = Ceiling of 338 ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance) 339 --------------------------------------------------------------------- 340 ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) 342 In this formula, the ODUflex(CBR) nominal bit rate is the bit rate of 343 the ODUflex(CBR) on the line side, i.e., the client signal bit rate 344 after applying the 239/238 factor (according to Clause 7.3, Table 7-2 345 of [G709-2012]) and the transcoding factor T (if needed) on the CBR 346 client. According to clauses 17.7.3, 17.7.4 and 17.7.5 of [G709- 347 2012]: 349 ODUflex(CBR) nominal bit rate = CBR client bit rate * (239/238) / T 351 The ODTUk.ts (Optical channel Data Tributary Unit k with ts tributary 352 slots) nominal bit rate is the nominal bit rate of the tributary slot 353 of ODUk, as shown in Table 1 (referring to Table 7-7 of [G709-2012]). 355 Table 1 - Actual TS bit rate of ODUk (in Kbps) 357 ODUk.ts Minimum Nominal Maximum 358 ----------------------------------------------------------- 359 ODU2.ts 1,249,384.632 1,249,409.620 1,249,434.608 360 ODU3.ts 1,254,678.635 1,254,703.729 1,254,728.823 361 ODU4.ts 1,301,683.217 1,301,709.251 1,301,735.285 363 Note that: 365 Minimum bit rate of ODUTk.ts = 366 ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) 368 Maximum bit rate of ODTUk.ts = 369 ODTUk.ts nominal bit rate * (1 + HO OPUk bit rate tolerance) 371 Where: HO OPUk bit rate tolerance = 20ppm (parts per million) 373 Note that the bit rate tolerance is implicit in Signal Type and the 374 ODUflex(CBR) bit rate tolerance is fixed and it is equal to 100ppm as 375 described in Table 7-2 of [G709-2012]. 377 Therefore, a node receiving a Path message containing ODUflex(CBR) 378 nominal bit rate can allocate precise number of tributary slots and 379 set up the cross-connection for the ODUflex service. 381 Note that for different ODUk, the bit rates of the tributary slots 382 are different, and so the total number of tributary slots to be 383 reserved for the ODUflex(CBR) may not be the same on different HO 384 ODUk links. 386 An example is given below to illustrate the usage of ODUflex(CBR) 387 Traffic Parameters. 389 +-----+ +---------+ +-----+ 390 | +-------------+ +-----+ +-------------+ | 391 | +=============+\| ODU |/+=============+ | 392 | +=============+/| flex+-+=============+ | 393 | +-------------+ | |\+=============+ | 394 | +-------------+ +-----+ +-------------+ | 395 | | | | | | 396 | | ....... | | ....... | | 397 | A +-------------+ B +-------------+ C | 398 +-----+ HO ODU4 +---------+ HO ODU2 +-----+ 400 =========: TSs occupied by ODUflex 401 ---------: available TSs 403 Figure 1 - Example of ODUflex(CBR) Traffic Parameters 405 As shown in Figure 1, assume there is an ODUflex(CBR) service 406 requesting a bandwidth of 2.5Gbps from node A to node C. 408 In other words, the ODUflex Traffic Parameters indicate that Signal 409 Type is 20 (ODUflex(CBR)), Bit_Rate is 2.5Gbps (Note that the 410 tolerance is not signaled as explained above). 412 - On the HO ODU4 link between node A and B: 414 The maximum bit rate of the ODUflex(CBR) equals 2.5Gbps * (1 + 415 100ppm), and the minimum bit rate of the tributary slot of ODU4 416 equals 1,301,683.217 Kbps, so the total number of tributary slots 417 N1 to be reserved on this link is: 419 N1 = ceiling (2.5Gbps * (1 + 100ppm) / 1,301,683.217 Kbps) = 2 421 - On the HO ODU2 link between node B and C: 423 The maximum bit rate of the ODUflex equals 2.5Gbps * (1 + 424 100ppm), and the minimum bit rate of the tributary slot of ODU2 425 equals 1,249,384.632 Kbps, so the total number of tributary slots 426 N2 to be reserved on this link is: 428 N2 = ceiling (2.5Gbps * (1 + 100ppm) / 1,249,384.632 Kbps) = 3 430 5.2. Usage of ODUflex(GFP) Traffic Parameters 432 [G709-2012] recommends that the ODUflex(GFP) will fill an integral 433 number of tributary slots of the smallest HO ODUk path over which the 434 ODUflex(GFP) may be carried, as shown in Table 2. 436 Table 2 - Recommended ODUflex(GFP) bit rates and tolerance 438 ODU type | Nominal bit-rate | Tolerance 439 ---------------------------------+------------------+----------- 440 ODUflex(GFP) of n TSs, 1<=n<=8 | n * ODU2.ts | +/-100 ppm 441 ODUflex(GFP) of n TSs, 9<=n<=32 | n * ODU3.ts | +/-100 ppm 442 ODUflex(GFP) of n TSs, 33<=n<=80 | n * ODU4.ts | +/-100 ppm 444 According to this table, the Bit_Rate field for ODUflex(GFP) MUST be 445 equal to one of the 80 values listed below: 447 1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts; 448 9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts; 449 33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts. 451 In this way, the number of required tributary slots for the 452 ODUflex(GFP) (i.e., the value of "n" in Table 2) can be deduced from 453 the Bit_Rate field. 455 5.3. Notification on Errors of OTN-TDM Traffic Parameters 457 There is no Adspec associated with the OTN-TDM SENDER_TSPEC object. 458 Either the Adspec is omitted or an Int-serv Adspec with the Default 459 General Characterization Parameters and Guaranteed Service fragment 460 is used, see [RFC2210]. 462 For a particular sender in a session, the contents of the OTN-TDM 463 FLOWSPEC object received in a Resv message SHOULD be identical to the 464 contents of the OTN-TDM SENDER_TSPEC object received in the 465 corresponding Path message. If the objects do not match, a ResvErr 466 message with a "Traffic Control Error/Bad Flowspec value" error MUST 467 be generated. 469 Intermediate and egress nodes MUST verify that the node itself, and 470 the interfaces on which the LSP will be established, can support the 471 requested Signal Type, NVC and Bit_Rate values. If the requested 472 value(s) cannot be supported, the receiver node MUST generate a 473 PathErr message with a "Traffic Control Error/Service unsupported" 474 indication (see [RFC2205]). 476 In addition, if the MT field is received with a zero value, the node 477 MUST generate a PathErr message with a "Traffic Control Error/Bad 478 Tspec value" indication (see [RFC2205]). 480 Further, if the Signal Type is not ODU1, ODU2 or ODU3, and the NVC 481 field is not 0, the node MUST generate a PathErr message with a 482 "Traffic Control Error/Bad Tspec value" indication (see [RFC2205]). 484 6. Generalized Label 486 This section defines the format of the OTN-TDM Generalized Label. 488 6.1. OTN-TDM Switching Type Generalized Label 490 The following is the GENERALIZED_LABEL object format for that MUST be 491 used with the OTN-TDM Switching Type: 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | TPN | Reserved | Length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 ~ Bit Map ...... ~ 499 ~ ...... | Padding Bits ~ 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 The OTN-TDM GENERALIZED_LABEL object is used to indicate how the LO 503 ODUj signal is multiplexed into the HO ODUk link. Note that the LO 504 OUDj signal type is indicated by Traffic Parameters, while the type 505 of HO ODUk link is identified by the selected interface carried in 506 the IF_ID RSVP_HOP object. 508 TPN (12 bits): indicates the TPN for the assigned Tributary Slot(s). 510 - In case of LO ODUj multiplexed into HO ODU1/ODU2/ODU3, only the 511 lower 6 bits of TPN field are significant and the other bits of 512 TPN MUST be set to 0. 514 - In case of LO ODUj multiplexed into HO ODU4, only the lower 7 515 bits of TPN field are significant and the other bits of TPN 516 MUST be set to 0. 518 - In case of ODUj mapped into OTUk (j=k), the TPN is not needed 519 and this field MUST be set to 0. 521 Per [G709-2012], The TPN is used to allow for correct demultiplexing 522 in the data plane. When an LO ODUj is multiplexed into HO ODUk 523 occupying one or more TSs, a new TPN value is configured at the two 524 ends of the HO ODUk link and is put into the related MSI byte(s) in 525 the OPUk overhead at the (traffic) ingress end of the link, so that 526 the other end of the link can learn which TS(s) is/are used by the LO 527 ODUj in the data plane. 529 According to [G709-2012], the TPN field MUST be set as according to 530 the following tables: 532 Table 3 - TPN Assignment Rules (2.5Gbps TS granularity) 533 +-------+-------+----+----------------------------------------------+ 534 |HO ODUk|LO ODUj|TPN | TPN Assignment Rules | 535 +-------+-------+----+----------------------------------------------+ 536 | ODU2 | ODU1 |1~4 |Fixed, = TS# occupied by ODU1 | 537 +-------+-------+----+----------------------------------------------+ 538 | | ODU1 |1~16|Fixed, = TS# occupied by ODU1 | 539 | ODU3 +-------+----+----------------------------------------------+ 540 | | ODU2 |1~4 |Flexible, != other existing LO ODU2s' TPNs | 541 +-------+-------+----+----------------------------------------------+ 542 Table 4 - TPN Assignment Rules (1.25Gbps TS granularity) 543 +-------+-------+----+----------------------------------------------+ 544 |HO ODUk|LO ODUj|TPN | TPN Assignment Rules | 545 +-------+-------+----+----------------------------------------------+ 546 | ODU1 | ODU0 |1~2 |Fixed, = TS# occupied by ODU0 | 547 +-------+-------+----+----------------------------------------------+ 548 | | ODU1 |1~4 |Flexible, != other existing LO ODU1s' TPNs | 549 | ODU2 +-------+----+----------------------------------------------+ 550 | |ODU0 & |1~8 |Flexible, != other existing LO ODU0s and | 551 | |ODUflex| |ODUflexes' TPNs | 552 +-------+-------+----+----------------------------------------------+ 553 | | ODU1 |1~16|Flexible, != other existing LO ODU1s' TPNs | 554 | +-------+----+----------------------------------------------+ 555 | | ODU2 |1~4 |Flexible, != other existing LO ODU2s' TPNs | 556 | ODU3 +-------+----+----------------------------------------------+ 557 | |ODU0 & | |Flexible, != other existing LO ODU0s and | 558 | |ODU2e &|1~32|ODU2es and ODUflexes' TPNs | 559 | |ODUflex| | | 560 +-------+-------+----+----------------------------------------------+ 561 | ODU4 |Any ODU|1~80|Flexible, != ANY other existing LO ODUs' TPNs | 562 +-------+-------+----+----------------------------------------------+ 564 Note that in the case of "Flexible", the value of TPN MAY not be 565 corresponding to the TS number as per [G709-2012]. 567 Length (12 bits): indicates the number of bits of the Bit Map field, 568 i.e., the total number of TS in the HO ODUk link. The TS granularity, 569 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's 570 rate by the value of the Length field. In the context of [G709-2012], 571 the values of 4 and 16 indicate a TS granularity of 2.5Gbps, and the 572 values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gbps. 574 In case of an ODUk mapped into OTUk, there is no need to indicate 575 which tributary slots will be used, so the length field MUST be set 576 to 0. 578 Bit Map (variable): indicates which tributary slots in HO ODUk that 579 the LO ODUj will be multiplexed into. The sequence of the Bit Map is 580 consistent with the sequence of the tributary slots in HO ODUk. Each 581 bit in the bit map represents the corresponding tributary slot in HO 582 ODUk with a value of 1 or 0 indicating whether the tributary slot 583 will be used by LO ODUj or not. 585 Padding bits are added after the Bit Map to make the whole label a 586 multiple of four bytes if necessary. Padding bits MUST be set to 0 587 and MUST be ignored on receipt. 589 6.2. Procedures 591 The ingress node MUST generate a Path message and specify the OTN-TDM 592 Switching Type and corresponding G-PID in the 593 GENERALIZED_LABEL_REQUEST object, which MUST be processed as defined 594 in [RFC3473]. 596 The ingress node of an LSP MAY include Label ERO (Explicit Route 597 Object) subobject to indicate the label in each hops along the path. 598 Note that the TPN in the Label ERO subobject need not be assigned by 599 the ingress node. When the TPN is assigned by a node, the node MUST 600 assign a valid TPN value and then put this value into TPN field of 601 the GENERALIZED_LABEL object when receiving a Path message. 603 In order to create bidirectional LSP, the ingress node and upstream 604 node MUST generate an UPSTREAM_LABEL Object on the outgoing interface 605 to indicate the reserved TSs of ODUk and the assigned TPN value in 606 the upstream direction. This UPSTREAM_LABEL object is sent to the 607 downstream node via Path massage for upstream resource reservation. 609 The ingress node or upstream node MAY generate LABEL_SET object to 610 indicate which labels on the outgoing interface in the downstream 611 direction are acceptable. The downstream node will restrict its 612 choice of labels, i.e., TS resource and TPN value, to one which is in 613 the LABEL_SET object. 615 The ingress node or upstream node MAY also generate SUGGESTED_LABEL 616 object to indicate the preference of TS resource and TPN value on the 617 outgoing interface in the downstream direction. The downstream node 618 is not required to use the suggested labels and may use another label 619 based on local decision and send it to the upstream node, as 620 described in [RFC3473]. 622 When an upstream node receives a Resv message containing a 623 GENERALIZED_LABEL object with an OTN-TDM label, it MUST firstly 624 identify which ODU Signal Type is multiplexed or mapped into which 625 ODU Signal Type according to the Traffic Parameters and the IF_ID 626 RSVP_HOP object in the received message. 628 - In case of ODUj to ODUk multiplexing, the node MUST retrieve the 629 reserved tributary slots in the ODUk by its downstream neighbor 630 node according to the position of the bits that are set to 1 in 631 the Bit Map field. The node determines the TS granularity 632 (according to the total TS number of the ODUk, or pre-configured 633 TS granularity), so that the node can multiplex the ODUj into the 634 ODUk based on the TS granularity. The node MUST also retrieve the 635 TPN value assigned by its downstream neighbor node from the label, 636 and fill the TPN into the related MSI byte(s) in the OPUk overhead 637 in the data plane, so that the downstream neighbor node can check 638 whether the TPN received from the data plane is consistent with 639 the ExMSI and determine whether there is any mismatch defect. 641 - In case of ODUk to OTUk mapping, the size of Bit Map field MUST be 642 0 and no additional procedure is needed. 644 When a downstream node or egress node receives a Path message 645 containing GENERALIZED_LABEL_REQUEST object for setting up an ODUj 646 LSP from its upstream neighbor node, the node MUST generate an OTN- 647 TDM label according to the Signal Type of the requested LSP and the 648 available resources (i.e., available tributary slots of ODUk) that 649 will be reserved for the LSP, and send the label to its upstream 650 neighbor node. 652 - In case of ODUj to ODUk multiplexing, the node MUST firstly 653 determine the size of the Bit Map field according to the Signal 654 Type and the tributary slot type of ODUk, and then set the bits to 655 1 in the Bit Map field corresponding to the reserved tributary 656 slots. The node MUST also assign a valid TPN, which MUST NOT 657 collide with other TPN value used by existing LO ODU connections 658 in the selected HO ODU link, and configure the Expected MSI 659 (ExMSI) using this TPN. Then, the assigned TPN MUST be filled into 660 the label. 662 - In case of ODUk to OTUk mapping, TPN field MUST be set to 0. Bit 663 Map information is not REQUIRED and MUST NOT be included, so 664 Length field MUST be set to 0 as well. 666 6.2.1. Notification on Label Error 668 When an upstream node receives a Resv message containing a 669 GENERALIZED_LABEL object with an OTN-TDM label, the node MUST verify 670 if the label is acceptable. If the label is not acceptable, the node 671 MUST generate a ResvErr message with a "Routing problem/Unacceptable 672 label value" indication. Per [RFC3473], the generated ResvErr 673 message MAY include an ACCEPTABLE_LABEL_SET object. With the 674 exception of label semantics, downstream node processing a received 675 ResvErr message and of ACCEPTABLE_LABEL_SET object is not modified by 676 this document. 678 Similarly, when a downstream node receives a Path message containing 679 an UPSTREAM_LABEL object with an OTN-TDM label, the node MUST verify 680 if the label is acceptable. If the label is not acceptable, the node 681 MUST generate a PathErr message with a "Routing problem/Unacceptable 682 label value" indication. Per [RFC3473], the generated PathErr message 683 MAY include an ACCEPTABLE_LABEL_SET object. With the exception of 684 label semantics, the upstream nodes processing received a PathErr 685 message and of ACCEPTABLE_LABEL_SET object is not modified by this 686 document. 688 A received label SHALL be considered unacceptable when one of the 689 following cases occurs: 691 - The received label doesn't conform to local policy; 693 - Invalid value in the length field; 695 - The selected link only supports 2.5Gbps TS granularity while the 696 Length field in the label along with ODUk Signal Type indicates 697 the 1.25Gbps TS granularity; 699 - The label includes an invalid TPN value that breaks the TPN 700 assignment rules; 702 - The indicated resources (i.e., the number of "1" in the Bit Map 703 field) are inconsistent with the Traffic Parameters. 705 6.3. Supporting Virtual Concatenation and Multiplication 707 Per [RFC6344], the Virtual Concatenation Groups (VCGs) can be created 708 using Co-Signaled style or Multiple LSPs style. 710 In case of Co-Signaled style, the explicit ordered list of all labels 711 MUST reflect the order of VCG members, which is similar to [RFC4328]. 712 In case of multiplexed virtually concatenated signals (NVC > 1), the 713 first label MUST indicate the components of the first virtually 714 concatenated signal; the second label MUST indicate the components of 715 the second virtually concatenated signal; and so on. In case of 716 multiplication of multiplexed virtually concatenated signals (MT > 717 1), the first label MUST indicate the components of the first 718 multiplexed virtually concatenated signal; the second label MUST 719 indicate components of the second multiplexed virtually concatenated 720 signal; and so on. 722 Support for Virtual Concatenation of ODU1, ODU2 and ODU3 Signal 723 Types, as defined by [RFC6344], is not modified by this document. 724 Virtual Concatenation of other Signal Types is not supported by 725 [G709-2012]. 727 Multiplier (MT) usage is as defined in [RFC6344] and [RFC4328]. 729 6.4. Examples 731 The following examples are given in order to illustrate the label 732 format described in Section 6.1 of this document. 734 (1) ODUk into OTUk mapping: 736 In such conditions, the downstream node along an LSP returns a label 737 indicating that the ODUk (k=1, 2, 3, 4) is directly mapped into the 738 corresponding OTUk. The following example label indicates an ODU1 739 mapped into OTU1. 741 0 1 2 3 742 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 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | TPN = 0 | Reserved | Length = 0 | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 (2) ODUj into ODUk multiplexing: 749 In such conditions, this label indicates that an ODUj is multiplexed 750 into several tributary slots of OPUk and then mapped into OTUk. Some 751 instances are shown as follow: 753 - ODU0 into ODU2 Multiplexing: 755 0 1 2 3 756 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | TPN = 2 | Reserved | Length = 8 | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 |0 1 0 0 0 0 0 0| Padding Bits (0) | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 This above label indicates an ODU0 multiplexed into the second 764 tributary slot of ODU2, wherein there are 8 TSs in ODU2 (i.e., the 765 type of the tributary slot is 1.25Gbps), and the TPN value is 2. 767 - ODU1 into ODU2 Multiplexing with 1.25Gbps TS granularity: 769 0 1 2 3 770 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 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | TPN = 1 | Reserved | Length = 8 | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 |0 1 0 1 0 0 0 0| Padding Bits (0) | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 This above label indicates an ODU1 multiplexed into the 2nd and the 777 4th tributary slot of ODU2, wherein there are 8 TSs in ODU2 (i.e., 778 the type of the tributary slot is 1.25Gbps), and the TPN value is 1. 780 - ODU2 into ODU3 Multiplexing with 2.5Gbps TS granularity: 782 0 1 2 3 783 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 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | TPN = 1 | Reserved | Length = 16 | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 |0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0| Padding Bits (0) | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 This above label indicates an ODU2 multiplexed into the 2nd, 3rd, 5th 791 and 7th tributary slot of ODU3, wherein there are 16 TSs in ODU3 792 (i.e., the type of the tributary slot is 2.5Gbps), and the TPN value 793 is 1. 795 7. Supporting Hitless Adjustment of ODUflex (GFP) 797 [G7044] describes the procedure of ODUflex (GFP) hitless resizing 798 using Link Connection Resize (LCR) and Bandwidth Resize (BWR) 799 protocols in OTN data plane. 801 For the control plane, signaling messages are REQUIRED to initiate 802 the adjustment procedure. Section 2.5 and Section 4.6.4 of [RFC3209] 803 describe how the Shared Explicit (SE) style is used in Traffic 804 Engineering (TE) network for bandwidth increasing and decreasing, 805 which is still applicable for triggering the ODUflex (GFP) adjustment 806 procedure in data plane. 808 Note that the SE style MUST be used at the beginning when creating a 809 resizable ODUflex connection (Signal Type = 21). Otherwise an error 810 with Error Code "Conflicting reservation style" MUST be generated 811 when performing bandwidth adjustment. 813 - Bandwidth increasing 815 For the ingress node, in order to increase the bandwidth of an 816 ODUflex (GFP) connection, a Path message with SE style (keeping 817 Tunnel ID unchanged and assigning a new LSP ID) MUST be sent 818 along the path. 820 The ingress node will trigger the BWR protocol when successful 821 completion of LCR protocols on every hop after Resv message is 822 processed. On success of BWR, the ingress node SHOULD send a 823 PathTear message to delete the old control state (i.e., the 824 control state of the ODUflex (GFP) before resizing) on the 825 control plane. 827 A downstream node receiving Path message with SE style compares 828 the old Traffic Parameters (stored locally) with the new one 829 carried in the Path message, to determine the number of TS to be 830 added. After choosing and reserving new available TS(s), the 831 downstream node MUST send back a Resv message carrying both the 832 old and new GENERALIZED_LABEL objects in the SE flow descriptor. 834 An upstream neighbor receiving Resv message with SE flow 835 descriptor MUST determine which TS(s) is/are added and trigger 836 the LCR protocol between itself and its downstream neighbor node. 838 - Bandwidth decreasing 840 For the ingress node, a Path message with SE style SHOULD also be 841 sent for ODUflex bandwidth decreasing. 843 The ingress node will trigger the BWR protocol when successful 844 completion of LCR handshake on every hop after Resv message is 845 processed. On success of BWR, the second step of LCR, i.e., link 846 connection decrease procedure will be started on every hop of the 847 connection. After completion of bandwidth decreasing, the ingress 848 node SHOULD send a ResvErr message to tear down the old control 849 state. 851 A downstream node receiving Path message with SE style compares 852 the old Traffic Parameters with the new one carried in the Path 853 message to determine the number of TS to be decreased. After 854 choosing TSs to be decreased, the downstream node MUST send back 855 a Resv message carrying both the old and new GENERALIZED_LABEL 856 objects in the SE flow descriptor. 858 An upstream neighbor receiving Resv message with SE flow 859 descriptor MUST determine which TS(s) is/are decreased and 860 trigger the first step of LCR protocol (i.e., LCR handshake) 861 between itself and its downstream neighbor node. 863 8. Operations, Administration and Maintenance (OAM) Considerations 865 Regarding OTN OAM configuration, it could be done through either 866 Network Management Systems (NMS) or GMPLS control plane as defined in 867 [TDM-OAM]. [RFC4783] SHOULD be used for communication of alarm 868 information in GMPLS based OTN. 870 Management Information Base (MIB) may need be extended to read new 871 information (e.g, OTN-TDM Generalized Label, OTN-TDM SENDER_TSPEC/ 872 FLOWSPEC) from the OTN devices. This is out of scope of this 873 document. 875 More information about the management aspects for GMPLS based OTN 876 refer to Section 5.7 of [OTN-FWK]. 878 9. Control Plane Backward Compatibility Considerations 880 As described in [OTN-FWK], since the [RFC4328] has been deployed in 881 the network for the nodes that support the 2001 revision of the G.709 882 specification, control plane backward compatibility SHOULD be taken 883 into consideration. More specifically: 885 o Nodes supporting this document SHOULD support [OTN-OSPF]. 887 o Nodes supporting this document MAY support [RFC4328] signaling. 889 o A node supporting both sets of procedures (i.e., [RFC4328] and 890 this document) is not REQUIRED to signal an LSP using both 891 procedures, i.e., to act as a signaling version translator. 893 o Ingress nodes that support both sets of procedures MAY select 894 which set of procedures to follow based on routing information or 895 local policy. 897 o Per [RFC3473], nodes that do not support this document will 898 generate a PathErr message, with a "Routing problem/Switching 899 Type" indication. 901 10. Security Considerations 903 This document is a modification to [RFC3473] and [RFC4328], and only 904 differs in specific information communicated. As such, this document 905 introduces no new security considerations to the existing GMPLS 906 signaling protocols. Referring to [RFC3473] and [RFC4328], further 907 details of the specific security measures are provided. Additionally, 908 [RFC5920] provides an overview of security vulnerabilities and 909 protection mechanisms for the GMPLS control plane. 911 11. IANA Considerations 913 Upon approval of this document, IANA will make the following 914 assignments in the "Class Types or C-Types 9 FLOWSPEC" and "Class 915 Types or C-Types 12 SENDER_TSPEC" section of the "RSVP Parameters" 916 registry located at http://www.iana.org/assignments/rsvp- 917 parameters/rsvp-parameters.xml. 919 Value Description Reference 920 7(*) OTN-TDM [This.I-D] 922 (*) Suggested value 924 IANA maintains the "Generalized Multi-Protocol Label Switching 925 (GMPLS) Signaling Parameters" registry (see 926 http://www.iana.org/assignments/gmpls-sig-parameters). "Generalized 927 PIDs (G-PID)" subregistry is included in this registry, which will be 928 extended and updated by this document as below. 930 The new G-PIDs should be shown in the TC MIB managed by IANA at 931 https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc- 932 mib.xhtml. 934 Value Type Technology Reference 935 ===== ====================== ========== 936 47 G.709 ODU-2.5G G.709 ODUk [RFC4328] 937 (IANA to update Type field) [This.I-D] 938 56 SBCON/ESCON G.709 ODUk, [RFC4328] 939 (IANA to update Type field) Lambda, Fiber [This.I-D] 940 59* Framed GFP G.709 ODUk [This.I-D] 941 60* STM-1 G.709 ODUk [This.I-D] 942 61* STM-4 G.709 ODUk [This.I-D] 943 62* InfiniBand G.709 ODUflex [This.I-D] 944 63* SDI (Serial Digital Interface) G.709 ODUk [This.I-D] 945 64* SDI/1.001 G.709 ODUk [This.I-D] 946 65* DVB_ASI G.709 ODUk [This.I-D] 947 66* G.709 ODU-1.25G G.709 ODUk [This.I-D] 948 67* G.709 ODU-Any G.709 ODUk [This.I-D] 949 68* Null Test G.709 ODUk [This.I-D] 950 69* Random Test G.709 ODUk [This.I-D] 951 70* 64B/66B GFP-F Ethernet G.709 ODUk [This.I-D] 953 (*) Suggested value 955 Upon approval of this document, IANA will define an "OTN Signal Type" 956 subregistry to the "Generalized Multi-Protocol Label Switching 957 (GMPLS) Signaling Parameters": 959 Value Signal Type Reference 960 ----- ----------- --------- 961 0 Not significant [RFC4328] 962 1 ODU1 (i.e., 2.5Gbps) [RFC4328] 963 2 ODU2 (i.e., 10Gbps) [RFC4328] 964 3 ODU3 (i.e., 40Gbps) [RFC4328] 965 4 ODU4 (i.e., 100Gbps) [this document] 966 5 Reserved (for future use) [RFC4328] 967 6 Och at 2.5Gbps [RFC4328] 968 7 OCh at 10Gbps [RFC4328] 969 8 OCh at 40Gbps [RFC4328] 970 9 OCh at 100Gbps [this document] 971 10 ODU0 (i.e., 1.25Gbps) [this document] 972 11 ODU2e (i.e., 10Gbps for FC1200 [this document] 973 and GE LAN) 974 12~19 Reserved (for future use) [this document] 975 20 ODUflex(CBR) (i.e., 1.25*N Gbps) [this document] 976 21 ODUflex(GFP-F), resizable [this document] 977 (i.e., 1.25*N Gbps) 978 22 ODUflex(GFP-F), non resizable [this document] 979 (i.e., 1.25*N Gbps) 980 23~255 Reserved (for future use) [this document] 982 New values are to be assigned via Standards Action as defined in 983 [RFC5226]. 985 12. References 987 12.1. Normative References 989 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 990 Requirement Levels", BCP 14, RFC 2119, March 1997. 992 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 993 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 994 Functional Specification", RFC 2205, September 1997. 996 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 997 Services", RFC 2210, September 1997. 999 [RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 1000 Tunnels", RFC3209, December 2001. 1002 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 1003 Switching (GMPLS) Signaling Functional Description", RFC 1004 3471, January 2003. 1006 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label Switching 1007 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1008 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1010 [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label 1011 Switching (GMPLS) Signaling Extensions for G.709 Optical 1012 Transport Networks Control", RFC 4328, Jan 2006. 1014 [RFC4506] M. Eisler, Ed., "XDR: External Data Representation 1015 Standard", RFC 4506, May 2006. 1017 [RFC4783] L. Berger, Ed., "GMPLS - Communication of Alarm 1018 Information", RFC 4783, December 2006. 1020 [RFC6344] G. Bernstein et al, "Operating Virtual Concatenation (VCAT) 1021 and the Link Capacity Adjustment Scheme (LCAS) with 1022 Generalized Multi-Protocol Label Switching (GMPLS)", 1023 RFC6344, August 2011. 1025 [OTN-OSPF] D. Ceccarelli et al, "Traffic Engineering Extensions to 1026 OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 1027 OTN Networks", Work in Progress: draft-ietf-ccamp-gmpls- 1028 ospf-g709v3, July 2013. 1030 [G709-2012] ITU-T, "Interfaces for the Optical Transport Network 1031 (OTN)", G.709/Y.1331 Recommendation, February 2012. 1033 [G7044] ITU-T, "Hitless adjustment of ODUflex", G.7044/Y.1347, 1034 October 2011. 1036 [G7041] ITU-T, "Generic framing procedure", G.7041/Y.1303, April 1037 2011. 1039 [IEEE] "IEEE Standard for Binary Floating-Point Arithmetic", 1040 ANSI/IEEE Standard 754-1985, Institute of Electrical and 1041 Electronics Engineers, August 1985. 1043 12.2. Informative References 1045 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1046 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 1047 2008. 1049 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1050 Networks", RFC 5920, July 2010. 1052 [OTN-FWK] Fatai Zhang et al, "Framework for GMPLS and PCE Control of 1053 G.709 Optical Transport Networks", Work in Progress: draft- 1054 ietf-ccamp-gmpls-g709-framework, August 2013. 1056 [OTN-INFO] S. Belotti et al, "Information model for G.709 Optical 1057 Transport Networks (OTN)", Work in Progress: draft-ietf- 1058 ccamp-otn-g709-info-model, July 2013. 1060 [TDM-OAM] A. Kern, A. Takacs, "GMPLS RSVP-TE Extensions for 1061 SONET/SDH and OTN OAM Configuration", draft-ietf-ccamp- 1062 rsvp-te-sdh-otn-oam-ext, Work in Progress. 1064 13. Contributors 1066 Yi Lin 1067 Huawei Technologies 1068 F3-5-B R&D Center, Huawei Base 1069 Bantian, Longgang District 1070 Shenzhen 518129 P.R.China 1071 Phone: +86-755-28972914 1072 Email: yi.lin@huawei.com 1074 Yunbin Xu 1075 China Academy of Telecommunication Research of MII 1076 11 Yue Tan Nan Jie Beijing, P.R.China 1077 Phone: +86-10-68094134 1078 Email: xuyunbin@mail.ritt.com.cn 1080 Pietro Grandi 1081 Alcatel-Lucent 1082 Optics CTO 1083 Via Trento 30 20059 Vimercate (Milano) Italy 1084 +39 039 6864930 1085 Email: pietro_vittorio.grandi@alcatel-lucent.it 1086 Diego Caviglia 1087 Ericsson 1088 Via A. Negrone 1/A 1089 Genova - Sestri Ponente 1090 Italy 1091 Email: diego.caviglia@ericsson.com 1093 Rajan Rao 1094 Infinera Corporation 1095 169, Java Drive 1096 Sunnyvale, CA-94089 1097 USA 1098 Email: rrao@infinera.com 1100 John E Drake 1101 Juniper 1102 Email: jdrake@juniper.net 1104 Igor Bryskin 1105 Adva Optical 1106 EMail: IBryskin@advaoptical.com 1108 Jonathan Sadler, Tellabs 1109 Email: jonathan.sadler@tellabs.com 1111 Kam LAM, Alcatel-Lucent 1112 Email: kam.lam@alcatel-lucent.com 1114 Francesco Fondelli, Ericsson 1115 Email: francesco.fondelli@ericsson.com 1117 Lyndon Ong, Ciena 1118 Email: lyong@ciena.com 1120 Biao Lu, infinera 1121 Email: blu@infinera.com 1123 14. Authors' Addresses 1125 Fatai Zhang (editor) 1126 Huawei Technologies 1127 F3-5-B R&D Center, Huawei Base 1128 Bantian, Longgang District 1129 Shenzhen 518129 P.R.China 1130 Phone: +86-755-28972912 1131 Email: zhangfatai@huawei.com 1133 Guoying Zhang 1134 China Academy of Telecommunication Research of MII 1135 11 Yue Tan Nan Jie Beijing, P.R.China 1136 Phone: +86-10-68094272 1137 Email: zhangguoying@mail.ritt.com.cn 1139 Sergio Belotti 1140 Alcatel-Lucent 1141 Optics CTO 1142 Via Trento 30 20059 Vimercate (Milano) Italy 1143 +39 039 6863033 1144 Email: sergio.belotti@alcatel-lucent.it 1146 Daniele Ceccarelli 1147 Ericsson 1148 Via A. Negrone 1/A 1149 Genova - Sestri Ponente 1150 Italy 1151 Email: daniele.ceccarelli@ericsson.com 1153 Khuzema Pithewan 1154 Infinera Corporation 1155 169, Java Drive 1156 Sunnyvale, CA-94089, USA 1157 Email: kpithewan@infinera.com 1159 15. Acknowledgment 1161 The authors would like to thank Lou Berger, Deborah Brungard and 1162 Xiaobing Zi for their useful comments to the document. 1164 Intellectual Property 1166 The IETF Trust takes no position regarding the validity or scope of 1167 any Intellectual Property Rights or other rights that might be 1168 claimed to pertain to the implementation or use of the technology 1169 described in any IETF Document or the extent to which any license 1170 under such rights might or might not be available; nor does it 1171 represent that it has made any independent effort to identify any 1172 such rights. 1174 Copies of Intellectual Property disclosures made to the IETF 1175 Secretariat and any assurances of licenses to be made available, or 1176 the result of an attempt made to obtain a general license or 1177 permission for the use of such proprietary rights by implementers or 1178 users of this specification can be obtained from the IETF on-line IPR 1179 repository at http://www.ietf.org/ipr 1181 The IETF invites any interested party to bring to its attention any 1182 copyrights, patents or patent applications, or other proprietary 1183 rights that may cover technology that may be required to implement 1184 any standard or specification contained in an IETF Document. Please 1185 address the information to the IETF at ietf-ipr@ietf.org. 1187 The definitive version of an IETF Document is that published by, or 1188 under the auspices of, the IETF. Versions of IETF Documents that are 1189 published by third parties, including those that are translated into 1190 other languages, should not be considered to be definitive versions 1191 of IETF Documents. The definitive version of these Legal Provisions 1192 is that published by, or under the auspices of, the IETF. Versions of 1193 these Legal Provisions that are published by third parties, including 1194 those that are translated into other languages, should not be 1195 considered to be definitive versions of these Legal Provisions. 1197 For the avoidance of doubt, each Contributor to the IETF Standards 1198 Process licenses each Contribution that he or she makes as part of 1199 the IETF Standards Process to the IETF Trust pursuant to the 1200 provisions of RFC 5378. No language to the contrary, or terms, 1201 conditions or rights that differ from or are inconsistent with the 1202 rights and licenses granted under RFC 5378, shall have any effect and 1203 shall be null and void, whether published or posted by such 1204 Contributor, or included with or in such Contribution. 1206 Disclaimer of Validity 1208 All IETF Documents and the information contained therein are provided 1209 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1210 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1211 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1212 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1213 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1214 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1215 FOR A PARTICULAR PURPOSE. 1217 Copyright Notice 1219 Copyright (c) 2013 IETF Trust and the persons identified as the 1220 document authors. All rights reserved. 1222 This document is subject to BCP 78 and the IETF Trust's Legal 1223 Provisions Relating to IETF Documents 1224 (http://trustee.ietf.org/license-info) in effect on the date of 1225 publication of this document. Please review these documents 1226 carefully, as they describe your rights and restrictions with respect 1227 to this document. Code Components extracted from this document must 1228 include Simplified BSD License text as described in Section 4.e of 1229 the Trust Legal Provisions and are provided without warranty as 1230 described in the Simplified BSD License.