Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8233

 
 
 

Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)

Part 2 of 2, p. 16 to 31
Prev Section

 


prevText      Top      ToC       Page 16 
4.  Stateful PCE and PCE Initiated LSPs

   [RFC8231] specifies a set of extensions to PCEP to enable stateful
   control of MPLS-TE and GMPLS LSPs via PCEP and the maintaining of
   these LSPs at the stateful PCE.  It further distinguishes between an
   active and a passive stateful PCE.  A passive stateful PCE uses LSP
   state information learned from PCCs to optimize path computations but
   does not actively update LSP state.  In contrast, an active stateful
   PCE utilizes the LSP delegation mechanism to update LSP parameters in
   those PCCs that delegated control over their LSPs to the PCE.
   [PCE-INITIATED] describes the setup, maintenance, and teardown of

Top      Up      ToC       Page 17 
   PCE-initiated LSPs under the stateful PCE model.  The document
   defines the PCInitiate message that is used by a PCE to request a PCC
   to set up a new LSP.

   The new metric type and objective functions defined in this document
   can also be used with the stateful PCE extensions.  The format of
   PCEP messages described in [RFC8231] and [PCE-INITIATED] uses
   <intended-attribute-list> and <attribute-list>, respectively, (where
   the <intended-attribute-list> is the attribute-list defined in
   Section 6.5 of [RFC5440] and extended in Section 5.2 of this
   document) for the purpose of including the service-aware parameters.

   The stateful PCE implementation MAY use the extension of PCReq and
   PCRep messages as defined in Sections 5.1 and 5.2 to enable the use
   of service-aware parameters during passive stateful operations.

5.  PCEP Message Extension

   Message formats in this document are expressed using Routing Backus-
   Naur Form (RBNF) as used in [RFC5440] and defined in [RFC5511].

5.1.  The PCReq Message

   The extensions to the PCReq message are:

   o  new metric types using existing METRIC object

   o  a new optional BU object

   o  new objective functions using existing OF object [RFC5541]

Top      Up      ToC       Page 18 
   The format of the PCReq message (with [RFC5541] and [RFC8231] as a
   base) is updated as follows:

      <PCReq Message> ::= <Common Header>
                           [<svec-list>]
                           <request-list>
      where:
           <svec-list> ::= <SVEC>
                           [<OF>]
                           [<metric-list>]
                           [<svec-list>]

           <request-list> ::= <request> [<request-list>]

           <request> ::= <RP>
                         <END-POINTS>
                         [<LSP>]
                         [<LSPA>]
                         [<BANDWIDTH>]
                         [<bu-list>]
                         [<metric-list>]
                         [<OF>]
                         [<RRO>[<BANDWIDTH>]]
                         [<IRO>]
                         [<LOAD-BALANCING>]

      and where:
           <bu-list>::=<BU>[<bu-list>]
           <metric-list> ::= <METRIC>[<metric-list>]

5.2.  The PCRep Message

   The extensions to the PCRep message are:

   o  new metric types using existing METRIC object

   o  a new optional BU object (during unsuccessful path computation, to
      indicate the bandwidth utilization as a reason for failure)

   o  new objective functions using existing OF object [RFC5541]

Top      Up      ToC       Page 19 
   The format of the PCRep message (with [RFC5541] and [RFC8231] as a
   base) is updated as follows:

      <PCRep Message> ::= <Common Header>
                          [<svec-list>]
                          <response-list>

      where:

            <svec-list> ::= <SVEC>
                            [<OF>]
                            [<metric-list>]
                            [<svec-list>]

           <response-list> ::= <response> [<response-list>]

           <response> ::= <RP>
                          [<LSP>]
                          [<NO-PATH>]
                          [<attribute-list>]
                          [<path-list>]

           <path-list> ::= <path> [<path-list>]

           <path> ::= <ERO>
                      <attribute-list>

      and where:

           <attribute-list> ::= [<OF>]
                                [<LSPA>]
                                [<BANDWIDTH>]
                                [<bu-list>]
                                [<metric-list>]
                                [<IRO>]

           <bu-list>::=<BU>[<bu-list>]
           <metric-list> ::= <METRIC> [<metric-list>]

5.3.  The PCRpt Message

   A Path Computation LSP State Report message (also referred to as
   PCRpt message) is a PCEP message sent by a PCC to a PCE to report the
   current state or delegate control of an LSP.  The BU object in a
   PCRpt message specifies the upper limit set at the PCC at the time of
   LSP delegation to an active stateful PCE.

Top      Up      ToC       Page 20 
   The format of the PCRpt message is described in [RFC8231], which uses
   the <intended-attribute-list>, which is the attribute-list defined in
   Section 6.5 of [RFC5440] and extended by PCEP extensions.

   The PCRpt message can use the updated <attribute-list> (as extended
   in Section 5.2) for the purpose of including the BU object.

6.  Other Considerations

6.1.  Inter-domain Path Computation

   [RFC5441] describes the Backward Recursive PCE-Based Computation
   (BRPC) procedure to compute an end-to-end optimized inter-domain path
   by cooperating PCEs.  The new metric types defined in this document
   can be applied to end-to-end path computation, in a similar manner to
   the existing IGP or TE metrics.  The new BU object defined in this
   document can be applied to end-to-end path computation, in a similar
   manner to a METRIC object with its B bit set to 1.

   All domains should have the same understanding of the METRIC (path
   delay variation, etc.) and the BU object for end-to-end inter-domain
   path computation to make sense.  Otherwise, some form of metric
   normalization as described in [RFC5441] MUST be applied.

6.1.1.  Inter-AS Links

   The IGP in each neighbor domain can advertise its inter-domain TE
   link capabilities.  This has been described in [RFC5316] (IS-IS) and
   [RFC5392] (OSPF).  The network performance link properties are
   described in [RFC7471] and [RFC7810].  The same properties must be
   advertised using the mechanism described in [RFC5392] (OSPF) and
   [RFC5316] (IS-IS).

6.1.2.  Inter-Layer Path Computation

   [RFC5623] provides a framework for PCE-based inter-layer MPLS and
   GMPLS traffic engineering.  Lower-layer LSPs that are advertised as
   TE links into the higher-layer network form a Virtual Network
   Topology (VNT).  The advertisement into the higher-layer network
   should include network performance link properties based on the
   end-to-end metric of the lower-layer LSP.  Note that the new metrics
   defined in this document are applied to end-to-end path computation,
   even though the path may cross multiple layers.

Top      Up      ToC       Page 21 
6.2.  Reoptimizing Paths

   [RFC6374] defines the measurement of loss, delay, and related metrics
   over LSPs.  A PCC can utilize these measurement techniques.  In case
   it detects a degradation of network performance parameters relative
   to the value of the constraint it gave when the path was set up, or
   relative to an implementation-specific threshold, it MAY ask the PCE
   to reoptimize the path by sending a PCReq with the R bit set in the
   RP object, as per [RFC5440].

   A PCC may also detect the degradation of an LSP without making any
   direct measurements, by monitoring the TED (as populated by the IGP)
   for changes in the network performance parameters of the links that
   carry its LSPs.  The PCC can issue a reoptimization request for any
   impacted LSPs.  For example, a PCC can monitor the link bandwidth
   utilization along the path by monitoring changes in the bandwidth
   utilization parameters of one or more links on the path in the TED.
   If the bandwidth utilization percentage of any of the links in the
   path changes to a value less than that required when the path was set
   up, or otherwise less than an implementation-specific threshold, then
   the PCC can issue a reoptimization request to a PCE.

   A stateful PCE can also determine which LSPs should be reoptimized
   based on network events or triggers from external monitoring systems.
   For example, when a particular link deteriorates and its loss
   increases, this can trigger the stateful PCE to automatically
   determine which LSPs are impacted and should be reoptimized.

7.  IANA Considerations

7.1.  METRIC Types

   IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
   registry at <http://www.iana.org/assignments/pcep>.  Within this
   registry, IANA maintains a subregistry for "METRIC Object T Field".
   Six new metric types are defined in this document for the METRIC
   object (specified in [RFC5440]).

   IANA has made the following allocations:

        Value       Description                        Reference
        ----------------------------------------------------------
        12          Path Delay metric                  RFC 8233
        13          Path Delay Variation metric        RFC 8233
        14          Path Loss metric                   RFC 8233
        15          P2MP Path Delay metric             RFC 8233
        16          P2MP Path Delay variation metric   RFC 8233
        17          P2MP Path Loss metric              RFC 8233

Top      Up      ToC       Page 22 
7.2.  New PCEP Object

   IANA maintains Object-Types within the "PCEP Objects" registry.  IANA
   has made the following allocation:

          Object    Object     Name                  Reference
          Class     Type
          ------------------------------------------------------
          35        0          Reserved              RFC 8233
                    1          BU                    RFC 8233

7.3.  BU Object

   IANA has created a new subregistry, named "BU Object Type Field",
   within the "Path Computation Element Protocol (PCEP) Numbers"
   registry to manage the Type field of the BU object.  New values are
   to be assigned by Standards Action [RFC8126].  Each value should be
   tracked with the following qualities:

   o  Type

   o  Name

   o  Reference

   The following values are defined in this document:

      Type    Name                                        Reference
      ---------------------------------------------------------------
      0       Reserved                                    RFC 8233

      1       LBU (Link Bandwidth Utilization)            RFC 8233

      2       LRBU (Link Residual Bandwidth Utilization)  RFC 8233

7.4.  OF Codes

   IANA maintains the "Objective Function" subregistry (described in
   [RFC5541]) within the "Path Computation Element Protocol (PCEP)
   Numbers" registry.  Three new objective functions have been defined
   in this document.

Top      Up      ToC       Page 23 
   IANA has made the following allocations:

     Code     Name                                         Reference
     Point
     -----------------------------------------------------------------
     9        Minimum Packet Loss Path (MPLP)              RFC 8233

     10       Maximum Under-Utilized Path (MUP)            RFC 8233

     11       Maximum Reserved Under-Utilized Path (MRUP)  RFC 8233

7.5.  New Error-Values

   IANA maintains a registry of Error-Types and Error-values for use in
   PCEP messages.  This is maintained as the "PCEP-ERROR Object Error
   Types and Values" subregistry of the "Path Computation Element
   Protocol (PCEP) Numbers" registry.

   IANA has made the following allocations:

   Two new Error-values are defined for the Error-Type "Not supported
   object" (type 4) and "Policy violation" (type 5).

       Error-Type     Meaning and error values           Reference
       -------------------------------------------------------------
          4           Not supported object

                      Error-value
                      5: Unsupported network             RFC 8233
                      performance constraint

          5           Policy violation

                      Error-value
                      8: Not allowed network             RFC 8233
                      performance constraint

8.  Security Considerations

   This document defines new METRIC types, a new BU object, and new OF
   codes that do not add any new security concerns beyond those
   discussed in [RFC5440] and [RFC5541] in itself.  Some deployments may
   find the service-aware information like delay and packet loss to be
   extra sensitive and could be used to influence path computation and
   setup with adverse effect.  Additionally, snooping of PCEP messages
   with such data or using PCEP messages for network reconnaissance may
   give an attacker sensitive information about the operations of the
   network.  Thus, such deployment should employ suitable PCEP security

Top      Up      ToC       Page 24 
   mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] or
   [PCEPS].  The procedure based on Transport Layer Security (TLS) in
   [PCEPS] is considered a security enhancement and thus is much better
   suited for the sensitive service-aware information.

9.  Manageability Considerations

9.1.  Control of Function and Policy

   The only configurable item is the support of the new constraints on a
   PCE, which MAY be controlled by a policy module on an individual
   basis.  If the new constraint is not supported/allowed on a PCE, it
   MUST send a PCErr message accordingly.

9.2.  Information and Data Models

   [RFC7420] describes the PCEP MIB.  There are no new MIB Objects for
   this document.

9.3.  Liveness Detection and Monitoring

   The mechanisms defined in this document do not imply any new liveness
   detection and monitoring requirements in addition to those already
   listed in [RFC5440].

9.4.  Verify Correct Operations

   The mechanisms defined in this document do not imply any new
   operation verification requirements in addition to those already
   listed in [RFC5440].

9.5.  Requirements on Other Protocols

   The PCE requires the TED to be populated with network performance
   information like link latency, delay variation, packet loss, and
   utilized bandwidth.  This mechanism is described in [RFC7471] and
   [RFC7810].

9.6.  Impact on Network Operations

   The mechanisms defined in this document do not have any impact on
   network operations in addition to those already listed in [RFC5440].

Top      Up      ToC       Page 25 
10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              DOI 10.17487/RFC3630, September 2003,
              <https://www.rfc-editor.org/info/rfc3630>.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
              2008, <https://www.rfc-editor.org/info/rfc5305>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.

   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
              Used to Form Encoding Rules in Various Routing Protocol
              Specifications", RFC 5511, DOI 10.17487/RFC5511, April
              2009, <https://www.rfc-editor.org/info/rfc5511>.

   [RFC5541]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
              Objective Functions in the Path Computation Element
              Communication Protocol (PCEP)", RFC 5541,
              DOI 10.17487/RFC5541, June 2009,
              <https://www.rfc-editor.org/info/rfc5541>.

   [RFC7471]  Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
              Previdi, "OSPF Traffic Engineering (TE) Metric
              Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
              <https://www.rfc-editor.org/info/rfc7471>.

   [RFC7810]  Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
              Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
              RFC 7810, DOI 10.17487/RFC7810, May 2016,
              <https://www.rfc-editor.org/info/rfc7810>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Top      Up      ToC       Page 26 
   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,
              <http://www.rfc-editor.org/info/rfc8231>.

10.2.  Informative References

   [IEEE.754]
              IEEE, "Standard for Binary Floating-Point Arithmetic",
              IEEE Standard 754-2008, DOI 10.1109/IEEESTD.2008.4610935,
              August 2008.

   [PCE-INITIATED]
              Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
              Extensions for PCE-initiated LSP Setup in a Stateful PCE
              Model", Work in Progress,
              draft-ietf-pce-pce-initiated-lsp-10, June 2017.

   [PCEPS]    Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure
              Transport for PCEP", Work in Progress,
              draft-ietf-pce-pceps-16, September 2017.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <https://www.rfc-editor.org/info/rfc4655>.

   [RFC5316]  Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
              Support of Inter-Autonomous System (AS) MPLS and GMPLS
              Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
              December 2008, <https://www.rfc-editor.org/info/rfc5316>.

   [RFC5392]  Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
              Support of Inter-Autonomous System (AS) MPLS and GMPLS
              Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392,
              January 2009, <https://www.rfc-editor.org/info/rfc5392>.

   [RFC5441]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
              "A Backward-Recursive PCE-Based Computation (BRPC)
              Procedure to Compute Shortest Constrained Inter-Domain
              Traffic Engineering Label Switched Paths", RFC 5441,
              DOI 10.17487/RFC5441, April 2009,
              <https://www.rfc-editor.org/info/rfc5441>.

Top      Up      ToC       Page 27 
   [RFC5623]  Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
              "Framework for PCE-Based Inter-Layer MPLS and GMPLS
              Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623,
              September 2009, <https://www.rfc-editor.org/info/rfc5623>.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
              June 2010, <https://www.rfc-editor.org/info/rfc5925>.

   [RFC6049]  Morton, A. and E. Stephan, "Spatial Composition of
              Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011,
              <https://www.rfc-editor.org/info/rfc6049>.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374,
              DOI 10.17487/RFC6374, September 2011,
              <https://www.rfc-editor.org/info/rfc6374>.

   [RFC7420]  Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
              Hardwick, "Path Computation Element Communication Protocol
              (PCEP) Management Information Base (MIB) Module",
              RFC 7420, DOI 10.17487/RFC7420, December 2014,
              <https://www.rfc-editor.org/info/rfc7420>.

   [RFC7823]  Atlas, A., Drake, J., Giacalone, S., and S. Previdi,
              "Performance-Based Path Selection for Explicitly Routed
              Label Switched Paths (LSPs) Using TE Metric Extensions",
              RFC 7823, DOI 10.17487/RFC7823, May 2016,
              <https://www.rfc-editor.org/info/rfc7823>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

Top      Up      ToC       Page 28 
Appendix A.  PCEP Requirements

   End-to-end service optimization based on latency, delay variation,
   packet loss, and link bandwidth utilization are key requirements for
   service providers.  The following associated key requirements are
   identified for PCEP:

   1.  A PCE supporting this specification MUST have the capability to
       compute end-to-end paths with latency, delay variation, packet
       loss, and bandwidth utilization constraints.  It MUST also
       support the combination of network performance constraints
       (latency, delay variation, loss,...) with existing constraints
       (cost, hop-limit,...).

   2.  A PCC MUST be able to specify any network performance constraint
       in a PCReq message to be applied during the path computation.

   3.  A PCC MUST be able to request that a PCE optimizes a path using
       any network performance criteria.

   4.  A PCE that supports this specification is not required to provide
       service-aware path computation to any PCC at any time.

       Therefore, it MUST be possible for a PCE to reject a PCReq
       message with a reason code that indicates service-aware path
       computation is not supported.  Furthermore, a PCE that does not
       support this specification will either ignore or reject such
       requests using pre-existing mechanisms; therefore, the requests
       MUST be identifiable to legacy PCEs, and rejections by legacy
       PCEs MUST be acceptable within this specification.

   5.  A PCE SHOULD be able to return end-to-end network performance
       information of the computed path in a PCRep message.

   6.  A PCE SHOULD be able to compute multi-domain (e.g., Inter-AS,
       Inter-Area, or Multi-Layer) service-aware paths.

   Such constraints are only meaningful if used consistently: for
   instance, if the delay of a computed path segment is exchanged
   between two PCEs residing in different domains, a consistent way of
   defining the delay must be used.

Top      Up      ToC       Page 29 
Acknowledgments

   We would like to thank Alia Atlas, John E. Drake, David Ward, Young
   Lee, Venugopal Reddy, Reeja Paul, Sandeep Kumar Boina, Suresh Babu,
   Quintin Zhao, Chen Huaimo, Avantika, and Adrian Farrel for their
   useful comments and suggestions.

   Also, the authors gratefully acknowledge reviews and feedback
   provided by Qin Wu, Alfred Morton, and Paul Aitken during performance
   directorate review.

   Thanks to Jonathan Hardwick for shepherding this document and
   providing valuable comments.  His help in fixing the editorial and
   grammatical issues is also appreciated.

   Thanks to Christian Hopps for the routing directorate review.

   Thanks to Jouni Korhonen and Alfred Morton for the operational
   directorate review.

   Thanks to Christian Huitema for the security directorate review.

   Thanks to Deborah Brungard for being the responsible AD.

   Thanks to Ben Campbell, Joel Jaeggli, Stephen Farrell, Kathleen
   Moriarty, Spencer Dawkins, Mirja Kuehlewind, Jari Arkko, and Alia
   Atlas for the IESG reviews.

Top      Up      ToC       Page 30 
Contributors

   Clarence Filsfils
   Cisco Systems
   Email: cfilsfil@cisco.com

   Siva Sivabalan
   Cisco Systems
   Email: msiva@cisco.com

   George Swallow
   Cisco Systems
   Email: swallow@cisco.com

   Stefano Previdi
   Cisco Systems, Inc
   Via Del Serafico 200
   Rome  00191
   Italy
   Email: sprevidi@cisco.com

   Udayasree Palle
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   India
   Email: udayasree.palle@huawei.com

   Avantika
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   India
   Email: avantika.sushilkumar@huawei.com

   Xian Zhang
   Huawei Technologies
   F3-1-B R&D Center, Huawei Base Bantian, Longgang District
   Shenzhen, Guangdong  518129
   China
   Email: zhang.xian@huawei.com

Top      Up      ToC       Page 31 
Authors' Addresses

   Dhruv Dhody
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   India

   Email: dhruv.ietf@gmail.com


   Qin Wu
   Huawei Technologies
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: bill.wu@huawei.com


   Vishwas Manral
   Nano Sec Co
   3350 Thomas Rd.
   Santa Clara, CA
   United States of America

   Email: vishwas@nanosec.io


   Zafar Ali
   Cisco Systems

   Email: zali@cisco.com


   Kenji Kumaki
   KDDI Corporation

   Email: ke-kumaki@kddi.com