idnits 2.17.1 draft-ietf-ccamp-gmpls-signaling-g709v3-05.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 (November 30, 2012) is 4163 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 131, but not defined -- Looks like a reference, but probably isn't: '32' on line 849 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: May 30, 2013 November 30, 2012 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-05.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 May 30, 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 6. Generalized Label ............................................ 11 68 6.1. OTN-TDM Switching Type Generalized Label ................ 11 69 6.2. Procedures .............................................. 13 70 6.2.1. Notification on Label Error ........................ 15 71 6.3. Supporting Virtual Concatenation and Multiplication ..... 15 72 6.4. Examples ................................................ 15 73 7. Supporting Hitless Adjustment of ODUflex (GFP) ............... 17 74 8. Control Plane Backward Compatibility Considerations........... 18 75 9. Security Considerations ...................................... 19 76 10. IANA Considerations.......................................... 19 77 11. References .................................................. 20 78 11.1. Normative References ................................... 20 79 11.2. Informative References ................................. 21 80 12. Contributors ................................................ 21 81 13. Authors' Addresses .......................................... 22 82 14. Acknowledgment .............................................. 24 84 1. Introduction 86 With the evolution and deployment of OTN technology, it is necessary 87 that appropriate enhanced control technology support be provided for 88 [G709-2012]. 90 [OTN-FWK] provides a framework to allow the development of protocol 91 extensions to support GMPLS and Path Computation Element (PCE) 92 control of OTN as specified in [G709-2012]. Based on this framework, 93 [OTN-INFO] evaluates the information needed by the routing and 94 signaling process in OTNs to support GMPLS control of OTN. 96 [RFC4328] describes the control technology details that are specific 97 to the 2001 revision of the G.709 specification. This document 98 updates [RFC4328] to provide Resource ReserVation Protocol-Traffic 99 Engineering (RSVP-TE) extensions to support of control for [G709- 100 2012]. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. GMPLS Extensions for the Evolving G.709 - Overview 110 New features for the evolving OTN, for example, new ODU0, ODU2e, ODU4 111 and ODUflex containers are specified in [G709-2012]. The 112 corresponding new signal types are summarized below: 114 - Optical Channel Transport Unit (OTUk): 115 . OTU4 117 - Optical Channel Data Unit (ODUk): 118 . ODU0 119 . ODU2e 120 . ODU4 121 . ODUflex 123 A new Tributary Slot Granularity (TS Granularity, TSG) (i.e., 1.25 124 Gbps) is also described in [G709-2012]. Thus, there are now two TS 125 granularities for the foundation OTN ODU1, ODU2 and ODU3 containers. 127 The TS granularity at 2.5 Gbps is used on legacy interfaces while the 128 new 1.25 Gbps is used on the new interfaces. 130 In addition to the support of ODUk mapping into OTUk (k = 1, 2, 3, 131 4), the evolving OTN [G.709-V3] encompasses the multiplexing of ODUj 132 (j = 0, 1, 2, 2e, 3, flex) into an ODUk (k > j), as described in 133 Section 3.1.2 of [OTN-FWK]. 135 Virtual Concatenation (VCAT) of Optical channel Payload Unit-k (OPUk) 136 (OPUk-Xv, k = 1/2/3, X = 1...256) is also supported by [G709-2012]. 137 Note that VCAT of OPU0 / OPU2e / OPU4 / OPUflex is not supported per 138 [G709-2012]. 140 [RFC4328] describes GMPLS signaling extensions to support the control 141 for the 2001 revision of the G.709 specification. However, [RFC4328] 142 needs to be updated because it does not provide the means to signal 143 all the new signal types and related mapping and multiplexing 144 functionalities. Moreover, it supports only the deprecated auto- 145 Multiframe Structure Identifier (MSI) mode which assumes that the 146 Tributary Port Number (TPN) is automatically assigned in the transmit 147 direction and not checked in the receive direction. 149 This document extends the G.709 traffic parameters described in 150 [RFC4328] and presents a new flexible and scalable OTN label format. 151 Additionally, procedures about Tributary Port Number assignment 152 through control plane are also provided in this document. 154 4. Generalized Label Request 156 The Generalized Label Request, as described in [RFC3471], carries the 157 Label Switched Path (LSP) Encoding Type, the Switching Type and the 158 Generalized Protocol Identifier (G-PID). 160 [RFC4328] extends the Generalized Label Request, introducing two new 161 code-points for the LSP Encoding Type (i.e., G.709 ODUk (Digital 162 Path) and G.709 Optical Channel) and adding a list of G-PID values in 163 order to accommodate the 2001 revision of the G.709 specification. 165 This document follows these extensions and a new Switching Type is 166 introduced to indicate the ODUk switching capability [G709-2012] in 167 order to support backward compatibility with [RFC4328], as described 168 in [OTN-FWK]. The new Switching Type (101, TBA by IANA) is defined in 169 [OTN-OSPF]. 171 This document also updates the G-PID values defined in [RFC4328]: 173 Value G-PID Type 174 ----- ---------- 175 47 ODU-2.5G: transport of Digital Paths (e.g., at 2.5, 10 and 176 40 Gbps) via 2.5Gbps TSG 178 49 CBRa: asynchronous Constant Bit Rate (CBR) (e.g., 179 mapping of CBR2G5, CBR10G and CBR40G) 181 50 CBRb: bit synchronous Constant Bit Rate (e.g., mapping 182 of CBR2G5, CBR10G, CBR40G, CBR10G3 and supra- 183 2.488 CBR Gbit/s signal (carried by OPUflex)) 185 32 ATM: mapping of Asynchronous Transfer Mode (ATM) cell 186 stream (e.g., at 1.25, 2.5, 10 and 40 Gbps) 188 51 BSOT: non-specific client Bit Stream with Octet Timing 189 (e.g., Mapping of 1.25, 2.5, 10, 40 and 100 Gbps 190 Bit Stream) 192 52 BSNT: non-specific client Bit Stream without Octet 193 Timing (e.g., Mapping of 1.25, 2.5, 10, 40 and 194 100 Gbps Bit Stream) 196 Note: Values 32, 47, 49 and 50 include mapping of Synchronous Digital 197 Hierarchy (SDH). 199 In the case of ODU multiplexing, the Lower Order ODU (LO ODU) (i.e., 200 the client signal) may be multiplexed into Higher Order ODU (HO ODU) 201 via 1.25G TSG, 2.5G TSG or any one of them (i.e., TSG 202 Auto_Negotiation is enabled). Since the G-PID type "ODUk" defined in 203 [RFC4328] is only used for 2.5Gbps TSG, two new G-PID types are 204 defined as follows: 206 - ODU-1.25G: transport of Digital Paths at 1.25, 2.5, 10, 40 and 100 207 Gbps via 1.25Gbps TSG 209 - ODU-any: transport of Digital Paths at 1.25, 2.5, 10, 40 and 100 210 Gbps via 1.25 or 2.5Gbps TSG (i.e., the fallback 211 procedure is enabled and the default value of 1.25Gbps 212 TSG can be fallen back to 2.5Gbps if needed) 214 In addition, some other new G-PID types are defined to support other 215 new client signals described in [G709-2012]: 217 - CBRc: Mapping of constant bit-rate signals with justification 218 into OPUk (k = 0, 1, 2, 3, 4) via Generic Mapping 219 Procedure (GMP) (i.e., mapping of sub-1.238, supra- 220 1.238 to sub-2.488, close-to 9.995, close-to 40.149 221 and close-to 104.134 Gbit/s CBR client signal) 223 - 1000BASE-X: Mapping of a 1000BASE-X signal via timing transparent 224 transcoding into OPU0 226 - FC-1200: Mapping of a FC-1200 signal via timing transparent 227 transcoding into OPU2e 229 The following table summarizes the new G-PID values with respect to 230 the LSP Encoding Type: 232 Value G-PID Type LSP Encoding Type 233 ----- ---------- ----------------- 234 59(TBA) G.709 ODU-1.25G G.709 ODUk 235 60(TBA) G.709 ODU-any G.709 ODUk 236 61(TBA) CBRc G.709 ODUk 237 62(TBA) 1000BASE-X G.709 ODUk (k=0) 238 63(TBA) FC-1200 G.709 ODUk (k=2e) 240 Note: Values 59 and 60 include mapping of SDH. 242 5. Extensions for Traffic Parameters for the Evolving G.709 244 The traffic parameters for OTN-TDM capable Switching Type are carried 245 in the OTN-TDM SENDER_TSPEC and FLOWSPEC objects. The objects have 246 the following class and type: 248 - OTN-TDM SENDER_TSPEC Object: Class = 12, C-Type = 7 (TBA) 249 - OTN-TDM FLOWSPEC Object: Class = 9, C-Type = 7 (TBA) 251 The format of traffic parameters in these two objects are defined as 252 follows: 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Signal Type | Reserved | Tolerance | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | NVC | Multiplier (MT) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Bit_Rate | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 The valid Signal Type values defined in [RFC4328] are updated to be: 266 Value Type 267 ----- ---- 268 0 Not significant 269 1 ODU1 (i.e., 2.5 Gbps) 270 2 ODU2 (i.e., 10 Gbps) 271 3 ODU3 (i.e., 40 Gbps) 272 4 ODU4 (i.e., 100 Gbps) 273 5 Reserved (for future use) 274 6 Optical Channel (Och) at 2.5 Gbps 275 7 OCh at 10 Gbps 276 8 OCh at 40 Gbps 277 9 OCh at 100 Gbps 278 10 ODU0 (i.e., 1.25 Gbps) 279 11 ODU2e (i.e., 10Gbps for FC1200 and GE LAN) 280 12~19 Reserved (for future use) 281 20 ODUflex(CBR) (i.e., 1.25*N Gbps) 282 21 ODUflex(Generic Framing Procedure-Framed (GFP-F)), 283 resizable (i.e., 1.25*N Gbps) 284 22 ODUflex(GFP-F), non resizable (i.e., 1.25*N Gbps) 285 23~255 Reserved (for future use) 287 In case of ODUflex(CBR), the Bit_Rate and Tolerance fields MUST be 288 used together to represent the actual bandwidth of ODUflex, where: 290 - The Bit_Rate field indicates the nominal bit rate of ODUflex(CBR) 291 expressed in bytes per second, encoded as a 32-bit IEEE single- 292 precision floating-point number (referring to [RFC4506] and 293 [IEEE]). The value contained in the Bit Rate field has to keep 294 into account both 239/238 factor and the Transcoding factor. 296 - The Tolerance field indicates the bit rate tolerance (part per 297 million, ppm) of the ODUflex(CBR) encoded as an unsigned integer, 298 which MUST be bounded in 0~100ppm. 300 For example, for an ODUflex(CBR) service with Bit_Rate = 2.5Gbps and 301 Tolerance = 100ppm, the actual bandwidth of the ODUflex is: 303 2.5Gbps * (1 +/- 100ppm) 305 In case of ODUflex(GFP), the Bit_Rate field is used to indicate the 306 nominal bit rate of the ODUflex(GFP), which implies the number of 307 tributary slots requested for the ODUflex(GFP). Since the tolerance 308 of ODUflex(GFP) makes no sense on tributary slot resource 309 reservation, the Tolerance field for ODUflex(GFP) is not necessary 310 and MUST be filled with 0. 312 In case of other ODUk signal types, the Bit_Rate and Tolerance fields 313 are not necessary and MUST be set to 0. 315 The usage of the NVC and Multiplier (MT) fields are the same as 316 [RFC4328]. 318 Note that the error process on the traffic parameters MUST follow the 319 rules defined in Section 6 of [RFC4328]. 321 5.1. Usage of ODUflex(CBR) Traffic Parameters 323 In case of ODUflex(CBR), the information of Bit_Rate and Tolerance in 324 the ODUflex traffic parameters MUST be used to determine the total 325 number of tributary slots N in the HO ODUk link to be reserved. Here: 327 N = Ceiling of 329 ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance) 330 --------------------------------------------------------------------- 331 ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) 333 In this formula, the ODUflex(CBR) nominal bit rate is the bit rate of 334 the ODUflex(CBR) on the line side, i.e., the client signal bit rate 335 after applying the 239/238 factor (according to Clause 7.3, Table 7-2 336 of [G709-2012]) and the transcoding factor T (if needed) on the CBR 337 client. According to clauses 17.7.3, 17.7.4 and 17.7.5 of [G709- 338 2012]: 340 ODUflex(CBR) nominal bit rate = CBR client bit rate * (239/238) / T 342 The ODTUk.ts (Optical channel Data Tributary Unit k with ts tributary 343 slots) nominal bit rate is the nominal bit rate of the tributary slot 344 of ODUk, as shown in Table 1 (referring to Table 7-7 of [G709-2012]). 346 Table 1 - Actual TS bit rate of ODUk (in Kbps) 348 ODUk.ts Minimum Nominal Maximum 349 ----------------------------------------------------------- 350 ODU2.ts 1,249,384.632 1,249,409.620 1,249,434.608 351 ODU3.ts 1,254,678.635 1,254,703.729 1,254,728.823 352 ODU4.ts 1,301.683.217 1,301,709.251 1,301,735.285 354 Note that: 356 Minimum bit rate of ODUTk.ts = 357 ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) 359 Maximum bit rate of ODTUk.ts = 360 ODTUk.ts nominal bit rate * (1 + HO OPUk bit rate tolerance) 362 Where: HO OPUk bit rate tolerance = 20ppm 364 Therefore, a node receiving a PATH message containing ODUflex(CBR) 365 nominal bit rate and tolerance can allocate precise number of 366 tributary slots and set up the cross-connection for the ODUflex 367 service. 369 Note that for different ODUk, the bit rates of the tributary slots 370 are different, and so the total number of tributary slots to be 371 reserved for the ODUflex(CBR) MAY not be the same on different HO 372 ODUk links. 374 An example is given below to illustrate the usage of ODUflex(CBR) 375 traffic parameters. 377 As shown in Figure 1, assume there is an ODUflex(CBR) service 378 requesting a bandwidth of (2.5Gbps, +/-100ppm) from node A to node C. 379 In other words, the ODUflex traffic parameters indicate that Signal 380 Type is 20 (ODUflex(CBR)), Bit_Rate is 2.5Gbps and Tolerance is 381 100ppm. 383 +-----+ +---------+ +-----+ 384 | +-------------+ +-----+ +-------------+ | 385 | +=============+\| ODU |/+=============+ | 386 | +=============+/| flex+-+=============+ | 387 | +-------------+ | |\+=============+ | 388 | +-------------+ +-----+ +-------------+ | 389 | | | | | | 390 | | ....... | | ....... | | 391 | A +-------------+ B +-------------+ C | 392 +-----+ HO ODU4 +---------+ HO ODU2 +-----+ 394 =========: TS occupied by ODUflex 395 ---------: free TS 397 Figure 1 - Example of ODUflex(CBR) Traffic Parameters 399 - On the HO ODU4 link between node A and B: 401 The maximum bit rate of the ODUflex(CBR) equals 2.5Gbps * (1 + 402 100ppm), and the minimum bit rate of the tributary slot of ODU4 403 equals 1,301,683.217 Kbps, so the total number of tributary slots 404 N1 to be reserved on this link is: 406 N1 = ceiling (2.5Gbps * (1 + 100ppm) / 1,301,683.217 Kbps) = 2 408 - On the HO ODU2 link between node B and C: 410 The maximum bit rate of the ODUflex equals 2.5Gbps * (1 + 411 100ppm), and the minimum bit rate of the tributary slot of ODU2 412 equals 1,249,384.632 Kbps, so the total number of tributary slots 413 N2 to be reserved on this link is: 415 N2 = ceiling (2.5Gbps * (1 + 100ppm) / 1,249,384.632 Kbps) = 3 417 5.2. Usage of ODUflex(GFP) Traffic Parameters 419 [G709-2012] recommends that the ODUflex(GFP) will fill an integral 420 number of tributary slots of the smallest HO ODUk path over which the 421 ODUflex(GFP) may be carried, as shown in Table 2. 423 Table 2 - Recommended ODUflex(GFP) bit rates and tolerance 425 ODU type | Nominal bit-rate | Tolerance 426 --------------------------------+------------------+----------- 427 ODUflex(GFP) of n TS, 1<=n<=8 | n * ODU2.ts | +/-100 ppm 428 ODUflex(GFP) of n TS, 9<=n<=32 | n * ODU3.ts | +/-100 ppm 429 ODUflex(GFP) of n TS, 33<=n<=80 | n * ODU4.ts | +/-100 ppm 431 According to this table, the Bit_Rate field for ODUflex(GFP) MUST 432 equal to one of the 80 values listed below: 434 1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts; 435 9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts; 436 33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts. 438 In this way, the number of required tributary slots for the 439 ODUflex(GFP) (i.e., the value of "n" in Table 2) can be deduced from 440 the Bit_Rate field. 442 6. Generalized Label 444 This section defines the format of the OTN-TDM Generalized Label. 446 6.1. OTN-TDM Switching Type Generalized Label 448 The following is the Generalized Label format for that MUST be used 449 with the OTN-TDM Switching Type: 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | TPN | Reserved | Length | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 ~ Bit Map ...... ~ 457 ~ ...... | Padding Bits ~ 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 The OTN-TDM Generalized Label is used to indicate how the LO ODUj 461 signal is multiplexed into the HO ODUk link. Note that the LO OUDj 462 signal type is indicated by traffic parameters, while the type of HO 463 ODUk link is identified by the selected interface carried in the 464 IF_ID RSVP_HOP Object. 466 TPN (12 bits): indicates the TPN for the assigned Tributary Slot(s). 468 - In case of LO ODUj multiplexed into HO ODU1/ODU2/ODU3, only the 469 lower 6 bits of TPN field are significant and the other bits of 470 TPN MUST be set to 0. 472 - In case of LO ODUj multiplexed into HO ODU4, only the lower 7 473 bits of TPN field are significant and the other bits of TPN 474 MUST be set to 0. 476 - In case of ODUj mapped into OTUk (j=k), the TPN is not needed 477 and this field MUST be set to 0. 479 Per [G709-2012], The TPN is used to allow for correct demultiplexing 480 in the data plane. When an LO ODUj is multiplexed into HO ODUk 481 occupying one or more TSs, a new TPN value is configured at the two 482 ends of the HO ODUk link and is put into the related MSI byte(s) in 483 the OPUk overhead at the (traffic) ingress end of the link, so that 484 the other end of the link can learn which TS(s) is/are used by the LO 485 ODUj in the data plane. 487 According to [G709-2012], the TPN field MUST be set as according to 488 the following tables: 490 Table 3 - TPN Assignment Rules (2.5Gbps TS granularity) 491 +-------+-------+----+----------------------------------------------+ 492 |HO ODUk|LO ODUj|TPN | TPN Assignment Rules | 493 +-------+-------+----+----------------------------------------------+ 494 | ODU2 | ODU1 |1~4 |Fixed, = TS# occupied by ODU1 | 495 +-------+-------+----+----------------------------------------------+ 496 | | ODU1 |1~16|Fixed, = TS# occupied by ODU1 | 497 | ODU3 +-------+----+----------------------------------------------+ 498 | | ODU2 |1~4 |Flexible, != other existing LO ODU2s' TPNs | 499 +-------+-------+----+----------------------------------------------+ 501 Table 4 - TPN Assignment Rules (1.25Gbps TS granularity) 502 +-------+-------+----+----------------------------------------------+ 503 |HO ODUk|LO ODUj|TPN | TPN Assignment Rules | 504 +-------+-------+----+----------------------------------------------+ 505 | ODU1 | ODU0 |1~2 |Fixed, = TS# occupied by ODU0 | 506 +-------+-------+----+----------------------------------------------+ 507 | | ODU1 |1~4 |Flexible, != other existing LO ODU1s' TPNs | 508 | ODU2 +-------+----+----------------------------------------------+ 509 | |ODU0 & |1~8 |Flexible, != other existing LO ODU0s and | 510 | |ODUflex| |ODUflexes' TPNs | 511 +-------+-------+----+----------------------------------------------+ 512 | | ODU1 |1~16|Flexible, != other existing LO ODU1s' TPNs | 513 | +-------+----+----------------------------------------------+ 514 | | ODU2 |1~4 |Flexible, != other existing LO ODU2s' TPNs | 515 | ODU3 +-------+----+----------------------------------------------+ 516 | |ODU0 & | |Flexible, != other existing LO ODU0s and | 517 | |ODU2e &|1~32|ODU2es and ODUflexes' TPNs | 518 | |ODUflex| | | 519 +-------+-------+----+----------------------------------------------+ 520 | ODU4 |Any ODU|1~80|Flexible, != ANY other existing LO ODUs' TPNs | 521 +-------+-------+----+----------------------------------------------+ 523 Note that in the case of "Flexible", the value of TPN MAY not be 524 corresponding to the TS number as per [G709-2012]. 526 Length (12 bits): indicates the number of bits of the Bit Map field, 527 i.e., the total number of TS in the HO ODUk link. The valid values 528 for this field are 0, 2, 4, 8, 16, 32 and 80. 530 In case of an ODUk mapped into OTUk, there is no need to indicate 531 which tributary slots will be used, so the length field MUST be set 532 to 0. 534 Bit Map (variable): indicates which tributary slots in HO ODUk that 535 the LO ODUj will be multiplexed into. The sequence of the Bit Map is 536 consistent with the sequence of the tributary slots in HO ODUk. Each 537 bit in the bit map represents the corresponding tributary slot in HO 538 ODUk with a value of 1 or 0 indicating whether the tributary slot 539 will be used by LO ODUj or not. 541 Padding bits are added after the Bit Map to make the whole label a 542 multiple of four bytes if necessary. Padding bits MUST be set to 0 543 and MUST be ignored. 545 6.2. Procedures 547 When a node receives a generalized label request for setting up an 548 ODUj LSP from its upstream neighbor node, the node MUST generate an 549 OTN-TDM label according to the signal type of the requested LSP and 550 the free resources (i.e., free tributary slots of ODUk) that will be 551 reserved for the LSP, and send the label to its upstream neighbor 552 node. 554 In case of ODUj to ODUk multiplexing, the node MUST firstly determine 555 the size of the Bit Map field according to the signal type and the 556 tributary slot type of ODUk, and then set the bits to 1 in the Bit 557 Map field corresponding to the reserved tributary slots. The node 558 MUST also assign a valid TPN, which MUST NOT collide with other TPN 559 value used by existing LO ODU connections in the selected HO ODU 560 link, and configure the Expected MSI (ExMSI) using this TPN. Then, 561 the assigned TPN MUST be filled into the label. 563 In case of ODUk to OTUk mapping, TPN field MUST be set to 0. Bit Map 564 information is not REQUIRED and MUST NOT be included, so Length field 565 MUST be set to 0 as well. 567 The node receiving a OTN-TDM generalized label MUST firstly identify 568 which ODU signal type is multiplexed or mapped into which ODU signal 569 type accordingly to the traffic parameters and the IF_ID RSVP_HOP 570 Object in the received message. 572 In case of ODUj to ODUk multiplexing, the node MUST retrieve the 573 reserved tributary slots in the ODUk by its downstream neighbor node 574 according to the position of the bits that are set to 1 in the Bit 575 Map field. The node determines the TS type (according to the total TS 576 number of the ODUk, or pre-configured TS type), so that the node, 577 based on the TS type, can multiplex the ODUj into the ODUk. The node 578 MUST also retrieve the TPN value assigned by its downstream neighbor 579 node from the label, and fill the TPN into the related MSI byte(s) in 580 the OPUk overhead in the data plane, so that the downstream neighbor 581 node can check whether the TPN received from the data plane is 582 consistent with the ExMSI and determine whether there is any mismatch 583 defect. 585 Note that the Length field in the label format MAY be used to 586 indicate the TS type of the HO ODUk (i.e., TS granularity at 1.25Gbps 587 or 2.5Gbps) since the HO ODUk type can be known from IF_ID RSVP_HOP 588 Object. In some cases when there is no Link Management Protocol (LMP) 589 or routing to make the two end points of the link to know the TSG, 590 the TSG information used by another end can be deduced from the label 591 format. For example, for HO ODU2 link, the value of the length filed 592 will be 4 or 8, which indicates the TS granularity is 2.5Gbps or 593 1.25Gbps, respectively. 595 In case of ODUk to OTUk mapping, the size of Bit Map field MUST be 0 596 and no additional procedure is needed. 598 In order to create bidirectional LSP, an upstream node MUST generate 599 an Upstream Label on the out outgoing interface to indicate the 600 reserved TSs of ODUk and the assigned TPN value in the upstream 601 direction. This Upstream Label is sent to the downstream node via 602 Path massage for upstream resource reservation. 604 The upstream node MAY generate Label Set to indicate which labels on 605 the outgoing interface in the downstream direction are acceptable. 606 The downstream node will restrict its choice of labels, i.e., TS 607 resource and TPN value, to one which is in the Label Set. 609 The upstream node MAY also generate Suggested Label to indicate the 610 preference of TS resource and TPN value on the outgoing interface in 611 the downstream direction. The downstream node is not REQUIRED to use 612 the Suggested Label and MAY use another label based on local decision 613 and send it to the upstream node, as described in [RFC3473]. 615 The ingress node of an LSP MAY include label ERO to indicate the 616 label in each hops along the path. Note that the TPN in the label ERO 617 (Explicit Route Object) subobject MAY not be assigned by the ingress 618 node. In this case, the node MUST assign a valid TPN value and then 619 put this value into TPN field of the label object when receiving a 620 Path message. 622 6.2.1. Notification on Label Error 624 When receiving an OTN-TDM label from the neighbor node, the node MUST 625 check whether the label is acceptable. An error message containing an 626 "Unacceptable label value" indication ([RFC3209]) MUST be sent if one 627 of the following cases occurs: 629 - Invalid value in the length field; 631 - The selected link only supports 2.5Gbps TS granularity while the 632 Length field in the label along with ODUk signal type indicates 633 the 1.25Gbps TS granularity; 635 - The label includes an invalid TPN value that breaks the TPN 636 assignment rules; 638 - The indicated resources (i.e., the number of "1" in the Bit Map 639 field) are inconsistent with the Traffic Parameters. 641 6.3. Supporting Virtual Concatenation and Multiplication 643 Per [RFC6344], the Virtual Concatenation Groups (VCGs) can be created 644 using Co-Signaled style or Multiple LSPs style. 646 In case of Co-Signaled style, the explicit ordered list of all labels 647 MUST reflect the order of VCG members, which is similar to [RFC4328]. 648 In case of multiplexed virtually concatenated signals (NVC > 1), the 649 first label MUST indicate the components of the first virtually 650 concatenated signal; the second label MUST indicate the components of 651 the second virtually concatenated signal; and so on. In case of 652 multiplication of multiplexed virtually concatenated signals (MT > 653 1), the first label MUST indicate the components of the first 654 multiplexed virtually concatenated signal; the second label MUST 655 indicate components of the second multiplexed virtually concatenated 656 signal; and so on. 658 In case of Multiple LSPs style, multiple control plane LSPs are 659 created with a single VCG and the VCAT Call SHOULD be used to 660 associate the control plane LSPs. The procedures are similar to 661 section 6 of [RFC6344]. 663 6.4. Examples 665 The following examples are given in order to illustrate the label 666 format described in Section 5.1 of this document. 668 (1) ODUk into OTUk mapping: 670 In such conditions, the downstream node along an LSP returns a label 671 indicating that the ODUk (k=1, 2, 3, 4) is directly mapped into the 672 corresponding OTUk. The following example label indicates an ODU1 673 mapped into OTU1. 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | TPN = 0 | Reserved | Length = 0 | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 (2) ODUj into ODUk multiplexing: 683 In such conditions, this label indicates that an ODUj is multiplexed 684 into several tributary slots of OPUk and then mapped into OTUk. Some 685 instances are shown as follow: 687 - ODU0 into ODU2 Multiplexing: 689 0 1 2 3 690 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 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | TPN = 2 | Reserved | Length = 8 | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 |0 1 0 0 0 0 0 0| Padded Bits (0) | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 This above label indicates an ODU0 multiplexed into the second 698 tributary slot of ODU2, wherein there are 8 TS in ODU2 (i.e., the 699 type of the tributary slot is 1.25Gbps), and the TPN value is 2. 701 - ODU1 into ODU2 Multiplexing with 1.25Gbps TS granularity: 703 0 1 2 3 704 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 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | TPN = 1 | Reserved | Length = 8 | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 |0 1 0 1 0 0 0 0| Padded Bits (0) | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 This above label indicates an ODU1 multiplexed into the 2nd and the 712 4th tributary slot of ODU2, wherein there are 8 TS in ODU2 (i.e., the 713 type of the tributary slot is 1.25Gbps), and the TPN value is 1. 715 - ODU2 into ODU3 Multiplexing with 2.5Gbps TS granularity: 717 0 1 2 3 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | TPN = 1 | Reserved | Length = 16 | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 |0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0| Padded Bits (0) | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 This above label indicates an ODU2 multiplexed into the 2nd, 3rd, 5th 726 and 7th tributary slot of ODU3, wherein there are 16 TS in ODU3 727 (i.e., the type of the tributary slot is 2.5Gbps), and the TPN value 728 is 1. 730 7. Supporting Hitless Adjustment of ODUflex (GFP) 732 [G7044] describes the procedure of ODUflex (GFP) hitless resizing 733 using Link Connection Resize (LCR) and Bandwidth Resize (BWR) 734 protocols in OTN data plane. 736 For the control plane, signaling messages are REQUIRED to initiate 737 the adjustment procedure. Section 2.5 and Section 4.6.4 of [RFC3209] 738 describe how the Shared Explicit (SE) style is used in Traffic 739 Engineering (TE) network for bandwidth increasing and decreasing, 740 which is still applicable for triggering the ODUflex (GFP) adjustment 741 procedure in data plane. 743 Note that the SE style MUST be used at the beginning when creating a 744 resizable ODUflex connection (Signal Type = 21). Otherwise an error 745 with Error Code "Conflicting reservation style" MUST be generated 746 when performing bandwidth adjustment. 748 - Bandwidth increasing 750 In order to increase the bandwidth of an ODUflex (GFP) 751 connection, a Path message with SE style (keeping Tunnel ID 752 unchanged and assigning a new LSP ID) MUST be sent along the 753 path. 755 A downstream node compares the old Traffic Parameters (stored 756 locally) with the new one carried in the Path message, to 757 determine the number of TS to be added. After choosing and 758 reserving new free TS, the downstream node MUST send back a Resv 759 message carrying both the old and new LABEL Objects in the SE 760 flow descriptor, so that its upstream neighbor can determine 761 which TS are added. And the LCR protocol between each pair of 762 neighbor nodes MUST be triggered. 764 On the source node, the BWR protocol will be triggered by the 765 successful completion of LCR protocols on every hop after Resv 766 message is processed. On success of BWR, the source node MUST 767 send a PathTear message to delete the old control state (i.e., 768 the control state of the ODUflex (GFP) before resizing) on the 769 control plane. 771 - Bandwidth decreasing 773 The SE style SHOULD also be used for ODUflex bandwidth 774 decreasing. For each pair of neighbor nodes, the sending and 775 receiving Resv message with old and new LABEL Objects will 776 trigger the first step of LCR between them to perform LCR 777 handshake. On the source node, the BWR protocol will be triggered 778 by the successful completion of LCR handshake on every hop after 779 Resv message is processed. On success of BWR, the second step of 780 LCR, i.e., link connection decrease procedure will be started on 781 every hop of the connection. 783 Similarly, after completion of bandwidth decreasing, a ResvErr 784 message SHOULD be sent to tear down the old control state. 786 8. Control Plane Backward Compatibility Considerations 788 As described in [OTN-FWK], since the [RFC4328] has been deployed in 789 the network for the nodes that support the 2001 revision of the G.709 790 specification, control plane backward compatibility SHOULD be taken 791 into consideration. More specifically: 793 o Nodes supporting this document SHOULD support [OTN-OSPF]. 795 o Nodes supporting this document MAY support [RFC4328] signaling. 797 o A node supporting both sets of procedures (i.e., [RFC4328] and 798 this document) is not REQUIRED to signal an LSP using both 799 procedures, i.e., to act as a signaling version translator. 801 o Ingress nodes that support both sets of procedures MAY select 802 which set of procedures to follow based on routing information or 803 local policy. 805 o Per [RFC3473], nodes that do not support this document will 806 generate a PathErr message, with a "Routing problem/Switching 807 Type" indication. 809 9. Security Considerations 811 This document introduces no new security considerations to the 812 existing GMPLS signaling protocols. Referring to [RFC3473] and 813 [RFC4328], further details of the specific security measures are 814 provided. Additionally, [RFC5920] provides an overview of security 815 vulnerabilities and protection mechanisms for the GMPLS control 816 plane. 818 10. IANA Considerations 820 Three RSVP C-Types are defined for OTN-TDM Traffic Parameters and 821 OTN-TDM Generalized Label in this document. 823 - OTN-TDM SENDER_TSPEC and FLOWSPEC objects: 825 o OTN-TDM SENDER_TSPEC Object: Class = 12, C-Type = 7 (see 826 Section 4) 828 o OTN-TDM FLOWSPEC Object: Class = 9, C-Type = 7 (see Section 4) 830 - OTN-TDM Generalized Label Object: 832 o OTN-TDM Generalized Label Object: Class = 16, C-Type = 2 (see 833 Section 5.1) 835 IANA will also track the code-point spaces extended and/or updated by 836 this document. The Generalized PID has been added in the newly 837 requested registry entry: 839 - Generalized PID (G-PID): 841 Name: G-PID 843 Format: 16-bit number 845 Values: 847 [0..31, 36..46] defined in [RFC3471] 849 [32] defined in [RFC3471] and updated by Section 3 850 [33..35] defined in [RFC3471] and updated by [RFC4328] 851 [47, 49..52] defined in [RFC4328] and updated by Section 3 852 [48, 53..58] defined in [RFC4328] 853 [59..63] defined in Section 3 855 Allocation Policy (as defined in [RFC4328]): 857 [0..31743] Assigned by IANA via IETF Standards Track RFC 858 Action. 859 [31744..32767] Assigned temporarily for Experimental Usage 860 [32768..65535] Not assigned. Before any assignments can be 861 made in this range, there MUST be a Standards 862 Track RFC that specifies IANA Considerations 863 that covers the range being assigned. 865 11. References 867 11.1. Normative References 869 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 870 Requirement Levels", BCP 14, RFC 2119, March 1997. 872 [RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 873 Tunnels", RFC3209, December 2001. 875 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 876 Switching (GMPLS) Signaling Functional Description", RFC 877 3471, January 2003. 879 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label Switching 880 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 881 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 883 [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label 884 Switching (GMPLS) Signaling Extensions for G.709 Optical 885 Transport Networks Control", RFC 4328, Jan 2006. 887 [RFC6344] G. Bernstein et al, "Operating Virtual Concatenation (VCAT) 888 and the Link Capacity Adjustment Scheme (LCAS) with 889 Generalized Multi-Protocol Label Switching (GMPLS)", 890 RFC6344, August 2011. 892 11.2. Informative References 894 [OTN-FWK] Fatai Zhang et al, "Framework for GMPLS and PCE Control of 895 G.709 Optical Transport Networks", Work in Progress: draft- 896 ietf-ccamp-gmpls-g709-framework, November 2012. 898 [OTN-INFO] S. Belotti et al, "Information model for G.709 Optical 899 Transport Networks (OTN)", Work in Progress: draft-ietf- 900 ccamp-otn-g709-info-model, November 2012. 902 [OTN-OSPF] D. Ceccarelli et al, "Traffic Engineering Extensions to 903 OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 904 OTN Networks", Work in Progress: draft-ietf-ccamp-gmpls- 905 ospf-g709v3, November 2012. 907 [G709-2012] ITU-T, "Interfaces for the Optical Transport Network 908 (OTN)", G.709/Y.1331 Recommendation, February 2012. 910 [G7044] ITU-T, "Hitless adjustment of ODUflex", G.7044/Y.1347, 911 October 2011. 913 [RFC4506] M. Eisler, Ed., "XDR: External Data Representation 914 Standard", RFC 4506, May 2006. 916 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 917 Networks", RFC5920, July 2010. 919 [IEEE] "IEEE Standard for Binary Floating-Point Arithmetic", 920 ANSI/IEEE Standard 754-1985, Institute of Electrical and 921 Electronics Engineers, August 1985. 923 12. Contributors 925 Jonathan Sadler, Tellabs 926 Email: jonathan.sadler@tellabs.com 928 Kam LAM, Alcatel-Lucent 929 Email: kam.lam@alcatel-lucent.com 930 Xiaobing Zi, Huawei Technologies 931 Email: zixiaobing@huawei.com 933 Francesco Fondelli, Ericsson 934 Email: francesco.fondelli@ericsson.com 936 Lyndon Ong, Ciena 937 Email: lyong@ciena.com 939 Biao Lu, infinera 940 Email: blu@infinera.com 942 13. Authors' Addresses 944 Fatai Zhang (editor) 945 Huawei Technologies 946 F3-5-B R&D Center, Huawei Base 947 Bantian, Longgang District 948 Shenzhen 518129 P.R.China 949 Phone: +86-755-28972912 950 Email: zhangfatai@huawei.com 952 Guoying Zhang 953 China Academy of Telecommunication Research of MII 954 11 Yue Tan Nan Jie Beijing, P.R.China 955 Phone: +86-10-68094272 956 Email: zhangguoying@mail.ritt.com.cn 958 Sergio Belotti 959 Alcatel-Lucent 960 Optics CTO 961 Via Trento 30 20059 Vimercate (Milano) Italy 962 +39 039 6863033 963 Email: sergio.belotti@alcatel-lucent.it 964 Daniele Ceccarelli 965 Ericsson 966 Via A. Negrone 1/A 967 Genova - Sestri Ponente 968 Italy 969 Email: daniele.ceccarelli@ericsson.com 971 Khuzema Pithewan 972 Infinera Corporation 973 169, Java Drive 974 Sunnyvale, CA-94089, USA 975 Email: kpithewan@infinera.com 977 Yi Lin 978 Huawei Technologies 979 F3-5-B R&D Center, Huawei Base 980 Bantian, Longgang District 981 Shenzhen 518129 P.R.China 982 Phone: +86-755-28972914 983 Email: yi.lin@huawei.com 985 Yunbin Xu 986 China Academy of Telecommunication Research of MII 987 11 Yue Tan Nan Jie Beijing, P.R.China 988 Phone: +86-10-68094134 989 Email: xuyunbin@mail.ritt.com.cn 991 Pietro Grandi 992 Alcatel-Lucent 993 Optics CTO 994 Via Trento 30 20059 Vimercate (Milano) Italy 995 +39 039 6864930 996 Email: pietro_vittorio.grandi@alcatel-lucent.it 997 Diego Caviglia 998 Ericsson 999 Via A. Negrone 1/A 1000 Genova - Sestri Ponente 1001 Italy 1002 Email: diego.caviglia@ericsson.com 1004 Rajan Rao 1005 Infinera Corporation 1006 169, Java Drive 1007 Sunnyvale, CA-94089 1008 USA 1009 Email: rrao@infinera.com 1011 John E Drake 1012 Juniper 1013 Email: jdrake@juniper.net 1015 Igor Bryskin 1016 Adva Optical 1017 EMail: IBryskin@advaoptical.com 1019 14. Acknowledgment 1021 The authors would like to thank Lou Berger and Deborah Brungard for 1022 their useful comments to the document. 1024 Intellectual Property 1026 The IETF Trust takes no position regarding the validity or scope of 1027 any Intellectual Property Rights or other rights that might be 1028 claimed to pertain to the implementation or use of the technology 1029 described in any IETF Document or the extent to which any license 1030 under such rights might or might not be available; nor does it 1031 represent that it has made any independent effort to identify any 1032 such rights. 1034 Copies of Intellectual Property disclosures made to the IETF 1035 Secretariat and any assurances of licenses to be made available, or 1036 the result of an attempt made to obtain a general license or 1037 permission for the use of such proprietary rights by implementers or 1038 users of this specification can be obtained from the IETF on-line IPR 1039 repository at http://www.ietf.org/ipr 1041 The IETF invites any interested party to bring to its attention any 1042 copyrights, patents or patent applications, or other proprietary 1043 rights that may cover technology that may be required to implement 1044 any standard or specification contained in an IETF Document. Please 1045 address the information to the IETF at ietf-ipr@ietf.org. 1047 The definitive version of an IETF Document is that published by, or 1048 under the auspices of, the IETF. Versions of IETF Documents that are 1049 published by third parties, including those that are translated into 1050 other languages, should not be considered to be definitive versions 1051 of IETF Documents. The definitive version of these Legal Provisions 1052 is that published by, or under the auspices of, the IETF. Versions of 1053 these Legal Provisions that are published by third parties, including 1054 those that are translated into other languages, should not be 1055 considered to be definitive versions of these Legal Provisions. 1057 For the avoidance of doubt, each Contributor to the IETF Standards 1058 Process licenses each Contribution that he or she makes as part of 1059 the IETF Standards Process to the IETF Trust pursuant to the 1060 provisions of RFC 5378. No language to the contrary, or terms, 1061 conditions or rights that differ from or are inconsistent with the 1062 rights and licenses granted under RFC 5378, shall have any effect and 1063 shall be null and void, whether published or posted by such 1064 Contributor, or included with or in such Contribution. 1066 Disclaimer of Validity 1068 All IETF Documents and the information contained therein are provided 1069 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1070 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1071 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1072 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1073 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1074 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1075 FOR A PARTICULAR PURPOSE. 1077 Copyright Notice 1079 Copyright (c) 2012 IETF Trust and the persons identified as the 1080 document authors. All rights reserved. 1082 This document is subject to BCP 78 and the IETF Trust's Legal 1083 Provisions Relating to IETF Documents 1084 (http://trustee.ietf.org/license-info) in effect on the date of 1085 publication of this document. Please review these documents 1086 carefully, as they describe your rights and restrictions with respect 1087 to this document. Code Components extracted from this document must 1088 include Simplified BSD License text as described in Section 4.e of 1089 the Trust Legal Provisions and are provided without warranty as 1090 described in the Simplified BSD License.