idnits 2.17.1 draft-ietf-ccamp-gmpls-signaling-g709v3-07.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2013) is 4074 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 -- Looks like a reference, but probably isn't: '32' on line 907 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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: August 21, 2013 February 21, 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-07.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 August 21, 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 .............................................. 13 71 6.2.1. Notification on Label Error ........................ 15 72 6.3. Supporting Virtual Concatenation and Multiplication ..... 16 73 6.4. Examples ................................................ 16 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 ................................. 22 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 ODU-2.5G: Transport of Digital Paths (e.g., at 2.5, 10 and 177 40 Gbps) via 2.5Gbps TSG 179 49 CBRa: Asynchronous Constant Bit Rate (CBR) (e.g., 180 mapping of CBR2G5, CBR10G and CBR40G) 182 50 CBRb: Bit synchronous Constant Bit Rate (e.g., mapping 183 of CBR2G5, CBR10G, CBR40G, CBR10G3 and supra- 184 2.488 CBR Gbit/s signal (carried by OPUflex)) 186 32 ATM: Mapping of Asynchronous Transfer Mode (ATM) cell 187 stream (e.g., at 1.25, 2.5, 10 and 40 Gbps) 189 51 BSOT: Non-specific client Bit Stream with Octet Timing 190 (e.g., Mapping of 1.25, 2.5, 10, 40 and 100 Gbps 191 Bit Stream) 193 52 BSNT: Non-specific client Bit Stream without Octet 194 Timing (e.g., Mapping of 1.25, 2.5, 10, 40 and 195 100 Gbps Bit Stream) 197 Note: Values 32, 47, 49 and 50 include mapping of Synchronous Digital 198 Hierarchy (SDH). 200 In the case of ODU multiplexing, the Lower Order ODU (LO ODU) (i.e., 201 the client signal) may be multiplexed into Higher Order ODU (HO ODU) 202 via 1.25G TSG, 2.5G TSG or any one of them (i.e., TSG 203 Auto_Negotiation is enabled). Since the G-PID type "ODUk" defined in 204 [RFC4328] is only used for 2.5Gbps TSG, two new G-PID types are 205 defined as follows: 207 - ODU-1.25G: Transport of Digital Paths at 1.25, 2.5, 10, 40 and 100 208 Gbps via 1.25Gbps TSG 210 - ODU-any: Transport of Digital Paths at 1.25, 2.5, 10, 40 and 100 211 Gbps via 1.25 or 2.5Gbps TSG (i.e., the fallback 212 procedure is enabled and the default value of 1.25Gbps 213 TSG can be fallen back to 2.5Gbps if needed) 215 In addition, some other new G-PID types are defined to support other 216 new client signals described in [G709-2012]: 218 - CBRc: Mapping of constant bit-rate signals with justification 219 into OPUk (k = 0, 1, 2, 3, 4) via Generic Mapping 220 Procedure (GMP) (i.e., mapping of sub-1.238, supra- 221 1.238 to sub-2.488, close-to 9.995, close-to 40.149 222 and close-to 104.134 Gbit/s CBR client signal) 224 - 1000BASE-X: Mapping of a 1000BASE-X signal via timing transparent 225 transcoding into OPU0 227 - FC-1200: Mapping of a FC-1200 signal via timing transparent 228 transcoding into OPU2e 230 The following table summarizes the new G-PID values with respect to 231 the LSP Encoding Type: 233 Value G-PID Type LSP Encoding Type 234 ----- ---------- ----------------- 235 59(TBA) G.709 ODU-1.25G G.709 ODUk 236 60(TBA) G.709 ODU-any G.709 ODUk 237 61(TBA) CBRc G.709 ODUk 238 62(TBA) 1000BASE-X G.709 ODUk (k=0) 239 63(TBA) FC-1200 G.709 ODUk (k=2e) 241 Note: Values 59 and 60 include mapping of SDH. 243 5. Extensions for Traffic Parameters for the Evolving G.709 245 The Traffic Parameters for OTN-TDM capable Switching Type are carried 246 in the OTN-TDM SENDER_TSPEC and FLOWSPEC objects. The objects have 247 the following class and type: 249 - OTN-TDM SENDER_TSPEC Object: Class = 12, C-Type = 7 (TBA) 250 - OTN-TDM FLOWSPEC Object: Class = 9, C-Type = 7 (TBA) 252 The format of Traffic Parameters in these two objects is defined as 253 follows: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Signal Type | Reserved | Tolerance | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | NVC | Multiplier (MT) | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Bit_Rate | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Signal Type: 8 bits 266 As defined in [RFC4328] Section 3.2.1, with the following 267 additional values: 269 Value Type 270 ----- ---- 271 4 ODU4 (i.e., 100 Gbps) 272 9 OCh at 100 Gbps 273 10 ODU0 (i.e., 1.25 Gbps) 274 11 ODU2e (i.e., 10Gbps for FC1200 and GE LAN) 275 12~19 Reserved (for future use) 276 20 ODUflex(CBR) (i.e., 1.25*N Gbps) 277 21 ODUflex(Generic Framing Procedure-Framed (GFP-F)), 278 resizable (i.e., 1.25*N Gbps) 279 22 ODUflex(GFP-F), non resizable (i.e., 1.25*N Gbps) 280 23~255 Reserved (for future use) 282 NVC: 16 bits 284 As defined in [RFC4328] Section 3.2.3. 286 Multiplier (MT): 16 bits 288 As defined in [RFC4328] Section 3.2.4. 290 Bit_Rate: 32 bits 292 In case of ODUflex including ODUflex(CBR) and ODUflex(GFP) signal 293 types, this field indicates the nominal bit rate of ODUflex 294 expressed in bytes per second, encoded as a 32-bit IEEE single- 295 precision floating-point number (referring to [RFC4506] and 296 [IEEE]). For other signal types, this field is not necessary and 297 MUST be set to 0. 299 Tolerance: 16 bits 301 In case of ODUflex(CBR) signal type, this field indicates the bit 302 rate tolerance (part per million, ppm) of the ODUflex(CBR) 303 encoded as an unsigned integer. The ODUflex(CBR) bit rate 304 tolerance is always specified as 100 ppm per Table 7-2 of [G709- 305 2012], so it MUST be set to 100ppm. For other signal types, this 306 field is not necessary and MUST be set to 0. 308 5.1. Usage of ODUflex(CBR) Traffic Parameters 310 In case of ODUflex(CBR), the information of Bit_Rate and Tolerance in 311 the ODUflex Traffic Parameters MUST be used to determine the actual 312 bandwidth of ODUflex(CBR) (i.e., Bit_Rate * (1 +/- Tolerance)). 313 Therefore the total number of tributary slots N in the HO ODUk link 314 can be reserved correctly. Here: 316 N = Ceiling of 318 ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance) 319 --------------------------------------------------------------------- 320 ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) 322 In this formula, the ODUflex(CBR) nominal bit rate is the bit rate of 323 the ODUflex(CBR) on the line side, i.e., the client signal bit rate 324 after applying the 239/238 factor (according to Clause 7.3, Table 7-2 325 of [G709-2012]) and the transcoding factor T (if needed) on the CBR 326 client. According to clauses 17.7.3, 17.7.4 and 17.7.5 of [G709- 327 2012]: 329 ODUflex(CBR) nominal bit rate = CBR client bit rate * (239/238) / T 331 The ODTUk.ts (Optical channel Data Tributary Unit k with ts tributary 332 slots) nominal bit rate is the nominal bit rate of the tributary slot 333 of ODUk, as shown in Table 1 (referring to Table 7-7 of [G709-2012]). 335 Table 1 - Actual TS bit rate of ODUk (in Kbps) 337 ODUk.ts Minimum Nominal Maximum 338 ----------------------------------------------------------- 339 ODU2.ts 1,249,384.632 1,249,409.620 1,249,434.608 340 ODU3.ts 1,254,678.635 1,254,703.729 1,254,728.823 341 ODU4.ts 1,301,683.217 1,301,709.251 1,301,735.285 343 Note that: 345 Minimum bit rate of ODUTk.ts = 346 ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) 348 Maximum bit rate of ODTUk.ts = 349 ODTUk.ts nominal bit rate * (1 + HO OPUk bit rate tolerance) 351 Where: HO OPUk bit rate tolerance = 20ppm 353 Therefore, a node receiving a PATH message containing ODUflex(CBR) 354 nominal bit rate and tolerance can allocate precise number of 355 tributary slots and set up the cross-connection for the ODUflex 356 service. 358 Note that for different ODUk, the bit rates of the tributary slots 359 are different, and so the total number of tributary slots to be 360 reserved for the ODUflex(CBR) MAY not be the same on different HO 361 ODUk links. 363 An example is given below to illustrate the usage of ODUflex(CBR) 364 Traffic Parameters. 366 As shown in Figure 1, assume there is an ODUflex(CBR) service 367 requesting a bandwidth of (2.5Gbps, +/-100ppm) from node A to node C. 368 In other words, the ODUflex Traffic Parameters indicate that Signal 369 Type is 20 (ODUflex(CBR)), Bit_Rate is 2.5Gbps and Tolerance is 370 100ppm. 372 +-----+ +---------+ +-----+ 373 | +-------------+ +-----+ +-------------+ | 374 | +=============+\| ODU |/+=============+ | 375 | +=============+/| flex+-+=============+ | 376 | +-------------+ | |\+=============+ | 377 | +-------------+ +-----+ +-------------+ | 378 | | | | | | 379 | | ....... | | ....... | | 380 | A +-------------+ B +-------------+ C | 381 +-----+ HO ODU4 +---------+ HO ODU2 +-----+ 383 =========: TS occupied by ODUflex 384 ---------: free TS 386 Figure 1 - Example of ODUflex(CBR) Traffic Parameters 388 - On the HO ODU4 link between node A and B: 390 The maximum bit rate of the ODUflex(CBR) equals 2.5Gbps * (1 + 391 100ppm), and the minimum bit rate of the tributary slot of ODU4 392 equals 1,301,683.217 Kbps, so the total number of tributary slots 393 N1 to be reserved on this link is: 395 N1 = ceiling (2.5Gbps * (1 + 100ppm) / 1,301,683.217 Kbps) = 2 397 - On the HO ODU2 link between node B and C: 399 The maximum bit rate of the ODUflex equals 2.5Gbps * (1 + 400 100ppm), and the minimum bit rate of the tributary slot of ODU2 401 equals 1,249,384.632 Kbps, so the total number of tributary slots 402 N2 to be reserved on this link is: 404 N2 = ceiling (2.5Gbps * (1 + 100ppm) / 1,249,384.632 Kbps) = 3 406 5.2. Usage of ODUflex(GFP) Traffic Parameters 408 [G709-2012] recommends that the ODUflex(GFP) will fill an integral 409 number of tributary slots of the smallest HO ODUk path over which the 410 ODUflex(GFP) may be carried, as shown in Table 2. 412 Table 2 - Recommended ODUflex(GFP) bit rates and tolerance 414 ODU type | Nominal bit-rate | Tolerance 415 --------------------------------+------------------+----------- 416 ODUflex(GFP) of n TS, 1<=n<=8 | n * ODU2.ts | +/-100 ppm 417 ODUflex(GFP) of n TS, 9<=n<=32 | n * ODU3.ts | +/-100 ppm 418 ODUflex(GFP) of n TS, 33<=n<=80 | n * ODU4.ts | +/-100 ppm 420 According to this table, the Bit_Rate field for ODUflex(GFP) MUST 421 equal to one of the 80 values listed below: 423 1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts; 424 9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts; 425 33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts. 427 In this way, the number of required tributary slots for the 428 ODUflex(GFP) (i.e., the value of "n" in Table 2) can be deduced from 429 the Bit_Rate field. 431 5.3. Notification on Errors of OTN-TDM Traffic Parameters 433 There is no Adspec associated with the OTN-TDM SENDER_TSPEC. Either 434 the Adspec is omitted or an Int-serv Adspec with the Default General 435 Characterization Parameters and Guaranteed Service fragment is used, 436 see [RFC2210]. 438 For a particular sender in a session, the contents of the FLOWSPEC 439 object received in a Resv message SHOULD be identical to the contents 440 of the SENDER_TSPEC object received in the corresponding Path 441 message. If the objects do not match, a ResvErr message with a 442 "Traffic Control Error/Bad Flowspec value" error SHOULD be generated. 444 Intermediate and egress nodes MUST verify that the node itself, and 445 the interfaces on which the LSP will be established, can support the 446 requested Signal Type, NVC, Tolerance and Bit_Rate values. If the 447 requested value(s) cannot be supported, the receiver node MUST 448 generate a PathErr message with a "Traffic Control Error/Service 449 unsupported" indication (see [RFC2205]). 451 In addition, if the MT field is received with a zero value, the node 452 MUST generate a PathErr message with a "Traffic Control Error/Bad 453 Tspec value" indication (see [RFC2205]). 455 Further, if the Signal Type is not ODU1, ODU2 or ODU3, and the NVC 456 field is not 0, the node MUST generate a PathErr message with a 457 "Traffic Control Error/Bad Tspec value" indication (see [RFC2205]). 459 6. Generalized Label 461 This section defines the format of the OTN-TDM Generalized Label. 463 6.1. OTN-TDM Switching Type Generalized Label 465 The following is the Generalized Label format for that MUST be used 466 with the OTN-TDM Switching Type: 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | TPN | Reserved | Length | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 ~ Bit Map ...... ~ 474 ~ ...... | Padding Bits ~ 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 The OTN-TDM Generalized Label is used to indicate how the LO ODUj 478 signal is multiplexed into the HO ODUk link. Note that the LO OUDj 479 signal type is indicated by Traffic Parameters, while the type of HO 480 ODUk link is identified by the selected interface carried in the 481 IF_ID RSVP_HOP Object. 483 TPN (12 bits): indicates the TPN for the assigned Tributary Slot(s). 485 - In case of LO ODUj multiplexed into HO ODU1/ODU2/ODU3, only the 486 lower 6 bits of TPN field are significant and the other bits of 487 TPN MUST be set to 0. 489 - In case of LO ODUj multiplexed into HO ODU4, only the lower 7 490 bits of TPN field are significant and the other bits of TPN 491 MUST be set to 0. 493 - In case of ODUj mapped into OTUk (j=k), the TPN is not needed 494 and this field MUST be set to 0. 496 Per [G709-2012], The TPN is used to allow for correct demultiplexing 497 in the data plane. When an LO ODUj is multiplexed into HO ODUk 498 occupying one or more TSs, a new TPN value is configured at the two 499 ends of the HO ODUk link and is put into the related MSI byte(s) in 500 the OPUk overhead at the (traffic) ingress end of the link, so that 501 the other end of the link can learn which TS(s) is/are used by the LO 502 ODUj in the data plane. 504 According to [G709-2012], the TPN field MUST be set as according to 505 the following tables: 507 Table 3 - TPN Assignment Rules (2.5Gbps TS granularity) 508 +-------+-------+----+----------------------------------------------+ 509 |HO ODUk|LO ODUj|TPN | TPN Assignment Rules | 510 +-------+-------+----+----------------------------------------------+ 511 | ODU2 | ODU1 |1~4 |Fixed, = TS# occupied by ODU1 | 512 +-------+-------+----+----------------------------------------------+ 513 | | ODU1 |1~16|Fixed, = TS# occupied by ODU1 | 514 | ODU3 +-------+----+----------------------------------------------+ 515 | | ODU2 |1~4 |Flexible, != other existing LO ODU2s' TPNs | 516 +-------+-------+----+----------------------------------------------+ 518 Table 4 - TPN Assignment Rules (1.25Gbps TS granularity) 519 +-------+-------+----+----------------------------------------------+ 520 |HO ODUk|LO ODUj|TPN | TPN Assignment Rules | 521 +-------+-------+----+----------------------------------------------+ 522 | ODU1 | ODU0 |1~2 |Fixed, = TS# occupied by ODU0 | 523 +-------+-------+----+----------------------------------------------+ 524 | | ODU1 |1~4 |Flexible, != other existing LO ODU1s' TPNs | 525 | ODU2 +-------+----+----------------------------------------------+ 526 | |ODU0 & |1~8 |Flexible, != other existing LO ODU0s and | 527 | |ODUflex| |ODUflexes' TPNs | 528 +-------+-------+----+----------------------------------------------+ 529 | | ODU1 |1~16|Flexible, != other existing LO ODU1s' TPNs | 530 | +-------+----+----------------------------------------------+ 531 | | ODU2 |1~4 |Flexible, != other existing LO ODU2s' TPNs | 532 | ODU3 +-------+----+----------------------------------------------+ 533 | |ODU0 & | |Flexible, != other existing LO ODU0s and | 534 | |ODU2e &|1~32|ODU2es and ODUflexes' TPNs | 535 | |ODUflex| | | 536 +-------+-------+----+----------------------------------------------+ 537 | ODU4 |Any ODU|1~80|Flexible, != ANY other existing LO ODUs' TPNs | 538 +-------+-------+----+----------------------------------------------+ 539 Note that in the case of "Flexible", the value of TPN MAY not be 540 corresponding to the TS number as per [G709-2012]. 542 Length (12 bits): indicates the number of bits of the Bit Map field, 543 i.e., the total number of TS in the HO ODUk link. The valid values 544 for this field are 0, 2, 4, 8, 16, 32 and 80. 546 In case of an ODUk mapped into OTUk, there is no need to indicate 547 which tributary slots will be used, so the length field MUST be set 548 to 0. 550 Bit Map (variable): indicates which tributary slots in HO ODUk that 551 the LO ODUj will be multiplexed into. The sequence of the Bit Map is 552 consistent with the sequence of the tributary slots in HO ODUk. Each 553 bit in the bit map represents the corresponding tributary slot in HO 554 ODUk with a value of 1 or 0 indicating whether the tributary slot 555 will be used by LO ODUj or not. 557 Padding bits are added after the Bit Map to make the whole label a 558 multiple of four bytes if necessary. Padding bits MUST be set to 0 559 and MUST be ignored. 561 6.2. Procedures 563 The ingress node MUST generate a Path message and specify the OTN-TDM 564 Switching Type and corresponding G-PID in the Generalized Label 565 Request object, which MUST be processed as defined in [RFC3473]. 567 The ingress node of an LSP MAY include label ERO (Explicit Route 568 Object) to indicate the label in each hops along the path. Note that 569 the TPN in the label ERO subobject MAY not be assigned by the ingress 570 node. In this case, the node MUST assign a valid TPN value and then 571 put this value into TPN field of the label object when receiving a 572 Path message. 574 In order to create bidirectional LSP, the ingress node and upstream 575 node MUST generate an Upstream Label on the out outgoing interface to 576 indicate the reserved TSs of ODUk and the assigned TPN value in the 577 upstream direction. This Upstream Label is sent to the downstream 578 node via Path massage for upstream resource reservation. 580 The ingress node or upstream node MAY generate Label Set to indicate 581 which labels on the outgoing interface in the downstream direction 582 are acceptable. The downstream node will restrict its choice of 583 labels, i.e., TS resource and TPN value, to one which is in the Label 584 Set. 586 The ingress node or upstream node MAY also generate Suggested Label 587 to indicate the preference of TS resource and TPN value on the 588 outgoing interface in the downstream direction. The downstream node 589 is not REQUIRED to use the Suggested Label and MAY use another label 590 based on local decision and send it to the upstream node, as 591 described in [RFC3473]. 593 When an upstream node receives a Resv message containing an LABEL 594 object with an OTN-TDM label, it MUST firstly identify which ODU 595 signal type is multiplexed or mapped into which ODU signal type 596 accordingly to the Traffic Parameters and the IF_ID RSVP_HOP Object 597 in the received message. 599 - In case of ODUj to ODUk multiplexing, the node MUST retrieve the 600 reserved tributary slots in the ODUk by its downstream neighbor 601 node according to the position of the bits that are set to 1 in 602 the Bit Map field. The node determines the TS type (according to 603 the total TS number of the ODUk, or pre-configured TS type), so 604 that the node can multiplex the ODUj into the ODUk based on the TS 605 type. The node MUST also retrieve the TPN value assigned by its 606 downstream neighbor node from the label, and fill the TPN into the 607 related MSI byte(s) in the OPUk overhead in the data plane, so 608 that the downstream neighbor node can check whether the TPN 609 received from the data plane is consistent with the ExMSI and 610 determine whether there is any mismatch defect. Note that the 611 Length field in the label format MAY be used to indicate the TS 612 type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps) 613 since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In 614 some cases when there is no Link Management Protocol (LMP) or 615 routing to make the two end points of the link to know the TSG, 616 the TSG information used by another end can be deduced from the 617 label format. For example, for HO ODU2 link, the value of the 618 length filed will be 4 or 8, which indicates the TS granularity is 619 2.5Gbps or 1.25Gbps, respectively. 621 - In case of ODUk to OTUk mapping, the size of Bit Map field MUST be 622 0 and no additional procedure is needed. 624 When a downstream node or egress node receives a Path message 625 containing Generalized Label Request object for setting up an ODUj 626 LSP from its upstream neighbor node, the node MUST generate an OTN- 627 TDM label according to the signal type of the requested LSP and the 628 free resources (i.e., free tributary slots of ODUk) that will be 629 reserved for the LSP, and send the label to its upstream neighbor 630 node. 632 - In case of ODUj to ODUk multiplexing, the node MUST firstly 633 determine the size of the Bit Map field according to the signal 634 type and the tributary slot type of ODUk, and then set the bits to 635 1 in the Bit Map field corresponding to the reserved tributary 636 slots. The node MUST also assign a valid TPN, which MUST NOT 637 collide with other TPN value used by existing LO ODU connections 638 in the selected HO ODU link, and configure the Expected MSI 639 (ExMSI) using this TPN. Then, the assigned TPN MUST be filled into 640 the label. 642 - In case of ODUk to OTUk mapping, TPN field MUST be set to 0. Bit 643 Map information is not REQUIRED and MUST NOT be included, so 644 Length field MUST be set to 0 as well. 646 6.2.1. Notification on Label Error 648 When an upstream node receives a Resv message containing an LABEL 649 object with an OTN-TDM label, the node MUST verify if the label is 650 acceptable. If the label is not acceptable, the node MUST generate a 651 ResvErr message with a "Routing problem/Unacceptable label value" 652 indication. Per [RFC3473], the generated ResvErr message MAY include 653 an ACCEPTABLE_LABEL_SET object. With the exception of label 654 semantics, downstream node processing a received ResvErr messages and 655 of ACCEPTABLE_LABEL_SET objects is not modified by this document. 657 Similarly, when a downstream node receives a Path message containing 658 an UPSTREAM_LABEL object with an OTN-TDM label, the node MUST verify 659 if the label is acceptable. If the label is not acceptable, the node 660 MUST generate a PathErr message with a "Routing problem/Unacceptable 661 label value" indication. Per [RFC3473], the generated ResvErr message 662 MAY include an ACCEPTABLE_LABEL_SET object. With the exception of 663 label semantics, downstream node processing received PathErr messages 664 and of ACCEPTABLE_LABEL_SET objects is not modified by this document. 666 A received label SHALL be considered unacceptable when one of the 667 following cases occurs: 669 - The received label doesn't conform to local policy; 671 - Invalid value in the length field; 673 - The selected link only supports 2.5Gbps TS granularity while the 674 Length field in the label along with ODUk signal type indicates 675 the 1.25Gbps TS granularity; 677 - The label includes an invalid TPN value that breaks the TPN 678 assignment rules; 680 - The indicated resources (i.e., the number of "1" in the Bit Map 681 field) are inconsistent with the Traffic Parameters. 683 6.3. Supporting Virtual Concatenation and Multiplication 685 Per [RFC6344], the Virtual Concatenation Groups (VCGs) can be created 686 using Co-Signaled style or Multiple LSPs style. 688 In case of Co-Signaled style, the explicit ordered list of all labels 689 MUST reflect the order of VCG members, which is similar to [RFC4328]. 690 In case of multiplexed virtually concatenated signals (NVC > 1), the 691 first label MUST indicate the components of the first virtually 692 concatenated signal; the second label MUST indicate the components of 693 the second virtually concatenated signal; and so on. In case of 694 multiplication of multiplexed virtually concatenated signals (MT > 695 1), the first label MUST indicate the components of the first 696 multiplexed virtually concatenated signal; the second label MUST 697 indicate components of the second multiplexed virtually concatenated 698 signal; and so on. 700 Support for Virtual Concatenation of ODU1, ODU2 and ODU3 signal 701 types, as defined by [RFC6344], is not modified by this document. 702 Virtual Concatenation of other signal types is not supported by 703 [G709-2012]. 705 Multiplier (MT) usage is as defined in [RFC6344] and [RFC4328]. 707 6.4. Examples 709 The following examples are given in order to illustrate the label 710 format described in Section 6.1 of this document. 712 (1) ODUk into OTUk mapping: 714 In such conditions, the downstream node along an LSP returns a label 715 indicating that the ODUk (k=1, 2, 3, 4) is directly mapped into the 716 corresponding OTUk. The following example label indicates an ODU1 717 mapped into OTU1. 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | TPN = 0 | Reserved | Length = 0 | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 (2) ODUj into ODUk multiplexing: 727 In such conditions, this label indicates that an ODUj is multiplexed 728 into several tributary slots of OPUk and then mapped into OTUk. Some 729 instances are shown as follow: 731 - ODU0 into ODU2 Multiplexing: 733 0 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | TPN = 2 | Reserved | Length = 8 | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 |0 1 0 0 0 0 0 0| Padding Bits (0) | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 This above label indicates an ODU0 multiplexed into the second 742 tributary slot of ODU2, wherein there are 8 TS in ODU2 (i.e., the 743 type of the tributary slot is 1.25Gbps), and the TPN value is 2. 745 - ODU1 into ODU2 Multiplexing with 1.25Gbps TS granularity: 747 0 1 2 3 748 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 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | TPN = 1 | Reserved | Length = 8 | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 |0 1 0 1 0 0 0 0| Padding Bits (0) | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 This above label indicates an ODU1 multiplexed into the 2nd and the 756 4th tributary slot of ODU2, wherein there are 8 TS in ODU2 (i.e., the 757 type of the tributary slot is 1.25Gbps), and the TPN value is 1. 759 - ODU2 into ODU3 Multiplexing with 2.5Gbps TS granularity: 761 0 1 2 3 762 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 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | TPN = 1 | Reserved | Length = 16 | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 |0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0| Padding Bits (0) | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 This above label indicates an ODU2 multiplexed into the 2nd, 3rd, 5th 770 and 7th tributary slot of ODU3, wherein there are 16 TS in ODU3 771 (i.e., the type of the tributary slot is 2.5Gbps), and the TPN value 772 is 1. 774 7. Supporting Hitless Adjustment of ODUflex (GFP) 776 [G7044] describes the procedure of ODUflex (GFP) hitless resizing 777 using Link Connection Resize (LCR) and Bandwidth Resize (BWR) 778 protocols in OTN data plane. 780 For the control plane, signaling messages are REQUIRED to initiate 781 the adjustment procedure. Section 2.5 and Section 4.6.4 of [RFC3209] 782 describe how the Shared Explicit (SE) style is used in Traffic 783 Engineering (TE) network for bandwidth increasing and decreasing, 784 which is still applicable for triggering the ODUflex (GFP) adjustment 785 procedure in data plane. 787 Note that the SE style MUST be used at the beginning when creating a 788 resizable ODUflex connection (Signal Type = 21). Otherwise an error 789 with Error Code "Conflicting reservation style" MUST be generated 790 when performing bandwidth adjustment. 792 - Bandwidth increasing 794 For the ingress node, in order to increase the bandwidth of an 795 ODUflex (GFP) connection, a Path message with SE style (keeping 796 Tunnel ID unchanged and assigning a new LSP ID) MUST be sent 797 along the path. 799 The ingress node will trigger the BWR protocol when successful 800 completion of LCR protocols on every hop after Resv message is 801 processed. On success of BWR, the ingress node SHOULD send a 802 PathTear message to delete the old control state (i.e., the 803 control state of the ODUflex (GFP) before resizing) on the 804 control plane. 806 A downstream node receiving Path message with SE style compares 807 the old Traffic Parameters (stored locally) with the new one 808 carried in the Path message, to determine the number of TS to be 809 added. After choosing and reserving new free TS, the downstream 810 node MUST send back a Resv message carrying both the old and new 811 LABEL Objects in the SE flow descriptor. 813 An upstream neighbor receiving Resv message with SE flow 814 descriptor MUST determine which TS are added and trigger the LCR 815 protocol between itself and its downstream neighbor node. 817 - Bandwidth decreasing 819 For the ingress node, a Path message with SE style SHOULD also be 820 sent for ODUflex bandwidth decreasing. 822 The ingress node will trigger the BWR protocol when successful 823 completion of LCR handshake on every hop after Resv message is 824 processed. On success of BWR, the second step of LCR, i.e., link 825 connection decrease procedure will be started on every hop of the 826 connection. After completion of bandwidth decreasing, the ingress 827 node SHOULD send a ResvErr message to tear down the old control 828 state. 830 A downstream node receiving Path message with SE style compares 831 the old Traffic Parameters with the new one carried in the Path 832 message to determine the number of TS to be decreased. After 833 choosing TSs to be decreased, the downstream node MUST send back 834 a Resv message carrying both the old and new LABEL Objects in the 835 SE flow descriptor. 837 An upstream neighbor receiving Resv message with SE flow 838 descriptor MUST determine which TS are decreased and trigger the 839 first step of LCR protocol (i.e., LCR handshake) between itself 840 and its downstream neighbor node. 842 8. Control Plane Backward Compatibility Considerations 844 As described in [OTN-FWK], since the [RFC4328] has been deployed in 845 the network for the nodes that support the 2001 revision of the G.709 846 specification, control plane backward compatibility SHOULD be taken 847 into consideration. More specifically: 849 o Nodes supporting this document SHOULD support [OTN-OSPF]. 851 o Nodes supporting this document MAY support [RFC4328] signaling. 853 o A node supporting both sets of procedures (i.e., [RFC4328] and 854 this document) is not REQUIRED to signal an LSP using both 855 procedures, i.e., to act as a signaling version translator. 857 o Ingress nodes that support both sets of procedures MAY select 858 which set of procedures to follow based on routing information or 859 local policy. 861 o Per [RFC3473], nodes that do not support this document will 862 generate a PathErr message, with a "Routing problem/Switching 863 Type" indication. 865 9. Security Considerations 867 This document introduces no new security considerations to the 868 existing GMPLS signaling protocols. Referring to [RFC3473] and 869 [RFC4328], further details of the specific security measures are 870 provided. Additionally, [RFC5920] provides an overview of security 871 vulnerabilities and protection mechanisms for the GMPLS control 872 plane. 874 10. IANA Considerations 876 Three RSVP C-Types are defined for OTN-TDM Traffic Parameters and 877 OTN-TDM Generalized Label in this document: 878 http://www.iana.org/assignments/rsvp-parameters 880 - OTN-TDM SENDER_TSPEC and FLOWSPEC objects: 882 o OTN-TDM SENDER_TSPEC Object: Class = 12, C-Type = 7 (see 883 Section 5) 885 o OTN-TDM FLOWSPEC Object: Class = 9, C-Type = 7 (see Section 5) 887 - OTN-TDM Generalized Label Object: 889 o OTN-TDM Generalized Label Object: Class = 16, C-Type = 2 (see 890 Section 6.1) 892 IANA maintains the "Generalized Multi-Protocol Label Switching 893 (GMPLS) Signaling Parameters" registry (see 894 http://www.iana.org/assignments/gmpls-sig-parameters). "Generalized 895 PIDs (G-PID)" subregistry is included in this registry, which will be 896 extended and updated by this document as below: 898 - Generalized PID (G-PID): 900 Name: G-PID 902 Format: 16-bit number 904 Values: 906 [0..31, 36..46] defined in [RFC3471] 907 [32] defined in [RFC3471] and updated by Section 4 908 [33..35] defined in [RFC3471] and updated by [RFC4328] 909 [47, 49..52] defined in [RFC4328] and updated by Section 4 911 [48, 53..58] defined in [RFC4328] 912 [59..63] defined in Section 4 of this document 914 Allocation Policy (as defined in [RFC4328]): 916 [0..31743] Assigned by IANA via IETF Standards Track RFC 917 Action. 918 [31744..32767] Assigned temporarily for Experimental Usage 919 [32768..65535] Not assigned. Before any assignments can be 920 made in this range, there MUST be a Standards 921 Track RFC that specifies IANA Considerations 922 that covers the range being assigned. 924 "Signal Type" subregistry to the "Generalized Multi-Protocol Label 925 Switching (GMPLS) Signaling Parameters" will be defined by this 926 document as below: 928 Value Signal Type Reference 929 ----- ----------- --------- 930 0 Not significant [RFC4328] 931 1 ODU1 (i.e., 2.5 Gbps) [RFC4328] 932 2 ODU2 (i.e., 10 Gbps) [RFC4328] 933 3 ODU3 (i.e., 40 Gbps) [RFC4328] 934 4 ODU4 (i.e., 100 Gbps) [this document] 935 5 Reserved (for future use) [RFC4328] 936 6 Och at 2.5 Gbps [RFC4328] 937 7 OCh at 10 Gbps [RFC4328] 938 8 OCh at 40 Gbps [RFC4328] 939 9 OCh at 100 Gbps [this document] 940 10 ODU0 (i.e., 1.25 Gbps) [this document] 941 11 ODU2e (i.e., 10Gbps for FC1200 [this document] 942 and GE LAN) 943 12~19 Reserved (for future use) [this document] 944 20 ODUflex(CBR) (i.e., 1.25*N Gbps) [this document] 945 21 ODUflex(GFP-F), resizable [this document] 946 (i.e., 1.25*N Gbps) 947 22 ODUflex(GFP-F), non resizable [this document] 948 (i.e., 1.25*N Gbps) 949 23~255 Reserved (for future use) [this document] 951 11. References 953 11.1. Normative References 955 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 956 Requirement Levels", BCP 14, RFC 2119, March 1997. 958 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 959 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 960 Functional Specification", RFC 2205, September 1997. 962 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 963 Services", RFC 2210, September 1997. 965 [RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 966 Tunnels", RFC3209, December 2001. 968 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 969 Switching (GMPLS) Signaling Functional Description", RFC 970 3471, January 2003. 972 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label Switching 973 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 974 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 976 [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label 977 Switching (GMPLS) Signaling Extensions for G.709 Optical 978 Transport Networks Control", RFC 4328, Jan 2006. 980 [RFC6344] G. Bernstein et al, "Operating Virtual Concatenation (VCAT) 981 and the Link Capacity Adjustment Scheme (LCAS) with 982 Generalized Multi-Protocol Label Switching (GMPLS)", 983 RFC6344, August 2011. 985 11.2. Informative References 987 [OTN-FWK] Fatai Zhang et al, "Framework for GMPLS and PCE Control of 988 G.709 Optical Transport Networks", Work in Progress: draft- 989 ietf-ccamp-gmpls-g709-framework, November 2012. 991 [OTN-INFO] S. Belotti et al, "Information model for G.709 Optical 992 Transport Networks (OTN)", Work in Progress: draft-ietf- 993 ccamp-otn-g709-info-model, January 2013. 995 [OTN-OSPF] D. Ceccarelli et al, "Traffic Engineering Extensions to 996 OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 997 OTN Networks", Work in Progress: draft-ietf-ccamp-gmpls- 998 ospf-g709v3, January 2013. 1000 [G709-2012] ITU-T, "Interfaces for the Optical Transport Network 1001 (OTN)", G.709/Y.1331 Recommendation, February 2012. 1003 [G7044] ITU-T, "Hitless adjustment of ODUflex", G.7044/Y.1347, 1004 October 2011. 1006 [RFC4506] M. Eisler, Ed., "XDR: External Data Representation 1007 Standard", RFC 4506, May 2006. 1009 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1010 Networks", RFC5920, July 2010. 1012 [IEEE] "IEEE Standard for Binary Floating-Point Arithmetic", 1013 ANSI/IEEE Standard 754-1985, Institute of Electrical and 1014 Electronics Engineers, August 1985. 1016 12. Contributors 1018 Jonathan Sadler, Tellabs 1019 Email: jonathan.sadler@tellabs.com 1021 Kam LAM, Alcatel-Lucent 1022 Email: kam.lam@alcatel-lucent.com 1024 Xiaobing Zi, Huawei Technologies 1025 Email: zixiaobing@huawei.com 1027 Francesco Fondelli, Ericsson 1028 Email: francesco.fondelli@ericsson.com 1030 Lyndon Ong, Ciena 1031 Email: lyong@ciena.com 1033 Biao Lu, infinera 1034 Email: blu@infinera.com 1036 13. Authors' Addresses 1038 Fatai Zhang (editor) 1039 Huawei Technologies 1040 F3-5-B R&D Center, Huawei Base 1041 Bantian, Longgang District 1042 Shenzhen 518129 P.R.China 1043 Phone: +86-755-28972912 1044 Email: zhangfatai@huawei.com 1046 Guoying Zhang 1047 China Academy of Telecommunication Research of MII 1048 11 Yue Tan Nan Jie Beijing, P.R.China 1049 Phone: +86-10-68094272 1050 Email: zhangguoying@mail.ritt.com.cn 1052 Sergio Belotti 1053 Alcatel-Lucent 1054 Optics CTO 1055 Via Trento 30 20059 Vimercate (Milano) Italy 1056 +39 039 6863033 1057 Email: sergio.belotti@alcatel-lucent.it 1059 Daniele Ceccarelli 1060 Ericsson 1061 Via A. Negrone 1/A 1062 Genova - Sestri Ponente 1063 Italy 1064 Email: daniele.ceccarelli@ericsson.com 1066 Khuzema Pithewan 1067 Infinera Corporation 1068 169, Java Drive 1069 Sunnyvale, CA-94089, USA 1070 Email: kpithewan@infinera.com 1071 Yi Lin 1072 Huawei Technologies 1073 F3-5-B R&D Center, Huawei Base 1074 Bantian, Longgang District 1075 Shenzhen 518129 P.R.China 1076 Phone: +86-755-28972914 1077 Email: yi.lin@huawei.com 1079 Yunbin Xu 1080 China Academy of Telecommunication Research of MII 1081 11 Yue Tan Nan Jie Beijing, P.R.China 1082 Phone: +86-10-68094134 1083 Email: xuyunbin@mail.ritt.com.cn 1085 Pietro Grandi 1086 Alcatel-Lucent 1087 Optics CTO 1088 Via Trento 30 20059 Vimercate (Milano) Italy 1089 +39 039 6864930 1090 Email: pietro_vittorio.grandi@alcatel-lucent.it 1092 Diego Caviglia 1093 Ericsson 1094 Via A. Negrone 1/A 1095 Genova - Sestri Ponente 1096 Italy 1097 Email: diego.caviglia@ericsson.com 1099 Rajan Rao 1100 Infinera Corporation 1101 169, Java Drive 1102 Sunnyvale, CA-94089 1103 USA 1104 Email: rrao@infinera.com 1105 John E Drake 1106 Juniper 1107 Email: jdrake@juniper.net 1109 Igor Bryskin 1110 Adva Optical 1111 EMail: IBryskin@advaoptical.com 1113 14. Acknowledgment 1115 The authors would like to thank Lou Berger and Deborah Brungard for 1116 their useful comments to the document. 1118 Intellectual Property 1120 The IETF Trust takes no position regarding the validity or scope of 1121 any Intellectual Property Rights or other rights that might be 1122 claimed to pertain to the implementation or use of the technology 1123 described in any IETF Document or the extent to which any license 1124 under such rights might or might not be available; nor does it 1125 represent that it has made any independent effort to identify any 1126 such rights. 1128 Copies of Intellectual Property disclosures made to the IETF 1129 Secretariat and any assurances of licenses to be made available, or 1130 the result of an attempt made to obtain a general license or 1131 permission for the use of such proprietary rights by implementers or 1132 users of this specification can be obtained from the IETF on-line IPR 1133 repository at http://www.ietf.org/ipr 1135 The IETF invites any interested party to bring to its attention any 1136 copyrights, patents or patent applications, or other proprietary 1137 rights that may cover technology that may be required to implement 1138 any standard or specification contained in an IETF Document. Please 1139 address the information to the IETF at ietf-ipr@ietf.org. 1141 The definitive version of an IETF Document is that published by, or 1142 under the auspices of, the IETF. Versions of IETF Documents that are 1143 published by third parties, including those that are translated into 1144 other languages, should not be considered to be definitive versions 1145 of IETF Documents. The definitive version of these Legal Provisions 1146 is that published by, or under the auspices of, the IETF. Versions of 1147 these Legal Provisions that are published by third parties, including 1148 those that are translated into other languages, should not be 1149 considered to be definitive versions of these Legal Provisions. 1151 For the avoidance of doubt, each Contributor to the IETF Standards 1152 Process licenses each Contribution that he or she makes as part of 1153 the IETF Standards Process to the IETF Trust pursuant to the 1154 provisions of RFC 5378. No language to the contrary, or terms, 1155 conditions or rights that differ from or are inconsistent with the 1156 rights and licenses granted under RFC 5378, shall have any effect and 1157 shall be null and void, whether published or posted by such 1158 Contributor, or included with or in such Contribution. 1160 Disclaimer of Validity 1162 All IETF Documents and the information contained therein are provided 1163 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1164 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1165 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1166 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1167 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1168 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1169 FOR A PARTICULAR PURPOSE. 1171 Copyright Notice 1173 Copyright (c) 2013 IETF Trust and the persons identified as the 1174 document authors. All rights reserved. 1176 This document is subject to BCP 78 and the IETF Trust's Legal 1177 Provisions Relating to IETF Documents 1178 (http://trustee.ietf.org/license-info) in effect on the date of 1179 publication of this document. Please review these documents 1180 carefully, as they describe your rights and restrictions with respect 1181 to this document. Code Components extracted from this document must 1182 include Simplified BSD License text as described in Section 4.e of 1183 the Trust Legal Provisions and are provided without warranty as 1184 described in the Simplified BSD License. 1186 This document may contain material from IETF Documents or IETF 1187 Contributions published or made publicly available before November 1188 10, 2008. The person(s) controlling the copyright in some of this 1189 material may not have granted the IETF Trust the right to allow 1190 modifications of such material outside the IETF Standards Process. 1191 Without obtaining an adequate license from the person(s) controlling 1192 the copyright in such materials, this document may not be modified 1193 outside the IETF Standards Process, and derivative works of it may 1194 not be created outside the IETF Standards Process, except to format 1195 it for publication as an RFC or to translate it into languages other 1196 than English.