idnits 2.17.1 draft-ietf-pce-pcep-stateful-pce-gmpls-00.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 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([Stateful-PCE]), 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 == Line 30 has weird spacing: '... months and ...' == Line 31 has weird spacing: '... at any time...' == Line 32 has weird spacing: '...ference mate...' == Line 617 has weird spacing: '... of these ...' == Line 618 has weird spacing: '...cluding thos...' == (3 more instances...) -- The document date (December 4, 2013) is 3790 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: 'Stateful-PCE' is mentioned on line 467, but not defined == Missing Reference: 'RFC 4655' is mentioned on line 87, but not defined == Missing Reference: 'RFC 5440' is mentioned on line 96, but not defined == Missing Reference: 'PCE-GMPLS' is mentioned on line 283, but not defined == Missing Reference: 'RFC5521' is mentioned on line 283, but not defined == Unused Reference: 'PCE-IA-WSON' is defined on line 510, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Xian Zhang 2 Internet-Draft Young Lee 3 Intended status: Standards Track Fatai Zhang 4 Huawei 5 Ramon Casellas 6 CTTC 7 Oscar Gonzalez de Dios 8 Telefonica I+D 9 Zafar Ali 10 Cisco Systems 12 Expires: June 5, 2014 December 4, 2013 14 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 15 Usage in GMPLS-controlled Networks 17 draft-ietf-pce-pcep-stateful-pce-gmpls-00.txt 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with 22 the provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as "work in 33 progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on June 5, 2014. 43 Abstract 45 The Path Computation Element (PCE) facilitates Traffic Engineering 46 (TE) based path calculation in large, multi-domain, multi-region, or 47 multi-layer networks. [Stateful-PCE] provides the fundamental PCE 48 communication Protocol (PCEP) extensions needed to support stateful 49 PCE functions, without specifying the technology-specific extensions. 50 This memo provides extensions required for PCEP so as to enable the 51 usage of a stateful PCE capability in GMPLS-controlled networks. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC-2119 [RFC2119]. 59 Table of Contents 61 Table of Contents .............................................. 2 62 1. Introduction ................................................ 3 63 2. PCEP Extensions ............................................. 3 64 2.1. Overview of Requirements................................ 3 65 2.2. Stateful PCE Capability Advertisement................... 4 66 2.2.1. PCE Capability Advertisement in Multi-layer Networks 4 67 2.3. LSP Delegation in GMPLS-controlled Networks............. 5 68 2.4. LSP Synchronization in GMPLS-controlled networks.........6 69 2.5. Modification of Existing PCEP Messages and Procedures....7 70 2.5.1. Use cases ......................................... 8 71 2.5.2. Modification for LSP Re-optimization ...............8 72 2.5.3. Modification for Route Exclusion ...................9 73 2.6. Additional Error Type and Error Values Defined..........10 74 3. IANA Considerations ........................................ 10 75 4. Manageability Considerations................................ 10 76 4.1. Requirements on Other Protocols and Functional Components 10 77 5. Security Considerations..................................... 11 78 6. Acknowledgement ............................................ 11 79 7. References ................................................. 11 80 7.1. Normative References................................... 11 81 7.2. Informative References................................. 11 82 8. Contributors' Address....................................... 12 83 Authors' Addresses ............................................ 13 85 1. Introduction 87 [RFC 4655] presents the architecture of a Path Computation Element 88 (PCE)-based model for computing Multiprotocol Label Switching (MPLS) 89 and Generalized MPLS (GMPLS) Traffic Engineering Label Switched 90 Paths (TE LSPs). To perform such a constrained computation, a PCE 91 stores the network topology (i.e., TE links and nodes) and resource 92 information (i.e., TE attributes) in its TE Database (TED). To 93 request path computation services to a PCE, [RFC 5440] defines the 94 PCE communication Protocol (PCEP) for interaction between a Path 95 Computation Client (PCC) and a PCE, or between two PCEs. PCEP as 96 specified in [RFC 5440] mainly focuses on MPLS networks and the PCEP 97 extensions needed for GMPLS-controlled networks are provided in 98 [PCEP-GMPLS]. 100 Stateful PCEs are shown to be helpful in many application scenarios, 101 in both MPLS and GMPLS networks, as illustrated in [Stateful-APP]. 102 In order for these applications to able to exploit the capability of 103 stateful PCEs, extensions to the PCE communication protocol (i.e., 104 PCEP) are required. 106 [Stateful-PCE] provides the fundamental extensions needed for 107 stateful PCE to support general functionality, but leaves out the 108 specification for technology-specific objects/TLVs. Complementarily, 109 this document focuses on the extensions that are necessary in order 110 for the deployment of stateful PCEs in GMPLS-controlled networks. 112 2. PCEP Extensions 114 2.1. Overview of Requirements 116 This section notes the main functional requirements for PCEP 117 extensions to support stateful PCE for use in GMPLS-controlled 118 networks, based on the description in [Stateful-APP]. Many 119 requirements are common across a variety of network types (e.g., 120 MPLS-TE networks and GMPLS networks) and the protocol extensions to 121 meet the requirements are already described in [Stateful-PCE]. This 122 document does not repeat the description of those protocol 123 extensions. Other requirements that are also common across a variety 124 of network types do not currently have protocol extensions defined 125 in [Stateful-PCE]. In these cases, this document presents protocol 126 extensions for discussion by the PCE working group and potential 127 inclusion in [Stateful-PCE]. In addition, this document presents 128 protocol extensions for a set of requirements which are specific to 129 the use of a stateful PCE in a GMPLS-controlled network. 131 The basic requirements are as follows: 133 o Advertisement of the stateful PCE capability. This generic 134 requirement is covered in Section 7.1.1 of [Stateful-PCE]. 135 Section 2.2 of this document discusses other potential extensions 136 for this functionality. 138 o LSP delegation is already covered in Section 5.5 of [Stateful-PCE]. 139 Section 2.3 of this document provides extension for its 140 application in GMPLS-controlled networks. Moreover, further 141 discussion of some generic details that may need additional 142 consideration is provided. 144 o LSP state synchronization. This is a generic requirement already 145 covered in Section 5.4 of [Stateful-PCE]. However, there are 146 further extensions required specifically for GMPLS-controlled 147 networks and discussed in Section 2.4. Reference to LSPs by 148 identifiers is discussed in Section 7.2 of [Stateful-PCE]. This 149 feature can be applied to reduce the data carried in PCEP messages. 150 Use cases and additional Error Codes are necessary, as described 151 in Section 2.5 and 2.6. 153 2.2. Stateful PCE Capability Advertisement 155 Whether a PCE has stateful capability or not can be advertised 156 during the PCEP session establishment process. It can also be 157 advertised through routing protocols as described in [RFC5088]. In 158 either case, the following additional aspects should also be 159 considered. 161 2.2.1. PCE Capability Advertisement in Multi-layer Networks 163 In multi-layer network scenarios, such as an IP-over-optical network, 164 if there are dedicated PCEs responsible for each layer, then the 165 PCCs should be informed of which PCEs they should synchronize their 166 LSP states with, as well as send path computation requests to. The 167 Layer-Cap TLV defined in [INTER-LAYER] can be used to indicate which 168 layer a PCE is in charge of. (Editor's note: this change is 169 currently not included in the current version of the [INTER-LAYER] 170 draft. It is expected that it will be included in its next version.) 171 This TLV is optional and MAY be carried in the OPEN object. It is 172 RECOMMMENDED that a PCC synchronizes its LSP states with the same 173 PCEs that it can use for path computation in a multi-layer network. 174 In a single layer, this TLV MAY not be used. However, if the PCE 175 capability discovery depends on IGP and if an IGP instance spans 176 across multiple layers, this TLV is still needed. 178 Alternatively, the extension to current OSPF PCED TLV is needed. A 179 new domain-type denoting the layer information can be defined: 181 domain-type: T.B.D. 183 When it is carried in PCE-DOMAIN sub-TLV, it denotes the layer for 184 which a PCE is responsible for path computation as well as LSP state 185 synchronization. When carried in the PCE-NEIG-DOMAIN sub-TLV, it 186 denotes its adjacent layers for which a PCE can compute paths and 187 synchronize the LSP states. The DOMAIN-ID information can be 188 represented using the following format, to denote the layer 189 information: 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | LSP Enc. Type | Switching Type| Reserved | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 2.3. LSP Delegation in GMPLS-controlled Networks 199 To enable the PCE to control an LSP, the PCUpd message is defined in 200 [Stateful-PCE]. However, the specification of technology specific 201 extensions is not covered. The following defines the 202 descriptor, present in the PCUpd message, that should be used in 203 GMPLS-controlled networks: 205 ::= 207 Where: 209 ::= [] 211 [] 213 [...] 215 [] 217 ::= [] 219 As explained in [stateful-APP], LSP parameter update controlled by a 220 stateful PCE in a multi-domain network is complex and requires well- 221 defined operational procedures as well as protocol design. 223 [TBD: protocol extensions] 225 2.4. LSP Synchronization in GMPLS-controlled networks 227 For LSP state synchronization of stateful PCEs in GMPLS networks, 228 the LSP attributes, such as its bandwidth, associated route as well 229 as protection information etc, should be updated by PCCs to PCE LSP 230 database (LSP-DB). Note the LSP state synchronization described in 231 this document denotes both the bulk LSP report at the initialization 232 phase as well as the LSP state report afterwards described in 233 [Stateful-PCE]. 235 As per [Stateful-PCE], it does not cover technology-specific 236 specification for state synchronization. Therefore, extensions of 237 PCEP for stateful PCE usage in GMPLS networks are required. For LSP 238 state synchronization, the objects/TLVs that should be used for 239 stateful PCE in GMPLS networks are defined in [PCEP-GMPLS] and are 240 briefly summarized as below: 242 o GENERALIZED BANDWIDTH 244 o GENERALIZED ENDPOINTS 246 o PROTECTION ATTRIBUTE 248 o Use of IF_ID_ERROR_SPEC. [Stateful-PCE] section 7.2.2 only 249 considers RSVP ERROR_SPEC TLVs. GMPLS extends this to also support 250 IF_ID_ERROR_SPEC, for example, to report about failed unnumbered 251 interfaces. 253 o Extended objects to support the inclusion of the label and 254 unnumbered links. 256 Per [Stateful-PCE], the PCRpt message is defined for LSP state 257 synchronization purposes. PCRpt is used by a PCC to report one or 258 more of its LSPs to a stateful PCE. However, the descriptor 259 is technology-specific and left undefined. 261 For LSP state synchronization in GMPLS-controlled networks, the 262 encoding of the descriptor is defined as follows: 264 ::= 266 Where: 268 ::= [] 270 [] 272 [...] 274 [] 276 [] 278 [] 280 ::= [] 282 The objects included in the descriptor can be found in 283 [RFC5440], [PCE-GMPLS] and [RFC5521]. 285 For all the objects presented in this section, the P and I bit MUST 286 be set to 0 since they are only used by a PCC to report its LSP 287 information. 289 In GMPLS-controlled networks, the object may include a list of 290 the label sub-object for SDH/SONET, OTN and DWDM networks. It may 291 also include a list of unnumbered interface IDs to denote the 292 allocated resource. The , and objects MAY include 293 unnumbered interface IDs and labels for networks such as OTN and WDM 294 networks. 296 If the LSP being reported is a protecting LSP, the TLV MUST be included in the object to denote its 298 attributes and restrictions. Moreover, if the status of the 299 protecting LSP changes from non-operational to operational, this 300 should be synchronized to the stateful PCE. For example, in 1:1 301 protection, the combination of S=0, P=1 and O=0 denotes the 302 protecting path is set up already but not used for carrying traffic. 303 Upon the working path failure, the operational status of the 304 aforementioned protecting LSP changes to in-use (i.e., O=1). This 305 information should be synchronized with a stateful PCE through a 306 PCRpt message. 308 The O bit in the object has no meaning for 309 LSP state synchronization and MUST be set to 0. Furthermore, this 310 object MAY appear twice, one with R set to 1 and the other with R 311 set to 0. This is to denote the asymmetric bandwidth property of the 312 updated bi-directional LSP. 314 2.5. Modification of Existing PCEP Messages and Procedures 316 One of the advantages mentioned in [Stateful-APP] is that the 317 stateful nature of a PCE simplifies the information conveyed in PCEP 318 messages, notably between PCC and PCE, since it is possible to refer 319 to PCE managed state for active LSPs. To be more specific, with a 320 stateful PCE, it is possible to refer to a LSP with a unique 321 identifier in the scope of the PCC-PCEP session and thus use such 322 identifier to refer to that LSP. 324 2.5.1. Use cases 326 Use Case 1: Assuming a stateful PCE's LSP-DB is up-to-date, a PCC 327 (e.g. NMS) requesting for a re-optimization of one or several LSPs 328 can send the request with "R" bit set and only provides the relevant 329 LSP unique identifiers. 331 Upon receiving the PCReq message, PCE should be able to correlate 332 with one or multiple LSPs with their detailed state information and 333 carry out optimization accordingly. 335 The handling of RP object specified in [RFC5440] is stated as 336 following: 338 "The absence of an RRO in the PCReq message for a non-zero-bandwidth 339 TE LSP (when the R bit of the RP object is set) MUST trigger the 340 sending of a PCErr message with Error-Type="Required Object Missing" 341 and Error-value="RRO Object missing for re-optimization." 343 If a PCE has stateful capabilities, and such capabilities have been 344 negotiated and advertised, specific rules given in [RFC5440] may 345 need to be relaxed. In particular, the re-optimization case: if the 346 re-optimization request refers to a given LSP state, and the RRO 347 information is available, the PCE can proceed. 349 Use Case 2: in order to set up a LSP which has a constraint that its 350 route should not use resources used by one or more existing LSPs, a 351 PCC can send a PCReq with the identifiers of these LSPs. A stateful 352 PCE should be able to find the corresponding route and resource 353 information so as to meet the constraints set by the requesting PCC. 354 Hence, the LSP identifier TLV defined in [Stateful-PCE] can be used 355 in XRO object for this purpose. Note that if the PCC is a node in 356 the network, the constraint LSP ID information will be confined to 357 the LSPs initiated by itself. 359 2.5.2. Modification for LSP Re-optimization 361 For re-optimization, upon receiving a path computation request and 362 the "R" bit is set, the stateful PCE SHOULD still perform the re- 363 optimization in the following two cases: 365 Case 1: the existing bandwidth and route information of the to-be- 366 optimized LSP is provided in the path computation request. This 367 information should be provided via , , objects. 370 Case 2: the existing bandwidth and route information can be found 371 locally in its LSP-DB. In this case, the PCRep and PCReq messages 372 need to be modified to carry LSP identifiers. The stateful PCE can 373 find this information using the per-node LSP ID together with the 374 PCC's address. 376 If no LSP state information is available to carry out re- 377 optimization, the stateful PCE should report the error "LSP state 378 information unavailable for the LSP re-optimization" (Error Type = 379 T.B.D., Error value= T.B.D.). 381 2.5.3. Modification for Route Exclusion 383 A LSP identifier sub-object is defined and its format as follows: 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 |L| Type (T.B.D.) | Length | Reserved | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | PLSP-ID | Flag | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | | 393 // Optional TLVs // 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 L bit: 397 The L bit SHOULD NOT be set, so that the subobject represents 398 a strict hop in the explicit route. 400 Type: 401 Subobject Type for a per-node LSP identifier. 403 Length: 404 The Length contains the total length of the subobject in bytes, 405 including the Type and Length fields. 407 PLSP-ID: 408 This is the identifier given to a LSP and it is unique on a 409 node basis. It is defined in [Stateful-PCE]. 411 Flags: 412 This field is defined in [Stateful-PCE]. It is not used in 413 this sub-object and should be ignored upon receipt. 415 Optional TLVs: 416 Additional TLVs can be defined in the future to provide 417 further information to identify a LSP. In this document, no TLVs are 418 defined. 420 One or multiple of these sub-objects can be present in the XRO 421 object. When a stateful PCE receives a path computation request 422 carrying this sub-object, it should find relevant information of 423 these LSPs and preclude the resource during the path computation 424 process. If a stateful PCE cannot recognize one or more of the 425 received LSP identifiers, it should reply PCErr saying "the LSP 426 state information for route exclusion purpose cannot be found" 427 (Error-type = T.B.D., Error-value= T.B.D.). Optionally, it may 428 provide with the unrecognized identifier information to the 429 requesting PCC. 431 2.6. Additional Error Type and Error Values Defined 433 Error Type Meaning 435 21(TBD) LSP state information missing 437 Error-value 1: LSP state information unavailable for the 438 LSP re-optimization 440 Error-value 2: the LSP state information for route 441 exclusion purpose cannot be found 443 3. IANA Considerations 445 IANA is requested to allocate new Types for the TLV/Object defined 446 in this document.T.B.D. 448 4. Manageability Considerations 450 The description and functionality specifications presented related 451 to stateful PCEs should also comply with the manageability 452 specifications covered in Section 8 of [RFC4655]. Furthermore, a 453 further list of manageability issues presented in [Stateful-PCE] 454 should also be considered. 456 Additional considerations are presented in the next sections. 458 4.1. Requirements on Other Protocols and Functional Components 460 When the detailed route information is included for LSP state 461 synchronization (either at the initial stage or during LSP state 462 report process), this require the ingress node of an LSP carry the 463 RRO object in order to enable the collection of such information. 465 5. Security Considerations 467 The security issues presented in [RFC5440] and [Stateful-PCE] apply 468 to this document. 470 6. Acknowledgement 472 We would like to thank Adrian Farrel and Cyril Margaria for the 473 useful comments and discussions. 475 7. References 477 7.1. Normative References 479 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 480 requirements levels", RFC 2119, March 1997. 482 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 483 Computation Element (PCE)-Based Architecture", RFC 4655, 484 August 2006. 486 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 487 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 488 March 2009. 490 [RFC5088] Le Roux, JL., Vasseur, J.-P., Ikejiri, Y., Zhang, R., 491 "OSPF Protocol Extensions for Path Computation Element 492 (PCE) Discovery", RFC 5088, January 2008. 494 [INTER-LAYER] Oki, E., Takeda, Tomonori, Le Roux, JL., Farrel, A., 495 Zhang, F., "Extensions to the Path Computation Element 496 communication Protocol (PCEP) for Inter-Layer MPLS and 497 GMPLS Traffic Engineering", draft-ietf-pce-inter-layer-ext, 498 work in progress. 500 7.2. Informative References 502 [Stateful-APP] Zhang, X., Minei, I., et al "Applicability of 503 Stateful Path Computation Element (PCE) ", draft-ietf-pce- 504 stateful-pce-app, , work in progress. 506 [Stateful-PCE]Crabbe, E., Medved, J., Varga, R., Minei, I., "PCEP 507 Extensions for Stateful PCE", draft-ietf-pce-stateful-pce, 508 work in progress. 510 [PCE-IA-WSON] Lee, Y., Bernstein G., Takeda, T., Tsuritani, T., 511 "PCEP Extensions for WSON Impairments", draft-lee-pce- 512 wson-impairments, work in progress. 514 [PCEP-GMPLS] Margaria, C., Gonzalez de Dios, O., Zhang, F., "PCEP 515 extensions for GMPLS", draft-ietf-pce-gmpls-pcep- 516 extensions, work in progress. 518 8. Contributors' Address 520 Dhruv Dhody 521 Huawei Technology 522 Leela Palace 523 Bangalore, Karnataka 560008 524 INDIA 526 EMail: dhruvd@huawei.com 528 Yi Lin 529 Huawei Technologies 530 F3-5-B R&D Center, Huawei Base 531 Bantian, Longgang District 532 Shenzhen 518129 P.R.China 534 Phone: +86-755-28972914 535 Email: yi.lin@huawei.com 537 Authors' Addresses 539 Xian Zhang 540 Huawei Technologies 541 F3-5-B R&D Center, Huawei Base 542 Bantian, Longgang District 543 Shenzhen 518129 P.R.China 545 Phone: +86-755-28972645 546 Email: zhang.xian@huawei.com 548 Young Lee 549 Huawei 550 1700 Alma Drive, Suite 100 551 Plano, TX 75075 552 US 554 Phone: +1 972 509 5599 x2240 555 Fax: +1 469 229 5397 556 EMail: ylee@huawei.com 558 Fatai Zhang 559 Huawei 560 F3-5-B R&D Center, Huawei Base 561 Bantian, Longgang District 562 P.R. China 564 Phone: +86-755-28972912 565 Email: zhangfatai@huawei.com 567 Ramon Casellas 568 CTTC 569 Av. Carl Friedrich Gauss n7 570 Castelldefels, Barcelona 08860 571 Spain 573 Phone: 574 Email: ramon.casellas@cttc.es 576 Oscar Gonzalez de Dios 577 Telefonica Investigacion y Desarrollo 578 Emilio Vargas 6 579 Madrid, 28045 580 Spain 581 Phone: +34 913374013 582 Email: ogondio@tid.es 584 Zafar Ali 585 Cisco Systems 586 Email: zali@cisco.com 588 Intellectual Property 590 The IETF Trust takes no position regarding the validity or scope of 591 any Intellectual Property Rights or other rights that might be 592 claimed to pertain to the implementation or use of the technology 593 described in any IETF Document or the extent to which any license 594 under such rights might or might not be available; nor does it 595 represent that it has made any independent effort to identify any 596 such rights. 598 Copies of Intellectual Property disclosures made to the IETF 599 Secretariat and any assurances of licenses to be made available, or 600 the result of an attempt made to obtain a general license or 601 permission for the use of such proprietary rights by implementers or 602 users of this specification can be obtained from the IETF on-line 603 IPR repository at http://www.ietf.org/ipr 605 The IETF invites any interested party to bring to its attention any 606 copyrights, patents or patent applications, or other proprietary 607 rights that may cover technology that may be required to implement 608 any standard or specification contained in an IETF Document. Please 609 address the information to the IETF at ietf-ipr@ietf.org. 611 The definitive version of an IETF Document is that published by, or 612 under the auspices of, the IETF. Versions of IETF Documents that are 613 published by third parties, including those that are translated into 614 other languages, should not be considered to be definitive versions 615 of IETF Documents. The definitive version of these Legal Provisions 616 is that published by, or under the auspices of, the IETF. Versions 617 of these Legal Provisions that are published by third parties, 618 including those that are translated into other languages, should 619 not be considered to be definitive versions of these Legal 620 Provisions. 622 For the avoidance of doubt, each Contributor to the IETF Standards 623 Process licenses each Contribution that he or she makes as part of 624 the IETF Standards Process to the IETF Trust pursuant to the 625 provisions of RFC 5378. No language to the contrary, or terms, 626 conditions or rights that differ from or are inconsistent with the 627 rights and licenses granted under RFC 5378, shall have any effect 628 and shall be null and void, whether published or posted by such 629 Contributor, or included with or in such Contribution. 631 Disclaimer of Validity 633 All IETF Documents and the information contained therein are 634 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 635 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 636 SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 637 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 638 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN 639 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 640 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 642 Full Copyright Statement 644 Copyright (c) 2013 IETF Trust and the persons identified as the 645 document authors. All rights reserved. 647 This document is subject to BCP 78 and the IETF Trust's Legal 648 Provisions Relating to IETF Documents 649 (http://trustee.ietf.org/license-info) in effect on the date of 650 publication of this document. Please review these documents 651 carefully, as they describe your rights and restrictions with 652 respect to this document. Code Components extracted from this 653 document must include Simplified BSD License text as described in 654 Section 4.e of the Trust Legal Provisions and are provided without 655 warranty as described in the Simplified BSD License.