From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7150.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc7150.txt (limited to 'doc/rfc/rfc7150.txt') diff --git a/doc/rfc/rfc7150.txt b/doc/rfc/rfc7150.txt new file mode 100644 index 0000000..ffaac1d --- /dev/null +++ b/doc/rfc/rfc7150.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) F. Zhang +Request for Comments: 7150 Huawei +Category: Standards Track A. Farrel +ISSN: 2070-1721 Juniper Networks + March 2014 + + + Conveying Vendor-Specific Constraints in the Path + Computation Element Communication Protocol + +Abstract + + The Path Computation Element communication Protocol (PCEP) is used to + convey path computation requests and responses both between Path + Computation Clients (PCCs) and Path Computation Elements (PCEs) and + between cooperating PCEs. In PCEP, the path computation requests + carry details of the constraints and objective functions that the PCC + wishes the PCE to apply in its computation. + + This document defines a facility to carry vendor-specific information + in PCEP using a dedicated object and a new Type-Length-Variable that + can be carried in any existing PCEP object. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7150. + + + + + + + + + + + + + + + +Zhang & Farrel Standards Track [Page 1] + +RFC 7150 Vendor-Specific Constraints in PCE March 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +1. Introduction + + A Path Computation Element (PCE) is an entity (component, + application, or network node) that is capable of computing a network + path or route based on a network graph and applying computational + constraints. An architecture for the use of PCEs is defined in + [RFC4655]. + + The Path Computation Element communication Protocol (PCEP) is defined + in [RFC5440] to exchange path computation requests and responses + between Path Computation Clients (PCCs) and PCEs. It is also used + between cooperating PCEs. + + Path computations performed by a PCE depend on a set of constraints + indicated by the PCC. These constraints include the endpoints of the + path to compute (source and destination) and may include other simple + constraints such as bandwidth requirements and metric maxima (for + example, a maximum threshold for the hop count or the Traffic + Engineering (TE) metric of the computed path). + + The PCE also needs to use an objective function to qualify the path + it selects as meeting the requirements of the PCC. The PCE may have + a default objective function, but the PCC can also indicate which + objective function it wants applied by placing an Objective Function + object in the path computation request message [RFC5541]. A core set + of objective functions to be supported in PCEP messages is defined in + the base PCEP requirements [RFC4657], and [RFC5541] defines each of + these functions as an abstract formula. + + The registry of codepoints used to indicate objective functions is + managed by IANA and new assignments can be made according to "IETF + Review" and "First Come First Served" policies [RFC5226]. PCE + implementations may also choose to offer proprietary, vendor-specific + + + +Zhang & Farrel Standards Track [Page 2] + +RFC 7150 Vendor-Specific Constraints in PCE March 2014 + + + objective functions, and there is scope for this within the codepoint + registry created by [RFC5541] using the codepoints that are flagged + as "Reserved for Private Use". + + Proprietary objective functions may operate on non-standard + constraints or metrics. The PCEP METRIC Object defined in [RFC5440] + has scope for the definition of new, standardized metrics, but no + facility for the definition of vendor-specific metrics. At the same + time, there is no mechanism in PCEP for carrying other, more complex, + vendor-specific information. + + This document defines a new PCEP object, the Vendor Information + object that can be used to carry arbitrary, proprietary information + such as vendor-specific constraints. + + This document also defines a new PCEP TLV, the VENDOR-INFORMATION-TLV + that can be used to carry arbitrary information within any PCEP + object that supports TLVs. + + It should be noted that by the very definition of "vendor-specific", + the inclusion of either a Vendor Information object or the VENDOR- + INFORMATION-TLV implies an inability to interoperate at a functional + level with implementations from other vendors unless there is some + cooperation agreement between vendors. Sections 2.1 and 3.1 discuss + backward compatibility, which indicates how these protocol constructs + are handled by implementations that do not support them at all, while + text in Sections 2 and 3 describe how implementations handle the + constructs if they understand them, but do not support the embedded + Enterprise Number that indicates to which vendor the constructs + apply. + + When vendor-specific information is used by an implementation, the + vendor is encouraged to document the meaning of the information to + encourage wider use and implementation. In particular, when there is + more general interest in a vendor-specific extension, the vendor is + encouraged to bring it to the IETF for standardization as a regular + protocol construct moving it out of the vendor-specific space. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + + + + + + +Zhang & Farrel Standards Track [Page 3] + +RFC 7150 Vendor-Specific Constraints in PCE March 2014 + + +2. Procedures for the Vendor Information Object + + A PCC that wants to convey proprietary or vendor-specific constraints + or metrics to a PCE does so by including a Vendor Information object + in the PCReq message. The contents and format of the object are + described in Section 4, but it is important to note that the object + includes an Enterprise Number that is a unique identifier of an + organization responsible for the definition of the content and + meaning of the object. + + A PCE that receives a PCReq message containing a Vendor Information + object MUST act according to the P flag in the object header. That + is, if the P flag is set, the object will be treated as mandatory and + the request will either be processed using the contents of the object + or be rejected as defined in [RFC5440] (see also Section 2.1). If + the P flag is clear, then, as defined in [RFC5440], the object may be + used by the PCE or may be ignored. The PCC sets the P flag according + to how it wishes the request to be processed. + + The PCE determines how to interpret the information in the Vendor + Information object by examining the Enterprise Number it contains. + An implementation that supports the Vendor Information object, but + receives one carrying an Enterprise Number that it does not support + MUST act according to the P flag in the object. That is, if the P + flag is set, the PCE MUST reject the PCReq as defined in [RFC5440] by + sending an Error message with Error-Type="Not supported Object" along + with the corresponding Vendor Information object. + + The Vendor Information object is OPTIONAL in a PCReq message. + Multiple instances of the object MAY be used on a single PCReq + message, and each MUST be treated according to its P-bit setting. + Different instances of the object can have different Enterprise + Numbers. + + The object can be present in the PCReq message to enable it to apply + to a single path computation request or to a set of synchronized + requests. This usage mirrors the usage of the Objective Function + object [RFC5541]. Thus, the PCReq message based on [RFC6006] is + encoded as follows using the syntax described in [RFC5511]. + + + + + + + + + + + + +Zhang & Farrel Standards Track [Page 4] + +RFC 7150 Vendor-Specific Constraints in PCE March 2014 + + + ::= + [] + + + where + + ::= + [] + [] + [] + [] + [] + [] + + ::= + [] + + ::= + [] + + ::= + [] + + ::= + [] + + [] + [] + [] + [] + [] + [] + [] + + where + + ::= + [] + [] + [] + [] + + ::= [] [] + + ::= [] + + The Vendor Information object can be included in a PCRep message in + exactly the same way as any other object as defined in [RFC5440]. + + + +Zhang & Farrel Standards Track [Page 5] + +RFC 7150 Vendor-Specific Constraints in PCE March 2014 + + + Thus, the PCRep is encoded as follows: + + ::= + + + ::= + [] + [] + [] + [] + + where: + + ::= + [] + + [] + [] + + ::= (|) [] + + ::= [] + [] + [] + [] + [] + +2.1. Backward Compatibility for the Vendor Information Object + + A legacy implementation that does not recognize the Vendor + Information object will act according to the procedures set out in + [RFC5440]. If the P flag is set in the object, the message will be + rejected using a PCErr message with an Error Type of 3 ("Unknown + Object"). If the P flag is not set, the object can safely be ignored + by the recipient. + +3. Procedures for the Vendor Information TLV + + The Vendor Information TLV can be used to carry vendor-specific + information that applies to a specific PCEP object by including the + TLV in the object. + + The PCE determines how to interpret the Vendor Information TLV by + examining the Enterprise Number it contains. If the Enterprise + Number is unknown to the PCE, it MUST treat the Vendor Information + TLV as an unknown TLV and handle it as described in [RFC5440] (see + also Section 3.1). + + + + +Zhang & Farrel Standards Track [Page 6] + +RFC 7150 Vendor-Specific Constraints in PCE March 2014 + + + Further specifications are needed to define the position and meaning + of the Vendor Information TLV for specific PCEP objects. + +3.1. Backward Compatibility + + A legacy implementation that does not recognize the Vendor + Information TLV in an object will act according to the procedures set + out in [RFC5440]. As described in Section 7.1 of [RFC5440], + unrecognized TLVs MUST be ignored. + +4. Protocol Elements + + The Vendor Information object and TLV conform to the format for PCEP + objects and TLVs defined in [RFC5440]. + + VENDOR-INFORMATION Object-Class 32 + + VENDOR-INFORMATION Object-Type 1 + + VENDOR-INFORMATION-TLV Type 7 + + The format of the VENDOR-INFORMATION object and the format of the + VENDOR-INFORMATION-TLV are the same and are as shown in Figure 1. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Enterprise Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Enterprise-Specific Information ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1 : Format of the Vendor Information Object and TLV + + Enterprise Number + + A unique identifier of an organization encoded as a 32-bit + integer. Enterprise Numbers are assigned by IANA and managed + through an IANA registry [RFC2578]. + + Enterprise-Specific Information + + The detailed enterprise-specific constraint information carried by + the object. The format and interpretation of this information is + a matter for the enterprise identified by the Enterprise Number. + Such formats and interpretation may be published by the enterprise + + + + + +Zhang & Farrel Standards Track [Page 7] + +RFC 7150 Vendor-Specific Constraints in PCE March 2014 + + + (possibly through an Informational RFC or through commercial + documentation) so that PCCs or PCEs that are not part of the + organization can use the information. + +5. IANA Considerations + + IANA maintains a registry of PCEP parameters called the "Path + Computation Element Protocol (PCEP) Numbers". + +5.1. New PCEP Object + + IANA has made an allocation from the "PCEP Objects" subregistry as + follows. + + Object-Class Value Name Reference + 32 VENDOR-INFORMATION [RFC7150] + Object-Type + 0: Unassigned + 1: Vendor-Specific Constraints [RFC7150] + 2-255: Unassigned + +5.2. New PCEP TLV + + IANA has made an allocation from the "PCEP TLV Type Indicators" + subregistry as follows. + + Value Description Reference + 7 VENDOR-INFORMATION-TLV [RFC7150] + +6. Management Considerations + + This section follows the guidance of [RFC5706] and [RFC6123]. + +6.1. Control of Function and Policy + + A PCEP implementation SHOULD allow configuring of various parameters + as described in [RFC5440]. A PCC implementation that uses vendor- + specific information MAY make the use of this information + configurable either across the whole PCC, per PCE that the PCC uses, + or per path computation request. A PCE that supports vendor-specific + information MAY make the support of this information configurable, + and MAY allow configuration of policies for the use of the + information. + + + + + + + + +Zhang & Farrel Standards Track [Page 8] + +RFC 7150 Vendor-Specific Constraints in PCE March 2014 + + +6.2. Information and Data Models + + A PCEP MIB module is defined in [PCE-MIB] that describes managed + objects for modeling of PCEP communications. + + It is NOT RECOMMENDED that standard MIB modules be extended to + include detailed information about the content of the Vendor + Information object or TLV. However, the standard MIB module MAY be + extended to report the use of the Vendor Information object or TLV + and the Enterprise Numbers that the objects and TLVs contain. + +6.3. Liveness Detection and Monitoring + + This document makes no change to the basic operation of PCEP, so + there are no changes to the requirements for liveness detection and + monitoring set out in [RFC4657] and [RFC5440]. + +6.4. Verifying Correct Operation + + This document makes no change to the basic operation of PCEP, so + there are no changes to the requirements or techniques for monitoring + the correct operation of the protocol out in [RFC4657] and [RFC5440]. + + Note that "correct operation" in this context refers to the operation + of the protocol itself and not to the operation of the computation + algorithms which are out of scope for all PCEP work. + + Mechanisms for verifying the correct operation of computation + algorithms might involve comparing the results returned by more than + one PCE. Scope for this might be limited by the use of vendor + information unless multiple PCEs support the same set of vendor + information. + +6.5. Requirements on Other Protocols and Functional Components + + This document does not place any new requirements on other network + components or protocols. However, it may be beneficial to consider + whether a PCE should advertise the Enterprise Numbers and vendor + information it supports. This advertisement could be within PCE + Discovery [RFC5088] [RFC5089] or through extensions to PCEP + [RFC5440]. + + Extensions for discovery and advertisement are outside the scope of + this document. + + + + + + + +Zhang & Farrel Standards Track [Page 9] + +RFC 7150 Vendor-Specific Constraints in PCE March 2014 + + +6.6. Impact on Network Operation + + The availability of vendor information in PCEP messages may + facilitate more complex and detailed path computations that may + enhance the way in which the network is operated. + + On the other hand, the presence of additional vendor-specific + information in PCEP messages may congest the operation of the + protocol especially if the PCE does not support the information + supplied by the PCC. Thus, a PCC SHOULD monitor the capabilities of + a PCE either by discovery mechanisms as described in Section 6.5 or + through the receipt of negative responses. A PCC SHOULD NOT include + vendor information in a PCReq message to a PCE that it believes does + not support the information and that will not forward the request to + some other PCE that does support the information. + +7. Security Considerations + + The protocol extensions defined in this document do not substantially + change the nature of PCEP. Therefore, the security considerations + set out in [RFC5440] apply unchanged. Note that further security + considerations for the use of PCEP over TCP are presented in + [RFC6952]. + + Operators should note that an attack on PCEP may involve making PCEP + messages as large as possible in order to consume bandwidth and + processing power. The Vendor Information object and TLV may provide + a vector for this type of attack. It may be protected against by + using the authentication and integrity procedures described in + [RFC5440]. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol (PCEP)", RFC 5440, + March 2009. + + [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax + Used to Form Encoding Rules in Various Routing Protocol + Specifications", RFC 5511, April 2009. + + + + + + +Zhang & Farrel Standards Track [Page 10] + +RFC 7150 Vendor-Specific Constraints in PCE March 2014 + + + [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., + Ali, Z., and J. Meuric, "Extensions to the Path + Computation Element Communication Protocol (PCEP) for + Point-to-Multipoint Traffic Engineering Label Switched + Paths", RFC 6006, September 2010. + +8.2. Informative References + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path + Computation Element (PCE)-Based Architecture", RFC 4655, + August 2006. + + [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol Generic + Requirements", RFC 4657, September 2006. + + [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. + Zhang, "OSPF Protocol Extensions for Path Computation + Element (PCE) Discovery", RFC 5088, January 2008. + + [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. + Zhang, "IS-IS Protocol Extensions for Path Computation + Element (PCE) Discovery", RFC 5089, January 2008. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of + Objective Functions in the Path Computation Element + Communication Protocol (PCEP)", RFC 5541, June 2009. + + [RFC5706] Harrington, D., "Guidelines for Considering Operations and + Management of New Protocols and Protocol Extensions", RFC + 5706, November 2009. + + [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path + Computation Element (PCE) Working Group Drafts", RFC 6123, + February 2011. + + + + + + + + +Zhang & Farrel Standards Track [Page 11] + +RFC 7150 Vendor-Specific Constraints in PCE March 2014 + + + [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of + BGP, LDP, PCEP, and MSDP Issues According to the Keying + and Authentication for Routing Protocols (KARP) Design + Guide", RFC 6952, May 2013. + + [PCE-MIB] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. + Hardwick, "Path Computation Element Protocol (PCEP) + Management Information Base", Work in Progress, February + 2014. + +9. Acknowledgements + + Thanks to Meral Shirazipour, Ramon Casellas, Cyril Margaria, Dhruv + Dhody, Julien Meuric, and Robert Sparks for review and comments. + +10. Contributors + + Greg Bernstein + Grotto Networking + EMail: gregb@grotto-networking.com + + Ina Minei + Juniper Networks + EMail: ina@juniper.net + +Authors' Addresses + + Adrian Farrel + Juniper Networks + EMail: adrian@olddog.co.uk + + Fatai Zhang + Huawei Technologies + EMail: zhangfatai@huawei.com + + + + + + + + + + + + + + + + + +Zhang & Farrel Standards Track [Page 12] + -- cgit v1.2.3