idnits 2.17.1 draft-ietf-ccamp-gmpls-g709-framework-02.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 : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 392: '...alues of the TPN MUST be either agreed...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2010) is 5036 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3945' is mentioned on line 92, but not defined == Missing Reference: 'RFC4655' is mentioned on line 111, but not defined == Missing Reference: 'G872Am2' is mentioned on line 156, but not defined == Missing Reference: 'WSON-Frame' is mentioned on line 550, but not defined == Unused Reference: 'HZang00' is defined on line 912, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4205 (Obsoleted by RFC 5307) == Outdated reference: A later version (-09) exists of draft-ietf-pce-gmpls-aps-req-01 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Fatai Zhang 2 Internet Draft Dan Li 3 Category: Informational Huawei 4 Han Li 5 CMCC 6 S.Belotti 7 Alcatel-Lucent 8 Expires: January 12, 2011 July 12, 2010 10 Framework for GMPLS and PCE Control of 11 G.709 Optical Transport Networks 13 draft-ietf-ccamp-gmpls-g709-framework-02.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 12, 2011. 38 Abstract 40 This document provides a framework to allow the development of 41 protocol extensions to support Generalized Multi-Protocol Label 42 Switching (GMPLS) and Path Computation Element (PCE) control of 43 Optical Transport Networks (OTN) as specified in ITU-T Recommendation 44 G.709 as consented in October 2009. 46 Table of Contents 48 1. Introduction..................................................2 49 2. Terminology...................................................3 50 3. G.709 Optical Transport Network (OTN).........................4 51 3.1. OTN Layer Network........................................4 52 3.1.1. Client signal mapping...............................5 53 3.1.1.1. ODUj types and parameters......................6 54 3.1.2. Multiplexing ODUj onto Links........................7 55 3.1.2.1. Link Parameters................................8 56 3.1.2.2. Tributary Port Number Assignment...............9 57 4. Connection management in OTN.................................10 58 4.1. Connection management of the ODU........................10 59 5. GMPLS/PCE Implications.......................................13 60 5.1. Implications for LSP Hierarchy with GMPLS TE............13 61 5.2. Implications for GMPLS Signaling........................13 62 5.2.1. Identifying OTN signals............................14 63 5.2.2. Tributary Port Number..............................15 64 5.2.3. Support for constraint signaling...................15 65 5.3. Implications for GMPLS Routing..........................15 66 5.4. Implications for Link Management Protocol (LMP).........17 67 5.4.1. Correlating the Granularity of the TS..............18 68 5.4.2. Correlating the Supported LO ODU Signal Types......18 69 5.5. Implications for Path Computation Elements..............18 70 6. Security Considerations......................................19 71 7. IANA Considerations..........................................19 72 8. Acknowledgments..............................................19 73 9. References...................................................19 74 9.1. Normative References....................................19 75 9.2. Informative References..................................21 76 10. Authors' Addresses..........................................21 77 11. Contributors................................................22 78 APPENDIX A: ODU connection examples.............................23 80 1. Introduction 82 OTN has become a mainstream layer 1 technology for the transport 83 network. Operators want to introduce control plane capabilities based 84 on Generalized Multi-Protocol Label Switching (GMPLS) to OTN networks, 85 to realize the benefits associated with a high-function control plane 86 (e.g., improved network resiliency, resource usage efficiency, etc.). 88 GMPLS extends MPLS to encompass time division multiplexing (TDM) 89 networks (e.g., SONET/SDH, PDH, and G.709 sub-lambda), lambda 90 switching optical networks, and spatial switching (e.g., incoming 91 port or fiber to outgoing port or fiber). The GMPLS architecture is 92 provided in [RFC3945], signaling function and Resource ReserVation 93 Protocol-Traffic Engineering (RSVP-TE) extensions are described in 94 [RFC3471] and [RFC3473], routing and OSPF extensions are described in 95 [RFC4202] and [RFC4203], and the Link Management Protocol (LMP) is 96 described in [RFC4204]. 98 The GMPLS protocol suite including provision [RFC4328] provides the 99 mechanisms for basic GMPLS control of OTN networks based on the 2001 100 revision of the G.709 specification [G709-V1]. Later revisions of the 101 G.709 specification, including [G709-V3], have included some new 102 features; for example, various multiplexing structures, two types of 103 TSs (i.e., 1.25Gbps and 2.5Gbps), and extension of the Optical Data 104 Unit (ODU) ODUj definition to include the ODUflex function. 106 This document reviews relevant aspects of OTN technology evolution 107 that affect the GMPLS control plane protocols and examines why and 108 how to update the mechanisms described in [RFC4328]. This document 109 additionally provides a framework for the GMPLS control of OTN 110 networks and includes a discussion of the implication for the use of 111 the Path Computation Element (PCE) [RFC4655]. No additional Switching 112 Type and LSP Encoding Type are required to support the control of the 113 evolved OTN, because the Switching Type and LSP Encoding Type defined 114 in [RFC4328] are still applicable. 116 For the purposes of the control plane the OTN can be considered as 117 being comprised of ODU and wavelength (OCh) layers. This document 118 focuses on the control of the ODU layer, with control of the 119 wavelength layer considered out of the scope. Please refer to [WSON- 120 Frame] for further information about the wavelength layer. 122 2. Terminology 124 OTN: Optical Transport Network 126 ODU: Optical Channel Data Unit 128 OTU: Optical channel transport unit 130 OMS: Optical multiplex section 132 MSI: Multiplex Structure Identifier 134 TPN: Tributary Port Number 136 LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4, 137 flex.) represents the container transporting a client of the OTN that 138 is either directly mapped into an OTUk (k = j) or multiplexed into a 139 server HO ODUk (k > j) container. 141 HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, 4.) 142 represents the entity transporting a multiplex of LO ODUj tributary 143 signals in its OPUk area. 145 ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a 146 bit rate tolerance up to 100 ppm. 148 3. G.709 Optical Transport Network (OTN) 150 This section provides an informative overview of those aspects of the 151 OTN impacting control plane protocols. This overview is based on the 152 ITU-T Recommendations that contain the normative definition of the 153 OTN. Technical details regarding OTN architecture and interfaces are 154 provided in the relevant ITU-T Recommendations. 156 Specifically, [G872-2001] and [G872Am2] describe the functional 157 architecture of optical transport networks providing optical signal 158 transmission, multiplexing, routing, supervision, performance 159 assessment, and network survivability. [G709-V1] defines the 160 interfaces of the optical transport network to be used within and 161 between subnetworks of the optical network. With the evolution and 162 deployment of OTN technology many new features have been specified in 163 ITU-T recommendations, including for example, new ODU0, ODU2e, ODU4 164 and ODUflex containers as described in [G709-V3]. 166 3.1. OTN Layer Network 168 The simplified signal hierarchy of OTN is shown in Figure 1, which 169 illustrates the layers that are of interest to the control plane. 170 Other layers below OCh (e.g. Optical Transmission Section - OTS) are 171 not included in this Figure. The full signal hierarchy is provided in 172 [G709-V3]. 174 Client signal 175 | 176 ODUj 177 | 178 OTU/OCh 179 OMS 181 Figure 1 - Basic OTN signal hierarchy 183 Client signals are mapped into ODUj containers. These ODUj containers 184 are multiplexed onto the OTU/OCh. The individual OTU/OCh signals are 185 combined in the Optical Multiplex Section (OMS) using WDM 186 multiplexing, and this aggregated signal provides the link between 187 the nodes. 189 3.1.1. Client signal mapping 191 The client signals are mapped into a Low Order (LO) ODUj. Appendix A 192 gives more information about LO ODU. 194 The current values of j defined in [G709-V3] are: 0, 1, 2, 2e, 3, 4, 195 Flex. The approximate bit rates of these signals are defined in 196 [G709-V3] and are reproduced in Tables 1 and 2. 198 +-----------------------+-----------------------------------+ 199 | ODU Type | ODU nominal bit rate | 200 +-----------------------+-----------------------------------+ 201 | ODU0 | 1 244 160 kbits/s | 202 | ODU1 | 239/238 x 2 488 320 kbit/s | 203 | ODU2 | 239/237 x 9 953 280 kbit/s | 204 | ODU3 | 239/236 x 39 813 120 kbit/s | 205 | ODU4 | 239/227 x 99 532 800 kbit/s | 206 | ODU2e | 239/237 x 10 312 500 kbit/s | 207 | | | 208 | ODUflex for CBR | | 209 | Client signals | 239/238 x client signal bit rate | 210 | | | 211 | ODUflex for GFP-F | | 212 | Mapped client signal | Configured bit rate | 213 +-----------------------+-----------------------------------+ 215 Table 1 - ODU types and bit rates 217 NOTE - The nominal ODUk rates are approximately: 2 498 775.126 kbit/s 218 (ODU1), 10 037 273.924 kbit/s (ODU2), 40 319 218.983 kbit/s (ODU3), 219 104 794 445.815 kbit/s (ODU4) and 10 399 525.316 kbit/s (ODU2e). 221 +-------------------+--------------------------------------+ 222 | ODU Type | ODU bit-rate tolerance | 223 +-------------------+--------------------------------------+ 224 | ODU0 | +- 20 ppm | 225 | ODU1 | +- 20 ppm | 226 | ODU2 | +- 20 ppm | 227 | ODU3 | +- 20 ppm | 228 | ODU4 | +- 20 ppm | 229 | ODU2e | +- 100 ppm | 230 | | | 231 | ODUflex for CBR | | 232 | Client signals | client signal bit rate tolerance, | 233 | | with a maximum of+-100 ppm | 234 | | | 235 | ODUflex for GFP-F | | 236 | Mapped client | +- 20 ppm | 237 | signal | | 238 +-------------------+--------------------------------------+ 239 Table 2 - ODU types and tolerance 241 One of two options is for mapping client signals into ODUflex 242 depending on the client signal type: 244 - Circuit clients are proportionally wrapped. Thus the bit rate and 245 tolerance are defined by the client signal. 247 - Packet clients are mapped using the Generic Framing Procedure 248 (GFP). [G709-V3] recommends that the bit rate should be set to an 249 integer multiplier of the High Order (HO) Optical Channel Physical 250 Unit (OPU) OPUk TS rate, the tolerance should be +/- 20ppm, and 251 the bit rate should be determined by the node that performs the 252 mapping. 254 3.1.1.1. ODUj types and parameters 256 When ODUj connections are setup, two types of information should be 257 conveyed in a connection request: 259 (a) End to end: 260 Client payload type (e.g. STM64; Ethernet etc.) 261 Bit rate and tolerance: Note for j = 0, 1, 2, 2e, 3, 4 this 262 information may be carried as an enumerated type. For the ODUflex 263 the actual bit rate and tolerance must be provided. 265 (b) Hop by hop: 266 TS assignment and port number carried by the Multiplex Structure 267 Identifier (MSI) bytes as described in section 3.1.2. 269 3.1.2. Multiplexing ODUj onto Links 271 The links between the switching nodes are provided by one or more 272 wavelengths. Each wavelength carries one OCh, which carries one OTU, 273 which carries one OPU. Since all of these signals have a 1:1:1 274 relationship, we only refer to the OTU for clarity. The ODUjs are 275 mapped into the TS of the OTUk. Note that in the case where j=k the 276 ODUj is mapped into the OTU/OCh without multiplexing. 278 The initial versions of G.709 [G709-V1] only provided a single TS 279 granularity, nominally 2.5Gb/s. [G709-V3], approved in 2009, added an 280 additional TS granularity, nominally 1.25Gb/s. The number and type of 281 TSs provided by each of the currently identified OTUk is provided 282 below: 284 2.5Gb/s 1.25Gb/s Nominal Bit rate 285 OTU1 1 2 2.5Gb/s 286 OTU2 4 8 10Gb/s 287 OTU3 16 32 40Gb/s 288 OTU4 -- 80 100Gb/s 290 To maintain backwards compatibility while providing the ability to 291 interconnect nodes that support 1.25Gb/s TS at one end of a link and 292 2.5Gb/s TS at the other, the 'new' equipment will fall back to the 293 use of a 2.5Gb/s TS if connected to legacy equipment. This 294 information is carried in band by the payload type. 296 The actual bit rate of the TS in an OTUk depends on the value of k. 297 Thus the number of TS occupied by an ODUj may vary depending on the 298 values of j and k. For example an ODU2e uses 9 TS in an OTU3 but 299 only 8 in an OTU4. Examples of the number of TS used for various 300 cases are provided below: 302 - ODU0 into ODU1, ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS 303 granularity 304 o ODU0 occupies 1 of the 2, 8, 32 or 80 TS for ODU1, ODU2, ODU3 305 or ODU4 307 - ODU1 into ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS 308 granularity 309 o ODU1 occupies 2 of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4 311 - ODU1 into ODU2, ODU3 multiplexing with 2.5Gbps TS granularity 312 o ODU1 occupies 1 of the 4 or 16 TS for ODU2 or ODU3 314 - ODU2 into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity 315 o ODU2 occupies 8 of the 32 or 80 TS for ODU3 or ODU4 317 - ODU2 into ODU3 multiplexing with 2.5Gbps TS granularity 318 o ODU2 occupies 4 of the 16 TS for ODU3 320 - ODU3 into ODU4 multiplexing with 1.25Gbps TS granularity 321 o ODU3 occupies 31 of the 80 TS for ODU4 323 - ODUflex into ODU2, ODU3 or ODU4 multiplexing with 1.25Gbps TS 324 granularity 325 o ODUflex occupies n of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4 326 (n <= Total TS numbers of ODUk) 328 - ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity 329 o ODU2e occupies 9 of the 32 TS for ODU3 or 8 of the 80 TS for 330 ODU4 332 In general the mapping of an ODUj (including ODUflex) into the OTUk 333 TSs is determined locally, and it can also be explicitly controlled 334 by a specific entity (e.g., head end, NMS) through Explicit Label 335 Control [RFC3473]. 337 3.1.2.1. Link Parameters 339 Per [RFC4201], each OTU can be treated as a component link of a link 340 bundle. The available capacity between nodes is the sum of the 341 available capacity on the OTUs that interconnect the nodes. This 342 total capacity is represented as the capacity of a link bundle. 344 Note that there will typically be more than one OTU between a pair of 345 nodes so that the available capacity will typically be distributed 346 across multiple OTUs. Thus, in order to be able to determine the 347 maximum payload that can be carried on a bundled link, the link state 348 advertisement must also provide the largest number of TSes available 349 on any one component OTU. 351 In order to compute the lowest cost path for a ODUj connection 352 request the critical parameters that need to be provided (for the 353 purposes of routing) are: 355 - Number of TS 357 - Maximum number of TS available for a LSP (i.e., Maximum LSP 358 Bandwidth) 360 - Bit rate of the TS. (Note: This may be efficiently encoded as a 361 two integers representing the value of k and the granularity.) 363 3.1.2.2. Tributary Port Number Assignment 365 When multiplexing an ODUj into a HO ODUk (k>j), G.709 specifies the 366 information that has to be transported in-band in order to allow for 367 correct demultiplexing. This information, known as Multiplex 368 Structure Information (MSI), is transported in the OPUk overhead and 369 is organized as a set of entries, with one entry for each HO ODUj 370 TS. The information carried by each entry is: 372 Payload Type: the type of the transported payload. 374 Tributary Port Number (TPN): the port number of the ODUj 375 transported by the HO ODUk. The TPN is the same for all the TSs 376 assigned to the transport of the same ODUj instance. 378 For example, an ODU2 carried by a HO ODU3 is described by 4 entries 379 in the OPU3 overhead when the TS size is 2.5 Gbit/s, and by 8 entries 380 when the TS size is 1.25 Gbit/s. 382 The MSI information inserted in OPU3 overhead by the source of the HO 383 ODUk trail is checked by the sink of the HO ODUk trail. G.709 default 384 behavior requires that the multiplexing structure of the HO ODUk be 385 provided by means of pre-provisioned MSI information, termed 386 expectedMSI. The sink of the HO ODU trail checks the complete content 387 of the MSI information (including the TPN) that was received in-band, 388 termed acceptedMSI, against the expectedMSI. If the acceptedMSI is 389 different from the expectedMSI, then the traffic is dropped and a 390 payload mismatch alarm is generated. 392 Note that the values of the TPN MUST be either agreed between the 393 source and the sink of the HO ODU trail either via control plane 394 signaling or provisioning by the management plane. 396 4. Connection management in OTN 398 OTN-based connection management is concerned with controlling the 399 connectivity of ODU paths and optical channels (OCh). This document 400 focuses on the connection management of ODU paths. The management of 401 OCh paths is described in [WSON-FRAME]. 403 While [G872-2001] considered the ODU as a set of layers in the same 404 way as SDH has been modeled, recent ITU-T OTN architecture progress 405 [G872-Am2] includes an agreement to model the ODU as a single layer 406 network with the bit rate as a parameter of links and connections. 407 This allows the links and nodes to be viewed in a single topology as 408 a common set of resources that are available to provide ODUj 409 connections independent of the value of j. Note that when the bit 410 rate of ODUj is less than the server bit rate, ODUj connections are 411 supported by HO-ODU (which has a one-to-one relationship with the 412 OTU). 414 From an ITU-T perspective, the ODU connection topology is represented 415 by that of the OTU link layer, which has the same topology as that of 416 the OCh layer (independent of whether the OTU supports HO-ODU, where 417 multiplexing is utilized, or LO-ODU in the case of direct mapping). 418 Thus, the OTU and OCh layers should be visible in a single 419 topological representation of the network, and from a logical 420 perspective, the OTU and OCh may be considered as the same logical, 421 switchable entity. 423 Note that the OTU link layer topology may be provided via various 424 infrastructure alternatives, including point-to-point optical 425 connections, flexible optical connections fully in the optical domain, 426 flexible optical connections involving hybrid sub-lambda/lambda nodes 427 involving 3R, etc. 429 The document will be updated to maintain consistency with G.872 430 progress when it is consented for publication. 432 4.1. Connection management of the ODU 434 LO ODUj can be either mapped into the OTUk signal (j = k), or 435 multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is 436 mapped into an OCh. See Appendix A for more information. 438 From the perspective of control plane, there are two kinds of network 439 topology to be considered. 441 (1) ODU layer 443 In this case, the ODU links are presented between adjacent OTN nodes, 444 which is illustrated in Figure 2. In this layer there are ODU links 445 with a variety of TSes available, and nodes that are ODXCs. Lo ODU 446 connections can be setup based on the network topology. 448 Link #5 +--+---+--+ Link #4 449 +--------------------------| |--------------------------+ 450 | | ODXC | | 451 | +---------+ | 452 | Node E | 453 | | 454 +-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++ 455 | |Link #1 | |Link #2 | |Link #3 | | 456 | |--------| |--------| |--------| | 457 | ODXC | | ODXC | | ODXC | | ODXC | 458 +---------+ +---------+ +---------+ +---------+ 459 Node A Node B Node C Node D 461 Figure 2 - Example Topology for LO ODU connection management 463 If an ODUj connection is requested between Node C and Node E 464 routing/path computation must select a path that has the required 465 number of TS available and that offers the lowest cost. Signaling is 466 then invoked to set up the path and to provide the information (e.g., 467 selected TS) required by each transit node to allow the configuration 468 of the ODUj to OTUk mapping (j = k) or multiplexing (j < k), and 469 demapping (j = k) or demultiplexing (j < k). 471 (2) ODU layer with OCh switching capability 473 In this case, the OTN nodes interconnect with wavelength switched 474 node (e.g., ROADM,OXC) that are capable of OCh switching, which is 475 illustrated in Figure 3 and Figure 4. There are ODU layer and OCh 476 layer, so it is simply a MLN. OCh connections may be created on 477 demand, which is described in section 5.1. 479 In this case, an operator may choose to allow the underlined OCh 480 layer to be visible to the ODU routing/path computation process in 481 which case the topology would be as shown in Figure 4. In Figure 3 482 below, instead, a cloud representing OCH capable switching nodes is 483 represented. In Figure 3, the operator choice is to hide the real RWA 484 network topology. 486 Node E 487 Link #5 +--------+ Link #4 488 +------------------------| |------------------------+ 489 | ------ | 490 | // \\ | 491 | || || | 492 | | RWA domain | | 493 +-+-----+ +----+- || || ------+ +-----+-+ 494 | | | \\ // | | | 495 | |Link #1 | -------- |Link #3 | | 496 | +--------+ | | +--------+ + 497 | ODXC | | ODXC +--------+ ODXC | | ODXC | 498 +-------+ +---------+Link #2 +---------+ +-------+ 499 Node A Node B Node C Node D 501 Figure 3 - RWA Hidden Topology for LO ODU connection management 503 Link #5 +---------+ Link #4 504 +------------------------| |-----------------------+ 505 | +----| ODXC |----+ | 506 | +-++ +---------+ ++-+ | 507 | Node f | | Node E | | Node g | 508 | +-++ ++-+ | 509 | | +--+ | | 510 +-+-----+ +----+----+--| |--+-----+---+ +-----+-+ 511 | |Link #1 | | +--+ | |Link #3 | | 512 | +--------+ | Node h | +--------+ + 513 | ODXC | | ODXC +--------+ ODXC | | ODXC | 514 +-------+ +---------+ Link #2+---------+ +-------+ 515 Node A Node B Node C Node D 517 Figure 4 - RWA Visible Topology for LO ODUj connection management 519 In Figure 4, the cloud of previous figure is substitute by the real 520 topology. The nodes f, g, h are nodes with OCH switching capability. 522 In the examples (i.e., Figure 3 and Figure 4), we have considered the 523 case in which LO-ODUj connections are supported by OCh connection, 524 and the case in which the supporting underlying connection can be 525 also made by a combination of HO-ODU/OCh connections. 527 In this case, the ODU routing/path selection process will request an 528 HO-ODU/OCh connection between node C to node E from the RWA domain. 529 The connection will appear at ODU level as a Forwarding Adjacency, 530 which will be used to create the ODU connection. 532 5. GMPLS/PCE Implications 534 The purpose of this section is to provide a framework for extensions 535 of the current GMPLS protocol suite and the PCE applications and 536 protocols to encompass OTN enhancements and connection management. 538 5.1. Implications for LSP Hierarchy with GMPLS TE 540 The path computation for ODU connection request is based on the 541 topology of ODU layer, including OCh layer visibility. 543 The OTN path computation can be divided into two layers. One layer is 544 OCh/OTUk, the other is ODUj. [RFC4206] and [RFC4206bis] define the 545 mechanisms to accomplish creating the hierarchy of LSPs. The LSP 546 management of multiple layers in OTN can follow the procedures 547 defined in [RFC4206], [RFC4206bis] and related MLN drafts. 549 As discussed in section 4, the route path computation for OCh is in 550 the scope of WSON [WSON-Frame]. Therefore, this document only 551 considers ODU layer for ODU connection request. 553 For the ODU layers, in order to maintain compatibility with 554 introducing new [G709-V3] services (e.g., ODU0, ODUflex) into a 555 legacy network configuration (containing [G709-V1] or [G709-V2] OTN 556 equipment), it may be needed to consider introducing multi-stage 557 multiplexing capability in specific network transition scenarios. One 558 method for enabling multi-stage multiplexing is by introducing 559 dedicated boards in a few specific places in the network and 560 tunneling these new services through [G709-V1] or [G709-V2] 561 containers (ODU1, ODU2, ODU3), thus postponing the need to upgrade 562 every network element to [G709-V3] capabilities. In such case, one 563 ODUj connection can be nested into another ODUk connection, which 564 forms the LSP hierarchy in ODU layer. Here, [RFC4206], [RFC4206bis] 565 and [MLN-EXT] (including related modifications, if needed) are 566 relevant to connection set up. 568 5.2. Implications for GMPLS Signaling 570 The signaling function and Resource reSerVation Protocol-Traffic 571 Engineering (RSVP-TE) extensions are described in [RFC3471] and [RFC 572 3473]. For OTN-specific control, [RFC4328] defines signaling 573 extensions to support G.709 Optical Transport Networks Control as 574 defined in [G709-V1]. 576 As described in Section 2, [G709-V3] introduced some new features 577 that include the ODU0, ODU2e, ODU4 and ODUflex containers. The 578 mechanisms defined in [RFC4328] do not support such new OTN features, 579 and protocol extensions will be necessary to allow them to be 580 controlled by a GMPLS control plane. 582 5.2.1. Identifying OTN signals 584 [RFC4328] defines the LSP Encoding Type, the Switching Type and the 585 Generalized Protocol Identifier (Generalized-PID) constituting the 586 common part of the Generalized Label Request. The G.709 Traffic 587 Parameters are also defined in [RFC4328]. The following new signal 588 types have been added since [RFC4328] was published: 590 (1) New signal types of sub-lambda layer 592 Optical Channel Data Unit (ODUj): 593 - ODU0 594 - ODU2e 595 - ODU4 596 - ODUflex 598 (2) A new TS granularity (i.e., 1.25 Gbps) 600 (3) Signal type with variable bandwidth: 602 ODUflex has a variable bandwidth/bit rate BR and a bit rate 603 tolerance T. As described above the (node local) mapping process 604 must be aware of the bit rate and tolerance of the ODUj being 605 multiplexed in order to select the correct number of TS and the 606 fixed/variable stuffing bytes. Therefore, bit rate and bit rate 607 tolerance should be carried in the Traffic Parameter in the 608 signaling of connection setup request. 610 (4) Extended multiplexing hierarchy (For example, ODU0 into OTU2 611 multiplexing (with 1,25Gbps TS granularity).) 613 So the encoding provided in [RFC4328] needs to be extended to support 614 all the signal types and related mapping and multiplexing with all 615 kinds of TSs. Moreover, the extensions should consider the 616 extensibility to match future evolvement of OTN. 618 For item (1) and (3), new traffic parameters may need to be extended 619 in signaling message; 620 For item (2) and (4), new label should be defined to carry the exact 621 TS allocation information related to the extended multiplexing 622 hierarchy. 624 5.2.2. Tributary Port Number 626 The tributary port number may be assigned locally by the node at the 627 (traffic) ingress end of the link and in this case as described above 628 must be conveyed to the far end of the link as a "transparent" 629 parameter i.e. the control plane does not need to understand this 630 information. The TPN may also be assigned by the control plane when 631 establishing LSP. 633 5.2.3. Support for constraint signaling 635 How an ODUk connection service is transported within an operator 636 network is governed by operator policy. For example, the ODUk 637 connection service might be transported over an ODUk path over an 638 OTUk section, with the path and section being at the same rate as 639 that of the connection service. In this case, an entire lambda of 640 capacity is consumed in transporting the ODUk connection service. On 641 the other hand, the operator might leverage sub-lambda multiplexing 642 capabilities in the network to improve infrastructure efficiencies 643 within any given networking domain. In this case, ODUk multiplexing 644 may be performed prior to transport over various rate ODU servers 645 over associated OTU sections. 647 The identification of constraints and associated encoding in the 648 signaling for differentiating full lambda LSP or sub lambda LSP is 649 for further study. 651 5.3. Implications for GMPLS Routing 653 The path computation process should select a suitable route for a 654 ODUj connection request. In order to compute the lowest cost path it 655 must evaluate the number (and availability) of TSs on each candidate 656 link. The routing protocol should be extended to convey some 657 information to represent ODU TE topology. As described above the 658 number of TSs (on a link bundle), the bandwidth of the TS and the 659 maximum number that are available to convey a single ODUj must be 660 provided. 662 GMPLS Routing [RFC4202] defines Interface Switching Capability 663 Descriptor of TDM which can be used for ODU. However, some other 664 issues should also be considered which are discussed below. 666 Interface Switching Capability Descriptors present a new constraint 667 for LSP path computation. [RFC4203] defines the switching capability 668 and related Maximum LSP Bandwidth and the Switching Capability 669 specific information. When the Switching Capability field is TDM the 670 Switching Capability specific information field includes Minimum LSP 671 Bandwidth, an indication whether the interface supports Standard or 672 Arbitrary SONET/SDH, and padding. So routing protocol should be 673 extended when TDM is ODU type to support representation of ODU 674 switching information, especially the following requirements should 675 be considered: 677 - Support for carrying the link multiplexing capability 679 As discussed in section 3.1.2, many different types of ODUj can 680 be multiplexed into the same OTUk. For example, both ODU0 and 681 ODU1 may be multiplexed into ODU2. An OTU link may support one or 682 more types of ODUj signals. The routing protocol should be 683 capable of carrying this multiplexing capability. 685 - Support for carrying the TS granularity that the interface can 686 support 688 One type of ODUj can be multiplexed to an OTUk using different TS 689 granularity. For example, ODU1 can be multiplexed into ODU2 with 690 either 2.5Gbps TS granularity or 1.25G TS granularity. The 691 routing protocol should be capable of carrying the TS granularity 692 supported by the ODU interface. 694 - Support any ODU and ODUflex 696 The bit rate (i.e., bandwidth) of TS is dependent on the TS 697 granularity and the signal type of the link. For example, the 698 bandwidth of a 1.25G TS in an OTU2 is about 1.249409620 Gbps, 699 while the bandwidth of a 1.25G TS in an OTU3 is about 1.254703729 700 Gbps. 702 One LO ODU may need different number of TSs when multiplexed into 703 different HO ODUs. For example, for ODU2e, 9 TSs are needed when 704 multiplexed into an ODU3, while only 8 TSs are needed when 705 multiplexed into an ODU4. For ODUflex, the total number of TSs to 706 be reserved in a HO ODU equals the maximum of [bandwidth of 707 ODUflex / bandwidth of TS of the HO ODU]. 709 Therefore, the routing protocol must be capable of carrying the 710 necessary and sufficient link bandwidth information for 711 performing accurate route computation for any of the fixed rate 712 ODUs as well as ODUflex. 714 - Support for differentiating between link multiplexing capacity and 715 link rate capacity 717 When a network operator receives a request for a particular ODU 718 connection service, the operator governs the manner in which the 719 request is fulfilled in their network. Considerations include 720 deployed network infrastructure capabilities, associated policies 721 (e.g., at what link fill threshold should a particular higher- 722 rate ODUk be utilized), etc. Thus, for example, an ODU2 723 connection service request could be supported by: OTU2 links 724 (here the connection service rate is the same as the link rate), 725 a combination of OTU2 and OTU3 links, OTU3 links, etc. 727 Therefore, to allow the required flexibility, the routing 728 protocol should be capable of differentiating between these two 729 types of link capacity. 731 - Support different priorities for resource reservation 733 How many priorities levels should be supported depends on the 734 operator's policy. Therefore, the routing protocol should be 735 capable of supporting either no priorities or up to 8 priority 736 levels as defined in [RFC4202]. 738 - Support link bundling 740 Link bundling can improve routing scalability by reducing the 741 amount of TE links that has to be handled by routing protocol. 742 The routing protocol must be capable of supporting bundling 743 multiple OTU links, at the same or different line rates, between 744 a pair of nodes as a TE link. Note that link bundling is optional 745 and is implementation dependent. 747 As mentioned in Section 5.1, one method of enabling multi-stage 748 multiplexing is via usage of dedicated boards to allow tunneling of 749 new services through legacy ODU1, ODU2, ODU3 containers. Such 750 dedicated boards may have some constraints with respect to switching 751 matrix access; detection and representation of such constraints is 752 for further study. 754 5.4. Implications for Link Management Protocol (LMP) 756 As discussed in section 5.3, Path computation needs to know the 757 interface switching capability of links. The switching capability of 758 two ends of the link may be different, so the link capability of two 759 ends should be correlated. 761 The Link Management Protocol (LMP) [RFC4204] provides a control plane 762 protocol for exchanging and correlating link capabilities. 764 It is not necessary to use LMP to correlate link-end capabilities if 765 the information is available from another source such as management 766 configuration or automatic discovery/negotiation within the data 767 plane. 769 Note that LO ODU type information can be, in principle, discovered by 770 routing. Since in certain case, routing is not present (e.g. UNI case) 771 we need to extend link management protocol capabilities to cover this 772 aspect. In case of routing presence, the discovering procedure by LMP 773 could also be optional. 775 5.4.1. Correlating the Granularity of the TS 777 As discussed in section 3.1.2, the two ends of a link may support 778 different TS granularity. In order to allow interconnection the node 779 with 1.25Gb/s granularity must fall back to 2.5Gb/s granularity. 781 Therefore, it is necessary for the two ends of a link to correlate 782 the granularity of the TS. This ensures that both ends of the link 783 advertise consistent capabilities (for routing) and ensures that 784 viable connections are established. 786 5.4.2. Correlating the Supported LO ODU Signal Types 788 Many new ODU signal types have been introduced [G709-V3], such as 789 ODU0, ODU4, ODU2e and ODUflex. It is possible that equipment does not 790 support all the LO ODU signal types introduced by those new standards 791 or drafts. If one end of a link can not support a certain LO ODU 792 signal type, the link cannot be selected to carry such type of LO ODU 793 connection. 795 Therefore, it is necessary for the two ends of an HO ODU link to 796 correlate which types of LO ODU can be supported by the link. After 797 correlating, the capability information can be flooded by IGP, so 798 that the correct path for an ODU connection can be calculated. 800 5.5. Implications for Path Computation Elements 802 [PCE-APS] describes the requirements for GMPLS applications of PCE in 803 order to establish GMPLS LSP. PCE needs to consider the GMPLS TE 804 attributes appropriately once a PCC or another PCE requests a path 805 computation. The TE attributes which can be contained in the path 806 calculation request message from the PCC or the PCE defined in 808 [RFC5440] includes switching capability, encoding type, signal type, 809 etc. 811 As described in section 5.2.1, new signal types and new signals with 812 variable bandwidth information need to be carried in the extended 813 signaling message of path setup. For the same consideration, PCECP 814 also has a desire to be extended to carry the new signal type and 815 related variable bandwidth information when a PCC requests a path 816 computation. 818 6. Security Considerations 820 The use of control plane protocols for signaling, routing, and path 821 computation opens an OTN to security threats through attacks on those 822 protocols. The data plane technology for an OTN does not introduce 823 any specific vulnerabilities, and so the control plane may be secured 824 using the mechanisms defined for the protocols discussed. 826 For further details of the specific security measures refer to the 827 documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], 828 [RFC4204], and [RFC5440]). [GMPLS-SEC] provides an overview of 829 security vulnerabilities and protection mechanisms for the GMPLS 830 control plane. 832 7. IANA Considerations 834 This document makes not requests for IANA action. 836 8. Acknowledgments 838 We would like to thank Maarten Vissers for his review and useful 839 comments. 841 9. References 843 9.1. Normative References 845 [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol 846 LabelSwitching (GMPLS) Signaling Extensions for G.709 847 Optical Transport Networks Control", RFC 4328, Jan 2006. 849 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label 850 Switching (GMPLS) Signaling Functional Description", RFC 851 3471, January 2003. 853 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label 854 Switching (GMPLS) Signaling Resource ReserVation 855 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 856 3473, January 2003. 858 [RFC4201] K. Kompella, Y. Rekhter, Ed., "Link Bundling in MPLS 859 Traffic Engineering (TE)", RFC 4201, October 2005. 861 [RFC4202] K. Kompella, Y. Rekhter, Ed., "Routing Extensions in 862 Support of Generalized Multi-Protocol Label Switching 863 (GMPLS)", RFC 4202, October 2005. 865 [RFC4203] K. Kompella, Y. Rekhter, Ed., "OSPF Extensions in Support 866 of Generalized Multi-Protocol Label Switching (GMPLS)", 867 RFC 4203, October 2005. 869 [RFC4205] K. Kompella, Y. Rekhter, Ed., "Intermediate System to 870 Intermediate System (IS-IS) Extensions in Support of 871 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 872 4205, October 2005. 874 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, 875 October 2005. 877 [RFC4206] K. Kompella, Y. Rekhter, Ed., " Label Switched Paths (LSP) 878 Hierarchy with Generalized Multi-Protocol Label Switching 879 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 881 [RFC4206bis] K. Shiomoto, A. Farrel, "Procedures for Dynamically 882 Signaled Hierarchical Label Switched Paths", draft-ietf- 883 ccamp-lsp-hierarchy-bis-08.txt, February 2010. 885 [MLN-EXT] Dimitri Papadimitriou et al, "Generalized Multi-Protocol 886 Label Switching (GMPLS) Protocol Extensions for Multi- 887 Layer and Multi-Region Networks (MLN/MRN)", draft-ietf- 888 ccamp-gmpls-mln-extensions-12.txt, February 21, 2010. 890 [RFC5440] JP. Vasseur, JL. Le Roux, Ed.," Path Computation Element 891 (PCE) Communication Protocol (PCEP)", RFC 5440, March 892 2009. 894 [G709-V3] ITU-T, "Interfaces for the Optical Transport Network 895 (OTN)", G.709 Recommendation, December 2009. 897 9.2. Informative References 899 [G709-V1] ITU-T, "Interface for the Optical Transport Network 900 (OTN)," G.709 Recommendation and Amendment1, November 901 2001. 903 [G709-V2] ITU-T, "Interface for the Optical Transport Network 904 (OTN)," G.709 Recommendation, March 2003. 906 [G872-2001] ITU-T, "Architecture of optical transport networks", 907 November 2001 (11 2001). 909 [G872-Am2] Draft Amendment 2, ITU-T, "Architecture of optical 910 transport networks". 912 [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing 913 and wavelength assignment approaches for wavelength- 914 routed optical WDM networks", Optical Networks Magazine, 915 January 2000. 917 [WSON-FRAME] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS 918 and PCE Control of Wavelength Switched Optical Networks 919 (WSON)", draft-ietf-ccamp-rwa-wson-framework, work in 920 progress. 922 [PCE-APS] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai 923 Zhang, "Requirements for GMPLS applications of PCE", 924 draft-ietf-pce-gmpls-aps-req-01.txt, July 2009. 926 [GMPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS 927 Networks", Work in Progress, October 2009. 929 10. Authors' Addresses 931 Fatai Zhang 932 Huawei Technologies 933 F3-5-B R&D Center, Huawei Base 934 Bantian, Longgang District 935 Shenzhen 518129 P.R.China 937 Phone: +86-755-28972912 938 Email: zhangfatai@huawei.com 939 Dan Li 940 Huawei Technologies Co., Ltd. 941 F3-5-B R&D Center, Huawei Base 942 Bantian, Longgang District 943 Shenzhen 518129 P.R.China 945 Phone: +86-755-28973237 946 Email: danli@huawei.com 948 Han Li 949 China Mobile Communications Corporation 950 53 A Xibianmennei Ave. Xuanwu District 951 Beijing 100053 P.R. China 953 Phone: +86-10-66006688 954 Email: lihan@chinamobile.com 956 Sergio Belotti 957 Alcatel-Lucent 958 Optics CTO 959 Via Trento 30 20059 Vimercate (Milano) Italy 960 +39 039 6863033 962 Email: sergio.belotti@alcatel-lucent.it 964 11. Contributors 966 Jianrui Han 967 Huawei Technologies Co., Ltd. 968 F3-5-B R&D Center, Huawei Base 969 Bantian, Longgang District 970 Shenzhen 518129 P.R.China 972 Phone: +86-755-28972913 973 Email: hanjianrui@huawei.com 975 Malcolm Betts 976 Huawei Technologies Co., Ltd. 978 Email: malcolm.betts@huawei.com 980 Pietro Grandi 981 Alcatel-Lucent 982 Optics CTO 983 Via Trento 30 20059 Vimercate (Milano) Italy 984 +39 039 6864930 986 Email: pietro_vittorio.grandi@alcatel-lucent.it 988 Eve Varma 989 Alcatel-Lucent 990 1A-261, 600-700 Mountain Av 991 PO Box 636 992 Murray Hill, NJ 07974-0636 993 USA 994 Email: eve.varma@alcatel-lucent.com 996 APPENDIX A: ODU connection examples 998 This appendix provides a description of ODU terminology and 999 connection examples. This section is not normative, and is just 1000 intended to facilitate understanding. 1002 In order to transmit a client signal, an ODU connection must first be 1003 created. From the perspective of [G709-V3] and [G872-Am2], some types 1004 of ODUs (i.e., ODU1, ODU2, ODU3, ODU4) may assume either a client or 1005 server role within the context of a particular networking domain: 1007 (1) An ODUj client that is mapped into an OTUk server. For example, 1008 if a STM-16 signal is encapsulated into ODU1, and then the ODU1 is 1009 mapped into OTU1, the ODU1 is a LO ODU (from a multiplexing 1010 perspective). 1012 (2) An ODUj client that is mapped into an ODUk (j < k) server 1013 occupying several TSs. For example, if ODU1 is multiplexed into ODU2, 1014 and ODU2 is mapped into OTU2, the ODU1 is a LO ODU and the ODU2 is a 1015 HO ODU (from a multiplexing perspective). 1017 Thus, a LO ODUj represents the container transporting a client of the 1018 OTN that is either directly mapped into an OTUk (k = j) or 1019 multiplexed into a server HO ODUk (k > j) container. Consequently, 1020 the HO ODUk represents the entity transporting a multiplex of LO ODUj 1021 tributary signals in its OPUk area. 1023 In the case of LO ODUj mapped into an OTUk (k = j) directly, Figure 5 1024 give an example of this kind of LO ODU connection. 1026 In Figure 5, The LO ODUj is switched at the intermediate ODXC node. 1027 OCh and OTUk are associated with each other. From the viewpoint of 1028 connection management, the management of OTUk is similar with OCh. LO 1029 ODUj and OCh/OTUk have client/server relationships. 1031 For example, one LO ODU1 connection can be setup between Node A and 1032 Node C. This LO ODU1 connection is to be supported by OCh/OTU1 1033 connections, which are to be set up between Node A and Node B and 1034 between Node B and Node C. LO ODU1 can be mapped into OTU1 at Node A, 1035 demapped from it in Node B, switched at Node B, and then mapped into 1036 the next OTU1 and demapped from this OTU1 at Node C. 1038 | LO ODUj | 1039 +------------------------------(b)---------------------------+ 1040 | | OCh/OTUk | | OCh/OTUk | | 1041 | +--------(a)---------+ +--------(a)---------+ | 1042 | | | | | | 1043 +------++-+ +--+---+--+ +-++------+ 1044 | |EO| |OE| |EO| |OE| | 1045 | +--+----------------+--+ +--+----------------+--+ | 1046 | ODXC | | ODXC | | ODXC | 1047 +---------+ +---------+ +---------+ 1048 Node A Node B Node C 1050 Figure 5 - Connection of LO ODUj (1) 1052 In the case of LO ODUj multiplexing into HO ODUk, Figure 6 gives an 1053 example of this kind of LO ODU connection. 1055 In Figure 6, OCh, OTUk, HO ODUk are associated with each other. The 1056 LO ODUj is multiplexed/de-multiplexed into/from the HO ODU at each 1057 ODXC node and switched at each ODXC node (i.e. trib port to line port, 1058 line card to line port, line port to trib port). From the viewpoint 1059 of connection management, the management of these HO ODUk and OTUk 1060 are similar to OCh. LO ODUj and OCh/OTUk/HO ODUk have client/server 1061 relationships. When a LO ODU connection is setup, it will be using 1062 the existing HO ODUk (/OTUk/OCh) connections which have been set up. 1063 Those HO ODUk connections provide LO ODU links, of which the LO ODU 1064 connection manager requests a link connection to support the LO ODU 1065 connection. 1067 For example, one HO ODU2 (/OTU2/OCh) connection can be setup between 1068 Node A and Node B, another HO ODU3 (/OTU3/OCh) connection can be 1069 setup between Node B and Node C. LO ODU1 can be generated at Node A, 1070 switched to one of the 10G line ports and multiplexed into a HO ODU2 1071 at Node A, demultiplexed from the HO ODU2 at Node B, switched at Node 1072 B to one of the 40G line ports and multiplexed into HO ODU3 at Node B, 1073 demultiplexed from HO ODU3 at Node C and switched to its LO ODU1 1074 terminating port at Node C. 1076 | LO ODUj | 1077 +----------------------------(b)-----------------------------+ 1078 | | OCh/OTUk/HO ODUk | | OCh/OTUk/HO ODUk | | 1079 | +--------(c)---------+ +---------(c)--------+ | 1080 | | | | | | 1081 +------++-+ +--+---+--+ +-++------+ 1082 | |EO| |OE| |EO| |OE| | 1083 | +--+----------------+--+ +--+----------------+--+ | 1084 | ODXC | | ODXC | | ODXC | 1085 +---------+ +---------+ +---------+ 1086 Node A Node B Node C 1088 Figure 6 - Connection of LO ODUj (2) 1090 Intellectual Property 1092 The IETF Trust takes no position regarding the validity or scope of 1093 any Intellectual Property Rights or other rights that might be 1094 claimed to pertain to the implementation or use of the technology 1095 described in any IETF Document or the extent to which any license 1096 under such rights might or might not be available; nor does it 1097 represent that it has made any independent effort to identify any 1098 such rights. 1100 Copies of Intellectual Property disclosures made to the IETF 1101 Secretariat and any assurances of licenses to be made available, or 1102 the result of an attempt made to obtain a general license or 1103 permission for the use of such proprietary rights by implementers or 1104 users of this specification can be obtained from the IETF on-line IPR 1105 repository at http://www.ietf.org/ipr 1107 The IETF invites any interested party to bring to its attention any 1108 copyrights, patents or patent applications, or other proprietary 1109 rights that may cover technology that may be required to implement 1110 any standard or specification contained in an IETF Document. Please 1111 address the information to the IETF at ietf-ipr@ietf.org. 1113 The definitive version of an IETF Document is that published by, or 1114 under the auspices of, the IETF. Versions of IETF Documents that are 1115 published by third parties, including those that are translated into 1116 other languages, should not be considered to be definitive versions 1117 of IETF Documents. The definitive version of these Legal Provisions 1118 is that published by, or under the auspices of, the IETF. Versions of 1119 these Legal Provisions that are published by third parties, including 1120 those that are translated into other languages, should not be 1121 considered to be definitive versions of these Legal Provisions. 1123 For the avoidance of doubt, each Contributor to the IETF Standards 1124 Process licenses each Contribution that he or she makes as part of 1125 the IETF Standards Process to the IETF Trust pursuant to the 1126 provisions of RFC 5378. No language to the contrary, or terms, 1127 conditions or rights that differ from or are inconsistent with the 1128 rights and licenses granted under RFC 5378, shall have any effect and 1129 shall be null and void, whether published or posted by such 1130 Contributor, or included with or in such Contribution. 1132 Disclaimer of Validity 1134 All IETF Documents and the information contained therein are provided 1135 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1136 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1137 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1138 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1139 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 1140 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1141 FOR A PARTICULAR PURPOSE. 1143 Copyright Notice 1145 Copyright (c) 2010 IETF Trust and the persons identified as the 1146 document authors. All rights reserved. 1148 This document is subject to BCP 78 and the IETF Trust's Legal 1149 Provisions Relating to IETF Documents 1150 (http://trustee.ietf.org/license-info) in effect on the date of 1151 publication of this document. Please review these documents 1152 carefully, as they describe your rights and restrictions with respect 1153 to this document. Code Components extracted from this document must 1154 include Simplified BSD License text as described in Section 4.e of 1155 the Trust Legal Provisions and are provided without warranty as 1156 described in the Simplified BSD License.