summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7150.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7150.txt')
-rw-r--r--doc/rfc/rfc7150.txt675
1 files changed, 675 insertions, 0 deletions
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
+
+
+ <PCReq Message> ::= <Common Header>
+ [<svec_list>]
+ <request-list>
+
+ where
+
+ <svec-list> ::= <SVEC>
+ [<OF>]
+ [<GC>]
+ [<XRO>]
+ [<metric-list>]
+ [<vendor-info-list>]
+ [<svec-list>]
+
+ <metric-list> ::= <METRIC>
+ [<metric-list>]
+
+ <vendor-info-list> ::= <VENDOR-INFORMATION>
+ [<vendor-info-list>]
+
+ <request-list> ::= <request>
+ [<request-list>]
+
+ <request> ::= <RP>
+ [<vendor-info-list>]
+ <end-point-rro-pair-list>
+ [<LSPA>]
+ [<BANDWIDTH>]
+ [<metric-list>]
+ [<OF>]
+ [<RRO>]
+ [<IRO>]
+ [<LOAD-BALANCING>]
+
+ where
+
+ <end-point-rro-pair-list> ::= <END-POINTS>
+ [<RRO-List>]
+ [<BANDWIDTH>]
+ [<vendor-info-list>]
+ [<end-point-rro-pair-list>]
+
+ <RRO-List> ::= <RRO> [<BANDWIDTH>] [<RRO-List>]
+
+ <metric-list> ::= <METRIC> [<metric-list>]
+
+ 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:
+
+ <PCRep Message> ::= <Common Header>
+ <response>
+
+ <response> ::= <RP>
+ [<vendor-info-list>]
+ [<end-point-path-pair-list>]
+ [<NO-PATH>]
+ [<attribute-list>]
+
+ where:
+
+ <end-point-path-pair-list> ::=
+ [<END-POINTS>]
+ <path>
+ [<vendor-info-list>]
+ [<end-point-path-pair-list>]
+
+ <path> ::= (<ERO>|<SERO>) [<path>]
+
+ <attribute-list> ::= [<OF>]
+ [<LSPA>]
+ [<BANDWIDTH>]
+ [<metric-list>]
+ [<IRO>]
+
+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]
+