idnits 2.17.1 draft-ietf-ccamp-gmpls-signaling-g709v3-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([G709-2012]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (May 31, 2013) is 3976 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: 'G.709-V3' is mentioned on line 132, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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: November 31, 2013 May 31, 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-09.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 November 31, 2013. 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 RFC4328 to provide the extensions to the 48 Generalized Multi-Protocol Label Switching (GMPLS) signaling to 49 control the evolving OTN addressing ODUk multiplexing and new 50 features including 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. Control Plane Backward Compatibility Considerations........... 19 76 9. Security Considerations ...................................... 20 77 10. IANA Considerations.......................................... 20 78 11. References .................................................. 22 79 11.1. Normative References ................................... 22 80 11.2. Informative References ................................. 23 81 12. Contributors ................................................ 23 82 13. Authors' Addresses .......................................... 24 83 14. Acknowledgment .............................................. 26 85 1. Introduction 87 With the evolution and deployment of OTN technology, it is necessary 88 that appropriate enhanced control technology support be provided for 89 [G709-2012]. 91 [OTN-FWK] provides a framework to allow the development of protocol 92 extensions to support GMPLS and Path Computation Element (PCE) 93 control of OTN as specified in [G709-2012]. Based on this framework, 94 [OTN-INFO] evaluates the information needed by the routing and 95 signaling process in OTNs to support GMPLS control of OTN. 97 [RFC4328] describes the control technology details that are specific 98 to the 2001 revision of the G.709 specification. This document 99 updates [RFC4328] to provide Resource ReserVation Protocol-Traffic 100 Engineering (RSVP-TE) extensions to support of control for [G709- 101 2012]. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. GMPLS Extensions for the Evolving G.709 - Overview 111 New features for the evolving OTN, for example, new ODU0, ODU2e, ODU4 112 and ODUflex containers are specified in [G709-2012]. The 113 corresponding new Signal Types are summarized below: 115 - Optical Channel Transport Unit (OTUk): 116 . OTU4 118 - Optical Channel Data Unit (ODUk): 119 . ODU0 120 . ODU2e 121 . ODU4 122 . ODUflex 124 A new Tributary Slot Granularity (TS Granularity, TSG) (i.e., 1.25 125 Gbps) is also described in [G709-2012]. Thus, there are now two TS 126 granularities for the foundation OTN ODU1, ODU2 and ODU3 containers. 128 The TS granularity at 2.5 Gbps is used on legacy interfaces while the 129 new 1.25 Gbps is used on the new interfaces. 131 In addition to the support of ODUk mapping into OTUk (k = 1, 2, 3, 132 4), the evolving OTN [G.709-V3] encompasses the multiplexing of ODUj 133 (j = 0, 1, 2, 2e, 3, flex) into an ODUk (k > j), as described in 134 Section 3.1.2 of [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 needs to be updated because it does not provide the means to signal 144 all the new Signal Types and related mapping and multiplexing 145 functionalities. Moreover, it supports only the deprecated auto- 146 Multiframe Structure Identifier (MSI) mode which assumes that the 147 Tributary Port Number (TPN) is automatically assigned in the transmit 148 direction and not checked in the receive direction. 150 This document extends the G.709 Traffic Parameters described in 151 [RFC4328] and presents a new flexible and scalable OTN label format. 152 Additionally, procedures about Tributary Port Number assignment 153 through control plane are also provided in this document. 155 4. Generalized Label Request 157 The Generalized Label Request, as described in [RFC3471], carries the 158 Label Switched Path (LSP) Encoding Type, the Switching Type and the 159 Generalized Protocol Identifier (G-PID). 161 [RFC4328] extends the Generalized Label Request, introducing two new 162 code-points for the LSP Encoding Type (i.e., G.709 ODUk (Digital 163 Path) and G.709 Optical Channel) and adding a list of G-PID values in 164 order to accommodate the 2001 revision of the G.709 specification. 166 This document follows these extensions and a new Switching Type is 167 introduced to indicate the ODUk switching capability [G709-2012] in 168 order to support backward compatibility with [RFC4328], as described 169 in [OTN-FWK]. The new Switching Type (OTN-TDM Switching Type) is 170 defined in [OTN-OSPF]. 172 This document also updates the G-PID values defined in [RFC4328]: 174 Value G-PID Type 175 ----- ---------- 176 47 Type field updated from "G.709 ODUj" to "ODU-2.5G" to 177 indicates transport of Digital Paths (e.g., at 2.5, 10 and 178 40 Gbps) via 2.5Gbps TSG 180 56 Type field updated from "ESCON" to "SBCON/ESCON" to align 181 with [G709-2012] payload type 0x1A. 183 Note: Value 47 includes mapping of Synchronous Digital Hierarchy 184 (SDH). 186 In the case of ODU multiplexing, the Lower Order ODU (LO ODU) (i.e., 187 the client signal) may be multiplexed into Higher Order ODU (HO ODU) 188 via 1.25G TSG, 2.5G TSG or any one of them (i.e., TSG 189 Auto_Negotiation is enabled). Since the G-PID type "ODUk" defined in 190 [RFC4328] is only used for 2.5Gbps TSG, two new G-PID types are 191 defined as follows: 193 - ODU-1.25G: Transport of Digital Paths at 1.25, 2.5, 10, 40 and 100 194 Gbps via 1.25Gbps TSG 196 - ODU-any: Transport of Digital Paths at 1.25, 2.5, 10, 40 and 100 197 Gbps via 1.25 or 2.5Gbps TSG (i.e., the fallback 198 procedure is enabled and the default value of 1.25Gbps 199 TSG can be fallen back to 2.5Gbps if needed) 201 The full list of payload types defined in [G709-2012] and their 202 mapping to existing and new G-PID types are as follows: 204 G.709 205 Payload 206 Type G-PID Type/Comment LSP Encoding 207 ==== ===== ===================== =================== 208 0x01 No standard value 209 0x02 49 CBRa G.709 ODUk 210 0x03 50 CBRb G.709 ODUk 211 0x04 32 ATM G.709 ODUk 212 0x05 59(TBA) Framed GFP G.709 ODUk 213 54 Ethernet MAC (framed GFP) G.709 ODUk 214 70(TBA) 64B/66B GFP-F Ethernet G.709 ODUk (k=2) 215 0x06 Not signaled 216 0x07 55 Ethernet PHY G.709 ODUk (k=0,3,4) 217 (transparent GFP) 218 0x08 58 Fiber Channel G.709 ODUk (k=2e) 219 0x09 59(TBA) Framed GFP G.709 ODUk (k=2) 220 70(TBA) 64B/66B GFP-F Ethernet G.709 ODUk (k=2) 222 0x0A 60(TBA) STM-1 G.709 ODUk (k=0) 223 0x0B 61(TBA) STM-4 G.709 ODUk (k=0) 224 0x0C 58 Fiber Channel G.709 ODUk (k=0) 225 0x0D 58 Fiber Channel G.709 ODUk (k=1) 226 0x0E 58 Fiber Channel G.709 ODUflex 227 0x0F 58 Fiber Channel G.709 ODUflex 228 0x10 51 BSOT G.709 ODUk 229 0x11 52 BSNT G.709 ODUk 230 0x12 62(TBA) InfiniBand G.709 ODUflex 231 0x13 62(TBA) InfiniBand G.709 ODUflex 232 0x14 62(TBA) InfiniBand G.709 ODUflex 233 0x15 63(TBA) Serial Digital Interface G.709 ODUk (k=0) 234 0x16 64(TBA) Serial Digital G.709 ODUk (k=1) 235 Interface/1.001 236 0x17 63(TBA) Serial Digital Interface G.709 ODUk (k=1) 237 0x18 64(TBA) Serial Digital G.709 ODUflex 238 Interface/1.001 239 0x19 63(TBA) Serial Digital Interface G.709 ODUflex 240 0x1A 56 SBCON/ESCON G.709 ODUk (k=0) 241 (IANA to update Type field) 242 0x1B 65(TBA) DVB_ASI G.709 ODUk (k=0) 243 0x1C 58 Fiber Channel G.709 ODUk 244 0x20 47 G.709 ODU-2.5G G.709 ODUk (k=2,3) 245 (IANA to update Type field) 246 66(TBA) G.709 ODU-1.25G G.709 ODUk (k=1) 247 0x21 66(TBA) G.709 ODU-1.25G G.709 ODUk (k=2,3,4) 248 67(TBA) G.709 ODU-Any G.709 ODUk (k=2,3) 249 0x55 No standard value 250 0x66 No standard value 251 0x80-0x8F No standard value 252 0xFD 68(TBA) Null Test G.709 ODUk 253 0xFE 69(TBA) Random Test G.709 ODUk 254 0xFF No standard value 256 Note: Values 59 and 70 include mapping of SDH. 258 Note that the mapping types for ODUj into OPUk are unambiguously per 259 Table 7-10 of [G709-2012], so it does not need to carry mapping type 260 information in the signaling. 262 Note also that additional information on G.709 client mapping can be 263 found in [G7041]. 265 5. Extensions for Traffic Parameters for the Evolving G.709 267 The Traffic Parameters for OTN-TDM capable Switching Type are carried 268 in the OTN-TDM SENDER_TSPEC and FLOWSPEC objects. The objects have 269 the following class and type: 271 - OTN-TDM SENDER_TSPEC Object: Class = 12, C-Type = 7 (TBA) 272 - OTN-TDM FLOWSPEC Object: Class = 9, C-Type = 7 (TBA) 274 The format of Traffic Parameters in these two objects is defined as 275 follows: 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Signal Type | Reserved | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | NVC | Multiplier (MT) | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Bit_Rate | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Signal Type: 8 bits 289 As defined in [RFC4328] Section 3.2.1, with the following 290 additional values: 292 Value Type 293 ----- ---- 294 4 ODU4 (i.e., 100 Gbps) 295 9 OCh at 100 Gbps 296 10 ODU0 (i.e., 1.25 Gbps) 297 11 ODU2e (i.e., 10Gbps for FC1200 and GE LAN) 298 12~19 Reserved (for future use) 299 20 ODUflex(CBR) (i.e., 1.25*N Gbps) 300 21 ODUflex(Generic Framing Procedure-Framed (GFP-F)), 301 resizable (i.e., 1.25*N Gbps) 302 22 ODUflex(GFP-F), non resizable (i.e., 1.25*N Gbps) 303 23~255 Reserved (for future use) 305 NVC: 16 bits 307 As defined in [RFC4328] Section 3.2.3. This field MUST be set to 308 0 for ODUflex Signal Types. 310 Multiplier (MT): 16 bits 311 As defined in [RFC4328] Section 3.2.4. This field MUST be set to 312 1 for ODUflex Signal Types. 314 Bit_Rate: 32 bits 316 In case of ODUflex including ODUflex(CBR) and ODUflex(GFP) Signal 317 Types, this field indicates the nominal bit rate of ODUflex 318 expressed in bytes per second, encoded as a 32-bit IEEE single- 319 precision floating-point number (referring to [RFC4506] and 320 [IEEE]). For other Signal Types, this field MUST be set to zero 321 on transmission and MUST be ignored on receipt and SHOULD be 322 passed unmodified by transit nodes. 324 5.1. Usage of ODUflex(CBR) Traffic Parameters 326 In case of ODUflex(CBR), the information of Bit_Rate carried in the 327 ODUflex Traffic Parameters MUST be used to determine the actual 328 bandwidth of ODUflex(CBR) (i.e., Bit_Rate * (1 +/- Tolerance)). 329 Therefore the total number of tributary slots N in the HO ODUk link 330 can be reserved correctly. Here: 332 N = Ceiling of 334 ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance) 335 --------------------------------------------------------------------- 336 ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) 338 In this formula, the ODUflex(CBR) nominal bit rate is the bit rate of 339 the ODUflex(CBR) on the line side, i.e., the client signal bit rate 340 after applying the 239/238 factor (according to Clause 7.3, Table 7-2 341 of [G709-2012]) and the transcoding factor T (if needed) on the CBR 342 client. According to clauses 17.7.3, 17.7.4 and 17.7.5 of [G709- 343 2012]: 345 ODUflex(CBR) nominal bit rate = CBR client bit rate * (239/238) / T 347 The ODTUk.ts (Optical channel Data Tributary Unit k with ts tributary 348 slots) nominal bit rate is the nominal bit rate of the tributary slot 349 of ODUk, as shown in Table 1 (referring to Table 7-7 of [G709-2012]). 351 Table 1 - Actual TS bit rate of ODUk (in Kbps) 353 ODUk.ts Minimum Nominal Maximum 354 ----------------------------------------------------------- 355 ODU2.ts 1,249,384.632 1,249,409.620 1,249,434.608 356 ODU3.ts 1,254,678.635 1,254,703.729 1,254,728.823 357 ODU4.ts 1,301,683.217 1,301,709.251 1,301,735.285 359 Note that: 361 Minimum bit rate of ODUTk.ts = 362 ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) 364 Maximum bit rate of ODTUk.ts = 365 ODTUk.ts nominal bit rate * (1 + HO OPUk bit rate tolerance) 367 Where: HO OPUk bit rate tolerance = 20ppm 369 Note that the bit rate tolerance is implicit in Signal Type and the 370 ODUflex(CBR) bit rate tolerance is fixed and it is equal to 100ppm as 371 described in Table 7-2 of [G709-2012]. 373 Therefore, a node receiving a PATH message containing ODUflex(CBR) 374 nominal bit rate can allocate precise number of tributary slots and 375 set up the cross-connection for the ODUflex service. 377 Note that for different ODUk, the bit rates of the tributary slots 378 are different, and so the total number of tributary slots to be 379 reserved for the ODUflex(CBR) MAY not be the same on different HO 380 ODUk links. 382 An example is given below to illustrate the usage of ODUflex(CBR) 383 Traffic Parameters. 385 As shown in Figure 1, assume there is an ODUflex(CBR) service 386 requesting a bandwidth of (2.5Gbps, +/-100ppm) from node A to node C. 387 In other words, the ODUflex Traffic Parameters indicate that Signal 388 Type is 20 (ODUflex(CBR)), Bit_Rate is 2.5Gbps and Tolerance is 389 100ppm. 391 +-----+ +---------+ +-----+ 392 | +-------------+ +-----+ +-------------+ | 393 | +=============+\| ODU |/+=============+ | 394 | +=============+/| flex+-+=============+ | 395 | +-------------+ | |\+=============+ | 396 | +-------------+ +-----+ +-------------+ | 397 | | | | | | 398 | | ....... | | ....... | | 399 | A +-------------+ B +-------------+ C | 400 +-----+ HO ODU4 +---------+ HO ODU2 +-----+ 402 =========: TS occupied by ODUflex 403 ---------: free TS 405 Figure 1 - Example of ODUflex(CBR) Traffic Parameters 407 - On the HO ODU4 link between node A and B: 409 The maximum bit rate of the ODUflex(CBR) equals 2.5Gbps * (1 + 410 100ppm), and the minimum bit rate of the tributary slot of ODU4 411 equals 1,301,683.217 Kbps, so the total number of tributary slots 412 N1 to be reserved on this link is: 414 N1 = ceiling (2.5Gbps * (1 + 100ppm) / 1,301,683.217 Kbps) = 2 416 - On the HO ODU2 link between node B and C: 418 The maximum bit rate of the ODUflex equals 2.5Gbps * (1 + 419 100ppm), and the minimum bit rate of the tributary slot of ODU2 420 equals 1,249,384.632 Kbps, so the total number of tributary slots 421 N2 to be reserved on this link is: 423 N2 = ceiling (2.5Gbps * (1 + 100ppm) / 1,249,384.632 Kbps) = 3 425 5.2. Usage of ODUflex(GFP) Traffic Parameters 427 [G709-2012] recommends that the ODUflex(GFP) will fill an integral 428 number of tributary slots of the smallest HO ODUk path over which the 429 ODUflex(GFP) may be carried, as shown in Table 2. 431 Table 2 - Recommended ODUflex(GFP) bit rates and tolerance 433 ODU type | Nominal bit-rate | Tolerance 434 --------------------------------+------------------+----------- 435 ODUflex(GFP) of n TS, 1<=n<=8 | n * ODU2.ts | +/-100 ppm 436 ODUflex(GFP) of n TS, 9<=n<=32 | n * ODU3.ts | +/-100 ppm 437 ODUflex(GFP) of n TS, 33<=n<=80 | n * ODU4.ts | +/-100 ppm 439 According to this table, the Bit_Rate field for ODUflex(GFP) MUST 440 equal to one of the 80 values listed below: 442 1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts; 443 9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts; 444 33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts. 446 In this way, the number of required tributary slots for the 447 ODUflex(GFP) (i.e., the value of "n" in Table 2) can be deduced from 448 the Bit_Rate field. 450 5.3. Notification on Errors of OTN-TDM Traffic Parameters 452 There is no Adspec associated with the OTN-TDM SENDER_TSPEC. Either 453 the Adspec is omitted or an Int-serv Adspec with the Default General 454 Characterization Parameters and Guaranteed Service fragment is used, 455 see [RFC2210]. 457 For a particular sender in a session, the contents of the FLOWSPEC 458 object received in a Resv message SHOULD be identical to the contents 459 of the SENDER_TSPEC object received in the corresponding Path 460 message. If the objects do not match, a ResvErr message with a 461 "Traffic Control Error/Bad Flowspec value" error MUST be generated. 463 Intermediate and egress nodes MUST verify that the node itself, and 464 the interfaces on which the LSP will be established, can support the 465 requested Signal Type, NVC and Bit_Rate values. If the requested 466 value(s) cannot be supported, the receiver node MUST generate a 467 PathErr message with a "Traffic Control Error/Service unsupported" 468 indication (see [RFC2205]). 470 In addition, if the MT field is received with a zero value, the node 471 MUST generate a PathErr message with a "Traffic Control Error/Bad 472 Tspec value" indication (see [RFC2205]). 474 Further, if the Signal Type is not ODU1, ODU2 or ODU3, and the NVC 475 field is not 0, the node MUST generate a PathErr message with a 476 "Traffic Control Error/Bad Tspec value" indication (see [RFC2205]). 478 6. Generalized Label 480 This section defines the format of the OTN-TDM Generalized Label. 482 6.1. OTN-TDM Switching Type Generalized Label 484 The following is the Generalized Label format for that MUST be used 485 with the OTN-TDM Switching Type: 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | TPN | Reserved | Length | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 ~ Bit Map ...... ~ 493 ~ ...... | Padding Bits ~ 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 The OTN-TDM Generalized Label is used to indicate how the LO ODUj 497 signal is multiplexed into the HO ODUk link. Note that the LO OUDj 498 signal type is indicated by Traffic Parameters, while the type of HO 499 ODUk link is identified by the selected interface carried in the 500 IF_ID RSVP_HOP Object. 502 TPN (12 bits): indicates the TPN for the assigned Tributary Slot(s). 504 - In case of LO ODUj multiplexed into HO ODU1/ODU2/ODU3, only the 505 lower 6 bits of TPN field are significant and the other bits of 506 TPN MUST be set to 0. 508 - In case of LO ODUj multiplexed into HO ODU4, only the lower 7 509 bits of TPN field are significant and the other bits of TPN 510 MUST be set to 0. 512 - In case of ODUj mapped into OTUk (j=k), the TPN is not needed 513 and this field MUST be set to 0. 515 Per [G709-2012], The TPN is used to allow for correct demultiplexing 516 in the data plane. When an LO ODUj is multiplexed into HO ODUk 517 occupying one or more TSs, a new TPN value is configured at the two 518 ends of the HO ODUk link and is put into the related MSI byte(s) in 519 the OPUk overhead at the (traffic) ingress end of the link, so that 520 the other end of the link can learn which TS(s) is/are used by the LO 521 ODUj in the data plane. 523 According to [G709-2012], the TPN field MUST be set as according to 524 the following tables: 526 Table 3 - TPN Assignment Rules (2.5Gbps TS granularity) 527 +-------+-------+----+----------------------------------------------+ 528 |HO ODUk|LO ODUj|TPN | TPN Assignment Rules | 529 +-------+-------+----+----------------------------------------------+ 530 | ODU2 | ODU1 |1~4 |Fixed, = TS# occupied by ODU1 | 531 +-------+-------+----+----------------------------------------------+ 532 | | ODU1 |1~16|Fixed, = TS# occupied by ODU1 | 533 | ODU3 +-------+----+----------------------------------------------+ 534 | | ODU2 |1~4 |Flexible, != other existing LO ODU2s' TPNs | 535 +-------+-------+----+----------------------------------------------+ 536 Table 4 - TPN Assignment Rules (1.25Gbps TS granularity) 537 +-------+-------+----+----------------------------------------------+ 538 |HO ODUk|LO ODUj|TPN | TPN Assignment Rules | 539 +-------+-------+----+----------------------------------------------+ 540 | ODU1 | ODU0 |1~2 |Fixed, = TS# occupied by ODU0 | 541 +-------+-------+----+----------------------------------------------+ 542 | | ODU1 |1~4 |Flexible, != other existing LO ODU1s' TPNs | 543 | ODU2 +-------+----+----------------------------------------------+ 544 | |ODU0 & |1~8 |Flexible, != other existing LO ODU0s and | 545 | |ODUflex| |ODUflexes' TPNs | 546 +-------+-------+----+----------------------------------------------+ 547 | | ODU1 |1~16|Flexible, != other existing LO ODU1s' TPNs | 548 | +-------+----+----------------------------------------------+ 549 | | ODU2 |1~4 |Flexible, != other existing LO ODU2s' TPNs | 550 | ODU3 +-------+----+----------------------------------------------+ 551 | |ODU0 & | |Flexible, != other existing LO ODU0s and | 552 | |ODU2e &|1~32|ODU2es and ODUflexes' TPNs | 553 | |ODUflex| | | 554 +-------+-------+----+----------------------------------------------+ 555 | ODU4 |Any ODU|1~80|Flexible, != ANY other existing LO ODUs' TPNs | 556 +-------+-------+----+----------------------------------------------+ 558 Note that in the case of "Flexible", the value of TPN MAY not be 559 corresponding to the TS number as per [G709-2012]. 561 Length (12 bits): indicates the number of bits of the Bit Map field, 562 i.e., the total number of TS in the HO ODUk link. The TS granularity, 563 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's 564 rate by the value of the Length field. In the context of [G709-2012], 565 the values of 4 and 16 indicate a TS granularity of 2.5Gps, and the 566 values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps. 568 In case of an ODUk mapped into OTUk, there is no need to indicate 569 which tributary slots will be used, so the length field MUST be set 570 to 0. 572 Bit Map (variable): indicates which tributary slots in HO ODUk that 573 the LO ODUj will be multiplexed into. The sequence of the Bit Map is 574 consistent with the sequence of the tributary slots in HO ODUk. Each 575 bit in the bit map represents the corresponding tributary slot in HO 576 ODUk with a value of 1 or 0 indicating whether the tributary slot 577 will be used by LO ODUj or not. 579 Padding bits are added after the Bit Map to make the whole label a 580 multiple of four bytes if necessary. Padding bits MUST be set to 0 581 and MUST be ignored. 583 6.2. Procedures 585 The ingress node MUST generate a Path message and specify the OTN-TDM 586 Switching Type and corresponding G-PID in the Generalized Label 587 Request object, which MUST be processed as defined in [RFC3473]. 589 The ingress node of an LSP MAY include label ERO (Explicit Route 590 Object) to indicate the label in each hops along the path. Note that 591 the TPN in the label ERO subobject MAY not be assigned by the ingress 592 node. In this case, the node MUST assign a valid TPN value and then 593 put this value into TPN field of the label object when receiving a 594 Path message. 596 In order to create bidirectional LSP, the ingress node and upstream 597 node MUST generate an Upstream Label on the out outgoing interface to 598 indicate the reserved TSs of ODUk and the assigned TPN value in the 599 upstream direction. This Upstream Label is sent to the downstream 600 node via Path massage for upstream resource reservation. 602 The ingress node or upstream node MAY generate Label Set to indicate 603 which labels on the outgoing interface in the downstream direction 604 are acceptable. The downstream node will restrict its choice of 605 labels, i.e., TS resource and TPN value, to one which is in the Label 606 Set. 608 The ingress node or upstream node MAY also generate Suggested Label 609 to indicate the preference of TS resource and TPN value on the 610 outgoing interface in the downstream direction. The downstream node 611 is not REQUIRED to use the Suggested Label and MAY use another label 612 based on local decision and send it to the upstream node, as 613 described in [RFC3473]. 615 When an upstream node receives a Resv message containing an LABEL 616 object with an OTN-TDM label, it MUST firstly identify which ODU 617 Signal Type is multiplexed or mapped into which ODU Signal Type 618 accordingly to the Traffic Parameters and the IF_ID RSVP_HOP Object 619 in the received message. 621 - In case of ODUj to ODUk multiplexing, the node MUST retrieve the 622 reserved tributary slots in the ODUk by its downstream neighbor 623 node according to the position of the bits that are set to 1 in 624 the Bit Map field. The node determines the TS type (according to 625 the total TS number of the ODUk, or pre-configured TS type), so 626 that the node can multiplex the ODUj into the ODUk based on the TS 627 type. The node MUST also retrieve the TPN value assigned by its 628 downstream neighbor node from the label, and fill the TPN into the 629 related MSI byte(s) in the OPUk overhead in the data plane, so 630 that the downstream neighbor node can check whether the TPN 631 received from the data plane is consistent with the ExMSI and 632 determine whether there is any mismatch defect. 634 - In case of ODUk to OTUk mapping, the size of Bit Map field MUST be 635 0 and no additional procedure is needed. 637 When a downstream node or egress node receives a Path message 638 containing Generalized Label Request object for setting up an ODUj 639 LSP from its upstream neighbor node, the node MUST generate an OTN- 640 TDM label according to the Signal Type of the requested LSP and the 641 free resources (i.e., free tributary slots of ODUk) that will be 642 reserved for the LSP, and send the label to its upstream neighbor 643 node. 645 - In case of ODUj to ODUk multiplexing, the node MUST firstly 646 determine the size of the Bit Map field according to the Signal 647 Type and the tributary slot type of ODUk, and then set the bits to 648 1 in the Bit Map field corresponding to the reserved tributary 649 slots. The node MUST also assign a valid TPN, which MUST NOT 650 collide with other TPN value used by existing LO ODU connections 651 in the selected HO ODU link, and configure the Expected MSI 652 (ExMSI) using this TPN. Then, the assigned TPN MUST be filled into 653 the label. 655 - In case of ODUk to OTUk mapping, TPN field MUST be set to 0. Bit 656 Map information is not REQUIRED and MUST NOT be included, so 657 Length field MUST be set to 0 as well. 659 6.2.1. Notification on Label Error 661 When an upstream node receives a Resv message containing an LABEL 662 object with an OTN-TDM label, the node MUST verify if the label is 663 acceptable. If the label is not acceptable, the node MUST generate a 664 ResvErr message with a "Routing problem/Unacceptable label value" 665 indication. Per [RFC3473], the generated ResvErr message MAY include 666 an ACCEPTABLE_LABEL_SET object. With the exception of label 667 semantics, downstream node processing a received ResvErr messages and 668 of ACCEPTABLE_LABEL_SET objects is not modified by this document. 670 Similarly, when a downstream node receives a Path message containing 671 an UPSTREAM_LABEL object with an OTN-TDM label, the node MUST verify 672 if the label is acceptable. If the label is not acceptable, the node 673 MUST generate a PathErr message with a "Routing problem/Unacceptable 674 label value" indication. Per [RFC3473], the generated ResvErr message 675 MAY include an ACCEPTABLE_LABEL_SET object. With the exception of 676 label semantics, downstream node processing received PathErr messages 677 and of ACCEPTABLE_LABEL_SET objects is not modified by this document. 679 A received label SHALL be considered unacceptable when one of the 680 following cases occurs: 682 - The received label doesn't conform to local policy; 684 - Invalid value in the length field; 686 - The selected link only supports 2.5Gbps TS granularity while the 687 Length field in the label along with ODUk Signal Type indicates 688 the 1.25Gbps TS granularity; 690 - The label includes an invalid TPN value that breaks the TPN 691 assignment rules; 693 - The indicated resources (i.e., the number of "1" in the Bit Map 694 field) are inconsistent with the Traffic Parameters. 696 6.3. Supporting Virtual Concatenation and Multiplication 698 Per [RFC6344], the Virtual Concatenation Groups (VCGs) can be created 699 using Co-Signaled style or Multiple LSPs style. 701 In case of Co-Signaled style, the explicit ordered list of all labels 702 MUST reflect the order of VCG members, which is similar to [RFC4328]. 703 In case of multiplexed virtually concatenated signals (NVC > 1), the 704 first label MUST indicate the components of the first virtually 705 concatenated signal; the second label MUST indicate the components of 706 the second virtually concatenated signal; and so on. In case of 707 multiplication of multiplexed virtually concatenated signals (MT > 708 1), the first label MUST indicate the components of the first 709 multiplexed virtually concatenated signal; the second label MUST 710 indicate components of the second multiplexed virtually concatenated 711 signal; and so on. 713 Support for Virtual Concatenation of ODU1, ODU2 and ODU3 Signal 714 Types, as defined by [RFC6344], is not modified by this document. 715 Virtual Concatenation of other Signal Types is not supported by 716 [G709-2012]. 718 Multiplier (MT) usage is as defined in [RFC6344] and [RFC4328]. 720 6.4. Examples 722 The following examples are given in order to illustrate the label 723 format described in Section 6.1 of this document. 725 (1) ODUk into OTUk mapping: 727 In such conditions, the downstream node along an LSP returns a label 728 indicating that the ODUk (k=1, 2, 3, 4) is directly mapped into the 729 corresponding OTUk. The following example label indicates an ODU1 730 mapped into OTU1. 732 0 1 2 3 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | TPN = 0 | Reserved | Length = 0 | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 (2) ODUj into ODUk multiplexing: 740 In such conditions, this label indicates that an ODUj is multiplexed 741 into several tributary slots of OPUk and then mapped into OTUk. Some 742 instances are shown as follow: 744 - ODU0 into ODU2 Multiplexing: 746 0 1 2 3 747 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 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | TPN = 2 | Reserved | Length = 8 | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 |0 1 0 0 0 0 0 0| Padding Bits (0) | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 This above label indicates an ODU0 multiplexed into the second 755 tributary slot of ODU2, wherein there are 8 TS in ODU2 (i.e., the 756 type of the tributary slot is 1.25Gbps), and the TPN value is 2. 758 - ODU1 into ODU2 Multiplexing with 1.25Gbps TS granularity: 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | TPN = 1 | Reserved | Length = 8 | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 |0 1 0 1 0 0 0 0| Padding Bits (0) | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 This above label indicates an ODU1 multiplexed into the 2nd and the 768 4th tributary slot of ODU2, wherein there are 8 TS in ODU2 (i.e., the 769 type of the tributary slot is 1.25Gbps), and the TPN value is 1. 771 - ODU2 into ODU3 Multiplexing with 2.5Gbps TS granularity: 773 0 1 2 3 774 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 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | TPN = 1 | Reserved | Length = 16 | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 |0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0| Padding Bits (0) | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 This above label indicates an ODU2 multiplexed into the 2nd, 3rd, 5th 782 and 7th tributary slot of ODU3, wherein there are 16 TS in ODU3 783 (i.e., the type of the tributary slot is 2.5Gbps), and the TPN value 784 is 1. 786 7. Supporting Hitless Adjustment of ODUflex (GFP) 788 [G7044] describes the procedure of ODUflex (GFP) hitless resizing 789 using Link Connection Resize (LCR) and Bandwidth Resize (BWR) 790 protocols in OTN data plane. 792 For the control plane, signaling messages are REQUIRED to initiate 793 the adjustment procedure. Section 2.5 and Section 4.6.4 of [RFC3209] 794 describe how the Shared Explicit (SE) style is used in Traffic 795 Engineering (TE) network for bandwidth increasing and decreasing, 796 which is still applicable for triggering the ODUflex (GFP) adjustment 797 procedure in data plane. 799 Note that the SE style MUST be used at the beginning when creating a 800 resizable ODUflex connection (Signal Type = 21). Otherwise an error 801 with Error Code "Conflicting reservation style" MUST be generated 802 when performing bandwidth adjustment. 804 - Bandwidth increasing 806 For the ingress node, in order to increase the bandwidth of an 807 ODUflex (GFP) connection, a Path message with SE style (keeping 808 Tunnel ID unchanged and assigning a new LSP ID) MUST be sent 809 along the path. 811 The ingress node will trigger the BWR protocol when successful 812 completion of LCR protocols on every hop after Resv message is 813 processed. On success of BWR, the ingress node SHOULD send a 814 PathTear message to delete the old control state (i.e., the 815 control state of the ODUflex (GFP) before resizing) on the 816 control plane. 818 A downstream node receiving Path message with SE style compares 819 the old Traffic Parameters (stored locally) with the new one 820 carried in the Path message, to determine the number of TS to be 821 added. After choosing and reserving new free TS, the downstream 822 node MUST send back a Resv message carrying both the old and new 823 LABEL Objects in the SE flow descriptor. 825 An upstream neighbor receiving Resv message with SE flow 826 descriptor MUST determine which TS are added and trigger the LCR 827 protocol between itself and its downstream neighbor node. 829 - Bandwidth decreasing 831 For the ingress node, a Path message with SE style SHOULD also be 832 sent for ODUflex bandwidth decreasing. 834 The ingress node will trigger the BWR protocol when successful 835 completion of LCR handshake on every hop after Resv message is 836 processed. On success of BWR, the second step of LCR, i.e., link 837 connection decrease procedure will be started on every hop of the 838 connection. After completion of bandwidth decreasing, the ingress 839 node SHOULD send a ResvErr message to tear down the old control 840 state. 842 A downstream node receiving Path message with SE style compares 843 the old Traffic Parameters with the new one carried in the Path 844 message to determine the number of TS to be decreased. After 845 choosing TSs to be decreased, the downstream node MUST send back 846 a Resv message carrying both the old and new LABEL Objects in the 847 SE flow descriptor. 849 An upstream neighbor receiving Resv message with SE flow 850 descriptor MUST determine which TS are decreased and trigger the 851 first step of LCR protocol (i.e., LCR handshake) between itself 852 and its downstream neighbor node. 854 8. Control Plane Backward Compatibility Considerations 856 As described in [OTN-FWK], since the [RFC4328] has been deployed in 857 the network for the nodes that support the 2001 revision of the G.709 858 specification, control plane backward compatibility SHOULD be taken 859 into consideration. More specifically: 861 o Nodes supporting this document SHOULD support [OTN-OSPF]. 863 o Nodes supporting this document MAY support [RFC4328] signaling. 865 o A node supporting both sets of procedures (i.e., [RFC4328] and 866 this document) is not REQUIRED to signal an LSP using both 867 procedures, i.e., to act as a signaling version translator. 869 o Ingress nodes that support both sets of procedures MAY select 870 which set of procedures to follow based on routing information or 871 local policy. 873 o Per [RFC3473], nodes that do not support this document will 874 generate a PathErr message, with a "Routing problem/Switching 875 Type" indication. 877 9. Security Considerations 879 This document introduces no new security considerations to the 880 existing GMPLS signaling protocols. Referring to [RFC3473] and 881 [RFC4328], further details of the specific security measures are 882 provided. Additionally, [RFC5920] provides an overview of security 883 vulnerabilities and protection mechanisms for the GMPLS control 884 plane. 886 10. IANA Considerations 888 Two RSVP C-Types are defined for OTN-TDM Traffic Parameters in this 889 document: 890 http://www.iana.org/assignments/rsvp-parameters 892 - OTN-TDM SENDER_TSPEC and FLOWSPEC objects: 894 o OTN-TDM SENDER_TSPEC Object: Class = 12, C-Type = 7 (see 895 Section 5) 897 o OTN-TDM FLOWSPEC Object: Class = 9, C-Type = 7 (see Section 5) 899 IANA maintains the "Generalized Multi-Protocol Label Switching 900 (GMPLS) Signaling Parameters" registry (see 901 http://www.iana.org/assignments/gmpls-sig-parameters). "Generalized 902 PIDs (G-PID)" subregistry is included in this registry, which will be 903 extended and updated by this document as below: 905 - Generalized PID (G-PID): 907 Name: G-PID 908 Format: 16-bit number 909 Values: 911 Value Type/Comment LSP Encoding/Technology 912 ======= ====================== ======================= 913 47 G.709 ODU-2.5G G.709 ODUk (k=2,3) 914 (IANA to update Type field) 915 56 SBCON/ESCON G.709 ODUk, Lambda, Fiber 916 (IANA to update Type field) 917 59(TBA) Framed GFP G.709 ODUk 918 60(TBA) STM-1 G.709 ODUk (k=0) 919 61(TBA) STM-4 G.709 ODUk (k=0) 920 62(TBA) InfiniBand G.709 ODUflex 921 63(TBA) Serial Digital Interface G.709 ODUk (k=0,1,flex) 922 64(TBA) Serial Digital Interface/1.001 G.709 ODUk (k=1,flex) 923 65(TBA) DVB_ASI G.709 ODUk (k=0) 924 66(TBA) G.709 ODU-1.25G G.709 ODUk 925 67(TBA) G.709 ODU-Any G.709 ODUk (k=2,3) 926 68(TBA) Null Test G.709 ODUk 927 69(TBA) Random Test G.709 ODUk 928 70(TBA) 64B/66B GFP-F Ethernet G.709 ODUk (k=2) 930 "Signal Type" subregistry to the "Generalized Multi-Protocol Label 931 Switching (GMPLS) Signaling Parameters" will be defined by this 932 document as below: 934 Value Signal Type Reference 935 ----- ----------- --------- 936 0 Not significant [RFC4328] 937 1 ODU1 (i.e., 2.5 Gbps) [RFC4328] 938 2 ODU2 (i.e., 10 Gbps) [RFC4328] 939 3 ODU3 (i.e., 40 Gbps) [RFC4328] 940 4 ODU4 (i.e., 100 Gbps) [this document] 941 5 Reserved (for future use) [RFC4328] 942 6 Och at 2.5 Gbps [RFC4328] 943 7 OCh at 10 Gbps [RFC4328] 944 8 OCh at 40 Gbps [RFC4328] 945 9 OCh at 100 Gbps [this document] 946 10 ODU0 (i.e., 1.25 Gbps) [this document] 947 11 ODU2e (i.e., 10Gbps for FC1200 [this document] 948 and GE LAN) 949 12~19 Reserved (for future use) [this document] 950 20 ODUflex(CBR) (i.e., 1.25*N Gbps) [this document] 951 21 ODUflex(GFP-F), resizable [this document] 952 (i.e., 1.25*N Gbps) 953 22 ODUflex(GFP-F), non resizable [this document] 954 (i.e., 1.25*N Gbps) 955 23~255 Reserved (for future use) [this document] 957 11. References 959 11.1. Normative References 961 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 962 Requirement Levels", BCP 14, RFC 2119, March 1997. 964 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 965 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 966 Functional Specification", RFC 2205, September 1997. 968 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 969 Services", RFC 2210, September 1997. 971 [RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 972 Tunnels", RFC3209, December 2001. 974 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 975 Switching (GMPLS) Signaling Functional Description", RFC 976 3471, January 2003. 978 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label Switching 979 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 980 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 982 [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label 983 Switching (GMPLS) Signaling Extensions for G.709 Optical 984 Transport Networks Control", RFC 4328, Jan 2006. 986 [RFC6344] G. Bernstein et al, "Operating Virtual Concatenation (VCAT) 987 and the Link Capacity Adjustment Scheme (LCAS) with 988 Generalized Multi-Protocol Label Switching (GMPLS)", 989 RFC6344, August 2011. 991 11.2. Informative References 993 [OTN-FWK] Fatai Zhang et al, "Framework for GMPLS and PCE Control of 994 G.709 Optical Transport Networks", Work in Progress: draft- 995 ietf-ccamp-gmpls-g709-framework, February 2013. 997 [OTN-INFO] S. Belotti et al, "Information model for G.709 Optical 998 Transport Networks (OTN)", Work in Progress: draft-ietf- 999 ccamp-otn-g709-info-model, May 2013. 1001 [OTN-OSPF] D. Ceccarelli et al, "Traffic Engineering Extensions to 1002 OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 1003 OTN Networks", Work in Progress: draft-ietf-ccamp-gmpls- 1004 ospf-g709v3, April 2013. 1006 [G709-2012] ITU-T, "Interfaces for the Optical Transport Network 1007 (OTN)", G.709/Y.1331 Recommendation, February 2012. 1009 [G7044] ITU-T, "Hitless adjustment of ODUflex", G.7044/Y.1347, 1010 October 2011. 1012 [G7041] ITU-T, "Generic framing procedure", G.7041/Y.1303, April 1013 2011. 1015 [RFC4506] M. Eisler, Ed., "XDR: External Data Representation 1016 Standard", RFC 4506, May 2006. 1018 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1019 Networks", RFC5920, July 2010. 1021 [IEEE] "IEEE Standard for Binary Floating-Point Arithmetic", 1022 ANSI/IEEE Standard 754-1985, Institute of Electrical and 1023 Electronics Engineers, August 1985. 1025 12. Contributors 1027 Jonathan Sadler, Tellabs 1028 Email: jonathan.sadler@tellabs.com 1029 Kam LAM, Alcatel-Lucent 1030 Email: kam.lam@alcatel-lucent.com 1032 Xiaobing Zi, Huawei Technologies 1033 Email: zixiaobing@huawei.com 1035 Francesco Fondelli, Ericsson 1036 Email: francesco.fondelli@ericsson.com 1038 Lyndon Ong, Ciena 1039 Email: lyong@ciena.com 1041 Biao Lu, infinera 1042 Email: blu@infinera.com 1044 13. Authors' Addresses 1046 Fatai Zhang (editor) 1047 Huawei Technologies 1048 F3-5-B R&D Center, Huawei Base 1049 Bantian, Longgang District 1050 Shenzhen 518129 P.R.China 1051 Phone: +86-755-28972912 1052 Email: zhangfatai@huawei.com 1054 Guoying Zhang 1055 China Academy of Telecommunication Research of MII 1056 11 Yue Tan Nan Jie Beijing, P.R.China 1057 Phone: +86-10-68094272 1058 Email: zhangguoying@mail.ritt.com.cn 1059 Sergio Belotti 1060 Alcatel-Lucent 1061 Optics CTO 1062 Via Trento 30 20059 Vimercate (Milano) Italy 1063 +39 039 6863033 1064 Email: sergio.belotti@alcatel-lucent.it 1066 Daniele Ceccarelli 1067 Ericsson 1068 Via A. Negrone 1/A 1069 Genova - Sestri Ponente 1070 Italy 1071 Email: daniele.ceccarelli@ericsson.com 1073 Khuzema Pithewan 1074 Infinera Corporation 1075 169, Java Drive 1076 Sunnyvale, CA-94089, USA 1077 Email: kpithewan@infinera.com 1079 Yi Lin 1080 Huawei Technologies 1081 F3-5-B R&D Center, Huawei Base 1082 Bantian, Longgang District 1083 Shenzhen 518129 P.R.China 1084 Phone: +86-755-28972914 1085 Email: yi.lin@huawei.com 1087 Yunbin Xu 1088 China Academy of Telecommunication Research of MII 1089 11 Yue Tan Nan Jie Beijing, P.R.China 1090 Phone: +86-10-68094134 1091 Email: xuyunbin@mail.ritt.com.cn 1092 Pietro Grandi 1093 Alcatel-Lucent 1094 Optics CTO 1095 Via Trento 30 20059 Vimercate (Milano) Italy 1096 +39 039 6864930 1097 Email: pietro_vittorio.grandi@alcatel-lucent.it 1099 Diego Caviglia 1100 Ericsson 1101 Via A. Negrone 1/A 1102 Genova - Sestri Ponente 1103 Italy 1104 Email: diego.caviglia@ericsson.com 1106 Rajan Rao 1107 Infinera Corporation 1108 169, Java Drive 1109 Sunnyvale, CA-94089 1110 USA 1111 Email: rrao@infinera.com 1113 John E Drake 1114 Juniper 1115 Email: jdrake@juniper.net 1117 Igor Bryskin 1118 Adva Optical 1119 EMail: IBryskin@advaoptical.com 1121 14. Acknowledgment 1123 The authors would like to thank Lou Berger and Deborah Brungard for 1124 their useful comments to the document. 1126 Intellectual Property 1128 The IETF Trust takes no position regarding the validity or scope of 1129 any Intellectual Property Rights or other rights that might be 1130 claimed to pertain to the implementation or use of the technology 1131 described in any IETF Document or the extent to which any license 1132 under such rights might or might not be available; nor does it 1133 represent that it has made any independent effort to identify any 1134 such rights. 1136 Copies of Intellectual Property disclosures made to the IETF 1137 Secretariat and any assurances of licenses to be made available, or 1138 the result of an attempt made to obtain a general license or 1139 permission for the use of such proprietary rights by implementers or 1140 users of this specification can be obtained from the IETF on-line IPR 1141 repository at http://www.ietf.org/ipr 1143 The IETF invites any interested party to bring to its attention any 1144 copyrights, patents or patent applications, or other proprietary 1145 rights that may cover technology that may be required to implement 1146 any standard or specification contained in an IETF Document. Please 1147 address the information to the IETF at ietf-ipr@ietf.org. 1149 The definitive version of an IETF Document is that published by, or 1150 under the auspices of, the IETF. Versions of IETF Documents that are 1151 published by third parties, including those that are translated into 1152 other languages, should not be considered to be definitive versions 1153 of IETF Documents. The definitive version of these Legal Provisions 1154 is that published by, or under the auspices of, the IETF. Versions of 1155 these Legal Provisions that are published by third parties, including 1156 those that are translated into other languages, should not be 1157 considered to be definitive versions of these Legal Provisions. 1159 For the avoidance of doubt, each Contributor to the IETF Standards 1160 Process licenses each Contribution that he or she makes as part of 1161 the IETF Standards Process to the IETF Trust pursuant to the 1162 provisions of RFC 5378. No language to the contrary, or terms, 1163 conditions or rights that differ from or are inconsistent with the 1164 rights and licenses granted under RFC 5378, shall have any effect and 1165 shall be null and void, whether published or posted by such 1166 Contributor, or included with or in such Contribution. 1168 Disclaimer of Validity 1170 All IETF Documents and the information contained therein are provided 1171 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1172 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1173 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1174 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1175 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1176 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1177 FOR A PARTICULAR PURPOSE. 1179 Copyright Notice 1181 Copyright (c) 2013 IETF Trust and the persons identified as the 1182 document authors. All rights reserved. 1184 This document is subject to BCP 78 and the IETF Trust's Legal 1185 Provisions Relating to IETF Documents 1186 (http://trustee.ietf.org/license-info) in effect on the date of 1187 publication of this document. Please review these documents 1188 carefully, as they describe your rights and restrictions with respect 1189 to this document. Code Components extracted from this document must 1190 include Simplified BSD License text as described in Section 4.e of 1191 the Trust Legal Provisions and are provided without warranty as 1192 described in the Simplified BSD License.