doc: Add RFC documents

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]
+