idnits 2.17.00 (12 Aug 2021) /tmp/idnits29827/draft-zhang-pce-pcep-extensions-for-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 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3209' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'RFC3477' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'RFC4872' is defined on line 565, but no explicit reference was found in the text == Unused Reference: 'RFC4873' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'RFC4606' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 592, but no explicit reference was found in the text == Unused Reference: 'RFC4657' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'RFC4674' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'RFC5088' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 613, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-REQ' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Normative reference to a draft: ref. 'OTN-SIG' == Outdated reference: draft-ietf-ccamp-ethernet-traffic-parameters has been published as RFC 6003 Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Fatai Zhang 2 Internet Draft Suresh B R 3 Young Lee 4 SenthilKumarS 5 Category: Standards Track Jun Sun 6 Huawei 7 Expires: August 20, 2010 February 21 2010 9 Extensions to the Path Computation Element Communication Protocol for 10 Traffic Engineering Label Switched Paths in GMPLS Networks 12 draft-zhang-pce-pcep-extensions-for-gmpls-00.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with 17 the provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 20, 2010. 37 Abstract 39 This document defines the extensions for the Path Computation Element 40 Communication Protocol (PCEP) to support the establishment of TE LSPs 41 in GMPLS networks. 43 Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in [RFC2119]. 49 Table of Contents 51 1. Introduction.................................................2 52 1.1. Requirements Language...................................3 53 2. Terminology..................................................3 54 3. PCEP Requirements............................................3 55 4. Protocol Procedure and Extensions............................4 56 4.1. SWITCH-LAYER Object.....................................4 57 4.2. END-POINTS Object Extension.............................4 58 4.2.1. Destination Prefix Information TLV.................4 59 4.3. New Object - QoS........................................5 60 4.3.1. Traffic Parameters TLV.............................6 61 4.3.2. LSP Protection Information TLV.....................7 62 4.3.3. SWITCH-LAYER and QoS Object in PCReq and PCRep.....7 63 4.4. NO-PATH Object Extension................................8 64 4.4.1. Extensions to NO-PATH-VECTOR TLV...................9 65 4.5. Additional Error Type and Error Values Defined..........9 66 5. Liveness Detection and Monitoring...........................10 67 6. IANA Considerations.........................................10 68 6.1. New PCEP Object........................................10 69 6.2. New PCEP TLVs..........................................11 70 6.3. PCEP NO-PATH-VECTOR TLV Flag Field.....................11 71 6.4. New PCEP Error Codes...................................12 72 7. Security Considerations.....................................12 73 8. Acknowledgements............................................12 74 9. References..................................................12 75 9.1. Normative References...................................12 76 9.2. Informative References.................................14 77 10. Authors' Addresses.........................................14 79 1. Introduction 81 RFC4655 defines the PCE based architecture and explains how a PCE may 82 compute LSPs in MPLS Traffic Engineering (TE) and GMPLS) networks at 83 the request of Path Computation Clients (PCCs). 85 RFC5440 specifies the PCEP for communication between a PCC and a PCE, 86 or between two PCEs, in compliance with RFC4657. However, that it 87 does not provide a mechanism to request path computation for 88 establishing TE LSPs in GMPLS networks such as SDH network. [GMPLS- 89 REQ] addresses the functional requirements for GMPLS in PCE 90 application. 92 This document describes the protocol extensions to PCEP to support 93 path computation for TE LSP in GMPLS networks. 95 1.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC2119. 101 2. Terminology 103 The following terminology is used in this document. 105 PCC: Path Computation Client. Any client application requesting a 106 path computation to be performed by the Path Computation 107 Element. 109 PCE: Path Computation Element. An entity (component, application, or 110 network node) that is capable of computing a network path or 111 route based on a network graph and applying computational 112 constraints. 114 PCEP: Path Computation Element Communication Protocol. PCEP is a 115 request/response protocol used for the communication between a 116 PCC and a PCE, or between two PCEs. 118 PCEP Peer: An element involved in a PCEP session (For example, a PCC 119 or a PCE). 121 PCEP Session: The PCEP session is a logical connection established 122 automatically between the PCEP peers. 124 This document also uses the terminology defined in RFC4655, and 125 RFC5440. 127 3. PCEP Requirements 129 This section summarizes the PCEP extensions for GMPLS. This document 130 introduces no new messages for PCEP. However, extensions have been 131 introduced to the existing PCEP objects, sub-objects and TLVs. Also, 132 a few new objects and TLVs have been introduced to support network 133 type and QoS. The details on the PCEP objects and TLVs are mentioned 134 below: 136 Enhanced Objects 138 o PCEP End Point (IPv4/Node ID) Object 139 o PCEP NO-PATH Object 141 Newly Introduced Object 143 o PCEP QoS Object 145 Newly Introduced TLVs 147 o Destination Prefix Information 148 o Traffic Parameters 149 o LSP Protection Information 151 4. Protocol Procedure and Extensions 153 4.1. SWITCH-LAYER Object 155 The PCE architecture can be extended to support various network types 156 such as SDH, WDM, OTN, and PTN and so on. PCE MAY select the 157 appropriate policy profile depending on the current path request 158 which is applicable to a particular network type. 160 The SWITCH-LAYER object is an OPTIONAL object and MUST be carried 161 only in PCReq and PCRep message specifying the encoding and switching 162 type of the network, to which the path request belongs to. This 163 object is defined in [INTER-LAYER] (Section 3.2). 165 4.2. END-POINTS Object Extension 167 The END-POINTS object is used in a PCReq message to specify the 168 source IP address and the destination IP address of the path for 169 which a path computation is requested. New OPTIONAL TLV is defined 170 that is to be carried in the END-POINTS object for the path that 171 depends on destination prefix information. 173 4.2.1. Destination Prefix Information TLV 175 The Destination Prefix Information TLV is a new OPTIONAL TLV. It MUST 176 only appear inside END-POINTS (IPv4/Node ID) object. The receiver 177 SHOULD ignore the Destination Prefix Information TLV if it appears in 178 any other object other than END-POINTS object. This TLV contains the 179 prefix length for the destination IPv4 address and will appear when 180 prefix length is in the range between 0 and 32 (inclusive). 182 The format of the Destination Prefix Information TLV is as follows: 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Type = 20 | Length = 4 | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Destination | Flags |E| Reserved | 190 | Prefix Length | Field |M| | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Destination Prefix Length (8-bits) - Specifies the prefix length of 194 the destination IPv4 address. 196 Flags Field (7-bits) - Reserved for future to define new flags. It 197 MUST be filled with zeros and SHOULD be ignored by the receiver. 199 EM- Exact Prefix Match (1-bit) - Specifies whether exact prefix match 200 is required for the destination IPv4 address. 202 Bit EM Type 204 0 Exact prefix match is not required 206 1 Exact prefix match is required 208 Reserved (16-bits) - Reserved. MUST be set to zero and SHOULD be 209 ignored by the receiver. 211 4.3. New Object - QoS 213 When a PCC requests a PCE for a route, and if PCE provides the 214 response to the request, it MAY be useful for the PCC and the PCE to 215 include the traffic parameters. These traffic parameters specify a 216 base set of capabilities for GMPLS networks such as Service Level 217 Agreement (SLA), protection scheme, segment recovery, concatenation, 218 transparency, and so on. The QoS object handles the quality of 219 service parameters for TE-LSPs in GMPLS networks. 221 The QoS object can be included in the PCReq and PCRep messages by the 222 PCC and PCE respectively. It represents the parameters that become 223 necessary to manage bandwidth in the networks. When a PCE cannot find 224 a path by satisfying a set of constraints requested by the PCC, the 225 PCE may also include the original constraint so as to indicate the 226 reason for an unsuccessful computation in the NO-PATH object. Based 227 on the available service parameters proposed by a PCE, the PCC MAY 228 decide to resend the path requests. These parameters ensure that the 229 applications are guaranteed the network resources they need, despite 230 varying traffic load. 232 The format of the QoS object is as follows: 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Object Class | OT |Res|P|I| Object Length | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | 240 // Traffic Parameters TLV // 241 | | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 // LSP Protection Information TLV // 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Object Class (8-bits) - Specifies the class of the object (Value = 247 25). 249 OT - Object Type (4-bits) - Specifies the type of the object (Value = 250 1). 252 4.3.1. Traffic Parameters TLV 254 For different networks, different traffic parameters should be 255 embedded in the Traffic Parameters TLV, which is a new OPTIONAL TLV. 256 The following types are defined currently: 258 Object Type Name Remarks 260 34 SDH-Traffic SDH/Sonet networks 262 35 G.709-Traffic OTN digital wrapper 264 36 WSON-Traffic WSON 266 37 Ethernet-Traffic Ethernet 268 38 PTN TBD 270 For SDH-Traffic, the contents of this object are identical in 271 encoding to the contents of the Resource Reservation Protocol Traffic 272 Engineering Extensions (RSVP-TE)SONET and SDH Parameters defined in 273 RFC4606 (section 2.1). 275 For G.709-Traffic, the contents of this object are identical with the 276 Traffic Parameters defined in [OTN-SIG]. 278 For WSON-Traffic and Ethernet-Traffic, we can refer to [WSON-SIG] and 279 [Eth-Traffic]. 281 4.3.2. LSP Protection Information TLV 283 The LSP Protection Information TLV is a new OPTIONAL TLV and MUST 284 only appear inside QoS object. This TLV contains the LSP recovery 285 attributes, LSP association and protection constraints that are 286 required during signaling to support end-to-end LSP recovery. 288 The information of end-to-end LSP recovery during GMPLS signaling is 289 already defined in RFC4872 and RFC4873. Henceforth, the contents of 290 LSP Protection Information TLV defined in this document is identical 291 to the Protection Object defined in RFC4873 (section 6.1). 293 LSP Protection Information TLV type is 40. 295 4.3.3. SWITCH-LAYER and QoS Object in PCReq and PCRep 297 As mentioned earlier the SWITCH-LAYER and QoS object MAY be included 298 in the PCReq message. These objects are OPTIONAL, and if QoS object 299 is present only one instance of SDH-ASON QoS parameters TLV or LSP 300 protection TLV must be included. If multiple instances of TLV or some 301 other TLV is present, then the complete message has to be discarded 302 without performing any further processing. 304 The format of the PCReq message including the SWITCH-LAYER and QoS 305 object is as follows: 307 ::= 308 [] 309 311 where: 313 ::= [] 315 ::= [] 317 ::= 318 319 320 [] 321 [] 322 [] 323 [] 324 [[]] 325 [] 326 [] 328 The format of the PCRep message is as follows: 330 ::= 331 333 where: 335 ::= [] 337 ::= 338 339 [] 340 [] 341 [] 343 ::= [] 345 ::= 347 where: 349 ::= [] 350 [] 351 [] 352 [] 353 [] 355 ::= [] 357 4.4. NO-PATH Object Extension 359 The NO-PATH object is used in PCRep messages in response to an 360 unsuccessful path computation request (the PCE could not find a path 361 by satisfying the set of constraints). In this scenario, PCE MUST 362 include a NO-PATH object in the PCRep message. 364 The NO-PATH object carries the NO-PATH-VECTOR TLV that specifies more 365 information on the reasons that led to a negative reply. In case of 366 GMPLS networks there could be some more additional constraints that 367 led to the failure like protection mismatch, lack of resources, and 368 so on. Few new flags have been introduced in 32-bit flag field of the 369 NO-PATH-VECTOR TLV and no modifications have been made in the NO-PATH 370 object. 372 4.4.1. Extensions to NO-PATH-VECTOR TLV 374 The modified NO-PATH-VECTOR TLV carrying the additional information 375 is as follows: 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Type = 1 | Length = 4 | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Flags |N|P|U|U|N| 383 | Field |R|M|S|D|P| 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 NP - PCE currently unavailable 387 UD - Unknown destination 388 US - Unknown source 390 New fields PM and NR are defined in the 28th and 27th bit of the 391 Flags field respectively. 393 PM - Protection Mismatch (1-bit). Specifies the mismatch of the 394 protection type in the request. 396 NR - No Resource (1-bit). Specifies that the resources are not 398 currently sufficient to provide the path. 400 4.5. Additional Error Type and Error Values Defined 402 A PCEP-ERROR object is used to report a PCEP error and is 403 characterized by an Error-Type that specifies the type of error and 404 an Error-value that provides additional information about the error 405 type. An additional error type and few error values are defined to 406 represent some of the errors related to the newly identified objects 407 related to GMPLS networks. 409 For each PCEP error, an Error-Type and an Error-value are defined. 410 Error-Type 1 to 10 is already defined in RFC5440. Additional Error- 411 values are defined for Error-Type 10 and a new Error-Type 14 is 412 introduced. 414 Error-Type Error-value 416 10 Reception of an invalid object 418 Error-value=2: LSP Protection Information TLV missing 419 in QoS object. 421 Error-value=3: TLV missing in QoS object. 423 Error-value=4: Multiple instance of TLV present in 424 QoS object. 426 Error-value=5: Unsupported TLV present in QoS object. 428 Error-value=6: Traffic Parameters TLV missing in QoS 429 object. 431 14 Path computation failure 433 Error-value=1: Unacceptable response message. 435 Error-value=2: QoS object missing in request message. 437 5. Liveness Detection and Monitoring 439 This document makes no change to the basic operation of PCEP and so 440 there are no changes to the requirements for liveness detection and 441 monitoring set out in RFC4657 and RFC5440. 443 6. IANA Considerations 445 IANA assigns values to the PCEP protocol objects and TLVs. IANA is 446 requested to make some allocations for the newly defined objects and 447 TLVs introduced in this document. Also, IANA is requested to manage 448 the space of flags that are newly added in the TLVs. 450 6.1. New PCEP Object 452 IANA is requested to make some allocations for the QoS object: 454 Object-Class Value Name Reference 455 25 QoS Object-Type-1 This document (section 4.5) 457 6.2. New PCEP TLVs 459 IANA is requested to create a registry for the following TLVs: 461 Value Meaning Reference 463 20 Destination Prefix Information This document (section 4.1.1) 465 34 SDH-Traffic This document (section 4.2.1) 467 35 G.709-Traffic This document (section 4.2.1) 469 36 WSON-Traffic This document (section 4.2.1) 471 37 Ethernet-Traffic This document (section 4.2.1) 473 40 LSP Protection Information This document (section 4.2.2) 475 6.3. PCEP NO-PATH-VECTOR TLV Flag Field 477 IANA is requested to update the registry that manages the Flag field 478 of the NO-PATH-VECTOR TLV. 480 New bit numbers may be allocated only by an IETF Consensus action. 481 Each bit should be tracked with the following qualities: 483 o Bit number (counting from bit 0 as the most significant bit) 485 o Name Flag 487 o Reference 489 Code space of the Flag field (NO-PATH-VECTOR TLV). 491 Bit Number Name Reference 493 27 No Resource (NR) This document (section 4.2.1) 495 28 Protection Mismatch (PM) This document (section 4.2.1) 497 6.4. New PCEP Error Codes 499 As descried in Section 4.5, new PCEP Error-Type and Error Values are 500 defined. IANA is requested to manage the code space of the Error 501 object. 503 Error-Type Error-value 505 10 Reception of an invalid object 507 Error-value=2: LSP Protection Information TLV missing 508 in QoS object. 510 Error-value=3: TLV missing in QoS object. 512 Error-value=4: Multiple instance of TLV present in 513 QoS object. 515 Error-value=5: Unsupported TLV present in QoS object. 517 Error-value=6: Traffic Parameters TLV missing in QoS 518 object. 520 14 Path computation failure 522 Error-value=1: Unacceptable response message. 524 Error-value=2: QoS object missing in request message. 526 7. Security Considerations 528 The protocol extensions defined in this document do not substantially 529 change the nature of PCEP. Therefore, the security considerations set 530 out in RFC5440 apply unchanged. 532 8. Acknowledgements 534 The authors would like to thank Cyril Margaria, Pradeep Shastry, 535 Thiyagarajan Manickam, and Hemalatha G for their suggestions during 536 the development of this draft. 538 9. References 540 9.1. Normative References 542 [GMPLS-REQ] Otani, Ogaki, Caviglia, and Fatai Zhang, "Requirements 543 for GMPLS applications of PCE", July 2009. 545 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 546 Requirement Levels", March 1997. 548 [RFC3209] Bradner, S., "RSVP-TE: Extensions to RSVP for LSP 549 Tunnels", March 1997. 551 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 552 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 553 Engineering (RSVP-TE) Extensions", January 2003. 555 [RFC3477] Kompella, K. and Y. Rekhter, "Signaling Unnumbered Links 556 in Resource Reservation Protocol - Traffic Engineering 557 (RSVP-TE)", January 2003. 559 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 560 Extensions to RSVP-TE for LSP Tunnels", May 2005. 562 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 563 IANA Considerations Section in RFCs", May 2008. 565 [RFC4872] J.P.Lang,Y.Rekhter, D. Papadimitriou "RSVP-TE Extensions 566 in Support of End-to-End Generalized Multi-Protocol 567 Label Switching (GMPLS) Recovery", May 2007. 569 [RFC4873] J.P.Lang, I. Bryskin, D. Papadimitriou, A. Farrel "GMPLS 570 Segment Recovery", May 2007. 572 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 573 Protocol Label Switching (GMPLS) Extensions for 574 Synchronous Optical Network (SONET) and Synchronous 575 Digital Hierarchy (SDH) Control", February 2003. 577 [OTN-SIG] Fatai Zhang, Ed., "Generalized Multi-Protocol Label 578 Switching (GMPLS) Signaling Extensions for the evolving 579 G.709 Optical Transport Networks Control", draft-zhang- 580 ccamp-gmpls-evolving-g709, in progress. 582 [WSON-SIG] G. Bernstein, Young Lee, Ed., "Signaling Extensions for 583 Wavelength Switched Optical Networks", draft-bernstein- 584 ccamp-wson-signaling, in progress. 586 [Eth-Traffic] D. Papadimitriou " Ethernet Traffic Parameters ", 587 draft-ietf-ccamp-ethernet-traffic-parameters", in 588 progress. 590 9.2. Informative References 592 [RFC4655] Vasseur, J. and J. Ash, "A Path Computation Element 593 (PCE)-Based Architecture", August 2006. 595 [RFC4657] Ash, J. and J. Roux, "Path Computation Element (PCE) 596 Communication Protocol Generic Requirements", September 597 2006. 599 [RFC4674] Roux, J., "Requirements for Path Computation Element 600 (PCE) Discovery", October 2006. 602 [RFC5088] Roux, J., "OSPF Protocol Extensions for PCE Discovery", 603 January 2008. 605 [RFC5440] Ash, J. and J. Roux, "Path Computation Element (PCE) 606 communication Protocol (PCEP)", March 2009. 608 [INTER-LAYER] E.Oki, Tomorini Takeda, J.Roux, A.Farrel,"Extensions 609 to the Path Computation Element communication Protocol 610 (PCEP) for Inter-Layer MPLS and GMPLS Traffic 611 Engineering" 613 [RFC3471] L.Berger," Generalized Multi-Protocol Label Switching 614 (GMPLS) Signaling Functional Description", Jan 2003 616 10. Authors' Addresses 618 Fatai Zhang 619 Huawei Technologies 620 F3-5-B R&D Center, Huawei Base 621 Bantian, Longgang District 622 Shenzhen 518129 P.R.China 623 Email: zhangfatai@huawei.com 625 Suresh BR 626 Huawei Technologies 627 Shenzhen 628 China 629 Email: sureshbr@huawei.com 631 Young Lee 632 Huawei Technologies 633 1700 Alma Drive, Suite 100 634 Plano, TX 75075 635 USA 637 Phone: (972) 509-5599 (x2240) 638 Email: ylee@huawei.com 640 SenthilKumar S 641 Huawei Technologies 642 Shenzhen 643 China 644 Email: senthilkumars@huawei.com 646 Jun Sun 647 Huawei Technologies 648 Shenzhen 649 China 650 Email: johnsun@huawei.com 652 Intellectual Property 654 The IETF Trust takes no position regarding the validity or scope of 655 any Intellectual Property Rights or other rights that might be 656 claimed to pertain to the implementation or use of the technology 657 described in any IETF Document or the extent to which any license 658 under such rights might or might not be available; nor does it 659 represent that it has made any independent effort to identify any 660 such rights. 662 Copies of Intellectual Property disclosures made to the IETF 663 Secretariat and any assurances of licenses to be made available, or 664 the result of an attempt made to obtain a general license or 665 permission for the use of such proprietary rights by implementers or 666 users of this specification can be obtained from the IETF on-line IPR 667 repository at http://www.ietf.org/ipr 669 The IETF invites any interested party to bring to its attention any 670 copyrights, patents or patent applications, or other proprietary 671 rights that may cover technology that may be required to implement 672 any standard or specification contained in an IETF Document. Please 673 address the information to the IETF at ietf-ipr@ietf.org. 675 The definitive version of an IETF Document is that published by, or 676 under the auspices of, the IETF. Versions of IETF Documents that are 677 published by third parties, including those that are translated into 678 other languages, should not be considered to be definitive versions 679 of IETF Documents. The definitive version of these Legal Provisions 680 is that published by, or under the auspices of, the IETF. Versions of 681 these Legal Provisions that are published by third parties, including 682 those that are translated into other languages, should not be 683 considered to be definitive versions of these Legal Provisions. 685 For the avoidance of doubt, each Contributor to the IETF Standards 686 Process licenses each Contribution that he or she makes as part of 687 the IETF Standards Process to the IETF Trust pursuant to the 688 provisions of RFC 5378. No language to the contrary, or terms, 689 conditions or rights that differ from or are inconsistent with the 690 rights and licenses granted under RFC 5378, shall have any effect and 691 shall be null and void, whether published or posted by such 692 Contributor, or included with or in such Contribution. 694 Disclaimer of Validity 696 All IETF Documents and the information contained therein are provided 697 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 698 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 699 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 700 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 701 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 702 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 703 FOR A PARTICULAR PURPOSE. 705 Copyright Notice 707 Copyright (c) 2010 IETF Trust and the persons identified as the 708 document authors. All rights reserved. 710 This document is subject to BCP 78 and the IETF Trust's Legal 711 Provisions Relating to IETF Documents 712 (http://trustee.ietf.org/license-info) in effect on the date of 713 publication of this document. Please review these documents 714 carefully, as they describe your rights and restrictions with 715 respect to this document.