MPLS Working Group A. Deshmukh Internet-Draft V. P. Beeram Intended status: Standards Track HPE Expires: 1 September 2026 28 February 2026 Signaling Optimization Objective and Bounded Metrics for MPLS Fast Reroute Backup LSP Tunnels draft-deshmukh-mpls-frr-ext-01 Abstract This document introduces RSVP-TE signaling procedures that enable the head-end Label Switched Router (LSR) of a local-protection-desiring Label Switched Path (LSP) to influence the optimization objective and bounded metric constraints used for the path computation of a backup LSP tunnel at a Point of Local Repair (PLR). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 1 September 2026. Copyright Notice Copyright (c) 2026 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Deshmukh & Beeram Expires 1 September 2026 [Page 1] Internet-Draft MPLS FRR EXT February 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.1. Local-Protection-Desiring LSP . . . . . . . . . . . . 3 1.2.2. Optimization Objective . . . . . . . . . . . . . . . 3 1.2.3. Bounded Metric . . . . . . . . . . . . . . . . . . . 4 2. Procedure at the Ingress . . . . . . . . . . . . . . . . . . 4 3. Procedure at the PLR . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 4.1. FAST_REROUTE_EXT Object . . . . . . . . . . . . . . . . . 5 4.1.1. Optimization Metric TLV . . . . . . . . . . . . . . . 6 4.1.2. Bounded Metric TLV . . . . . . . . . . . . . . . . . 7 4.2. RRO IPv4/IPv6 Sub-Object Flag . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6.1. FAST_REROUTE_EXT Object . . . . . . . . . . . . . . . . . 8 6.1.1. Metrics . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Record Route Object Sub-object Flags: FRR_EXT Protection . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. Error Codes and Error Values . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction [RFC4090] defines RSVP-TE signaling procedures to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. It introduces the FAST_REROUTE object, which allows the head-end Label Switched Router (LSR) of a local-protection-desiring LSP to signal the constraints used for the path computation of a backup LSP tunnel at each point of local repair (PLR). The constraints carried in the FAST_REROUTE object are limited to priorities, affinities, hop limit, and bandwidth. Implementations rely on the local policy at the PLR to determine the optimization objective and other relevant constraints for computing the backup path. Deshmukh & Beeram Expires 1 September 2026 [Page 2] Internet-Draft MPLS FRR EXT February 2026 This document enhances the options available at the head-end LSR of a local-protection-desiring LSP to influence the path computation of the backup LSP tunnel at the PLR. It introduces an extensible TLV- based RSVP object, FAST_REROUTE_EXT, for signaling the optimization objective and bounded metric constraints to be imposed on the backup LSP tunnel path computation. The signaling procedures defined in the document are backward-compatible with implementations that only understand the FAST_REROUTE object. The criteria for determining the appropriate optimization objective and bounded metrics for the backup LSP tunnel paths are outside the scope of this document. 1.1. Requirements Language 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology The reader is expected to be familiar with the terminology used in [RFC3209] and [RFC4090]. 1.2.1. Local-Protection-Desiring LSP In this document, a local-protection-desiring LSP refers to an MPLS RSVP-TE LSP for which local protection is requested by signaling the FAST_REROUTE object in the PATH message as specified in RFC4090. 1.2.2. Optimization Objective An optimization objective is typically represented as a quantifiable metric that an algorithm aims to optimize (minimize or maximize, depending on the metric type) when selecting a TE path. For example, the optimization objective used in the backup path computation could be (but not limited to) any of the following: * Minimize the cumulative "IGP Metric" along the traversed path. * Minimize the cumulative "TE Metric" along the traversed path. * Minimize the cumulative "Delay-Average" along the traversed path. * Minimize the cumulative "Unreserved Bandwidth" along the traversed path. Deshmukh & Beeram Expires 1 September 2026 [Page 3] Internet-Draft MPLS FRR EXT February 2026 In certain scenarios where the path computation is deemed a multi- parameter optimization problem and multiple optimization objectives are considered, a normalization weight may be required for each objective. 1.2.3. Bounded Metric A bounded metric is a constraint parameter that is used to define a bound that a computed TE path must satisfy. The bounded metric can be of path-scope or link-scope. A path-scoped bounded metric is used when the bound is to be imposed on the cumulative metric associated with a path, while a link-scoped bounded metric is used when the bound is to be imposed on the metric associated with a link. An example of a path-scoped bounded metric specification is to ensure that the cumulative "TE Metric" along the traversed path does not exceed 1000. An example of a link-scoped bounded metric specification is to ensure that the "Delay Variation Threshold" on a traversed link does not exceed 15ms. 2. Procedure at the Ingress The optimization objective and/or the bounded metrics for the backup LSP MAY be specified at the ingress of the primary LSP via explicit configuration. The user may explicitly specify whether the optimization objective and/or bounded metrics of the local- protection-desiring LSP are to be inherited by the backup LSP at the PLR, or whether different values are to be used. If there is no such explicit configuration, the local PLR policy will dictate the optimization objective and the bounded metrics used for the backup LSP. If such explicit configuration is present, then the ingress of the primary LSP MUST signal an RSVP PATH message with the FAST_REROUTE_EXT object. The presence of the FAST_REROUTE_EXT object in the PATH message is to be deemed as a companion object to the FAST_REROUTE object. It is deemed a request to the PLR to establish the backup path using the optimization objective and/or the specified bounded metrics. The ingress MUST NOT include the FAST_REROUTE_EXT object in the PATH message unless it also includes the FAST_REROUTE object. When the ingress receives the corresponding RESV message, it can determine whether each PLR was able to cater to the signaled request by checking whether the "FRR_EXT protection" flag in the RESV RRO sub-object for that PLR is set. Deshmukh & Beeram Expires 1 September 2026 [Page 4] Internet-Draft MPLS FRR EXT February 2026 3. Procedure at the PLR A PLR that does not understand the FAST_REROUTE_EXT object MUST ignore the object in the PATH message but forward it unexamined and unmodified. The class number used for the object will ensure this behavior. In such a scenario, the local policy on PLR will dictate the optimization objective and bounded metrics for the backup path computation. A PLR that understands the FAST_REROUTE_EXT object but does not find the companion FAST_REROUTE object in the PATH message MUST reject the PATH with the following error - {Policy Control Failure (2), Missing FAST_REROUTE object (TBA3)}. A PLR that understands the FAST_REROUTE_EXT object but cannot cater to the requested optimization objective and bounded metrics MAY fall back onto the optimization objective and bounded metrics dictated by local policy. In such a scenario, the PLR MUST NOT set the "FRR_EXT protection" flag in the corresponding RESV RRO sub-object. A PLR that understands the FAST_REROUTE_EXT object and caters to the requested optimization objective and bounded metrics successfully MUST set the "FRR_EXT protection" flag in the corresponding RESV RRO sub-object. 4. Protocol Extensions 4.1. FAST_REROUTE_EXT Object The FAST_REROUTE_EXT Object carries a set of TLVs. It MAY be carried in an RSVP PATH message. It MUST carry at least one TLV when present. It MUST always be accompanied with a FAST_REROUTE object in the RSVP PATH message. Class-Num = TBA1 (Format - 11bbbbbb) C-Type = 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (TLVs) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * TLVs - Series of TLVs. Each TLV has the form: Deshmukh & Beeram Expires 1 September 2026 [Page 5] Internet-Draft MPLS FRR EXT February 2026 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ | Type | Length | (TLV contents) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ * The Length field in the TLV contains the total length of the TLV in bytes, including the Type and Length fields. The Length MUST be at least 4 and MUST be a multiple of 4. 4.1.1. Optimization Metric TLV Optimization Metric TLV carries the Metric-Type to be used in the optimization objective. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Metric Type | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Type = 1 - Optimization Metric TLV * Length = 4 * Metric Type: - 1 IGP - 2 TE - 3 Unreserved-Bandwidth - 4 Delay-Minimum - 5 Delay-Average - 6 Delay-Maximum * Weight: Metric Normalization Weight In some scenarios where multiple optimization objectives are desired, multiple Optimization Metric TLVs (each with a unique "Metric Type") MAY be packed into the FAST_REROUTE_EXT object. In such scenarios, the weight field is used for normalizing different metrics. When only one optimization objective is specified, the weight field is set to zero and is ignored. Deshmukh & Beeram Expires 1 September 2026 [Page 6] Internet-Draft MPLS FRR EXT February 2026 4.1.2. Bounded Metric TLV Bounded Metric TLV is used to carry the bound value for the specified Metric-Type. 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Metric Type | |L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric Bound | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Type = 2 Bounded Metric TLV * Length = 8 * Metric Type: - 1 IGP - 2 TE - 3 Unreserved-Bandwidth - 4 Delay-Minimum - 5 Delay-Average - 6 Delay-Maximum - 7 Delay-Variation-Threshold * L Flag: Link-Scope * Metric Bound: Bounded metric value. The units used and whether the bound is upper or lower depends on the metric-type. There can be more than one Bounded Metric TLV (each with a unique "Metric Type") packed into the FAST_REROUTE_EXT object. The Bounded Metric TLV, if present, MUST include a non-zero "Metric Bound" value. If there is a desire to specify a metric-bound for the same metric that is being optimized for, then the expectation is that both Optimization Metric TLV and Bounded Metric TLV for the same metric type are included in the FAST_REROUTE_EXT object. There MUST be at most one instance of the Bounded Metric TLV for each metric type with the same L flag (Link Scope) value. If two or more instances of a Bounded Metric TLV with the same L flag value are present for a Deshmukh & Beeram Expires 1 September 2026 [Page 7] Internet-Draft MPLS FRR EXT February 2026 metric type, only the first instance MUST be considered, and other instances MUST be ignored. The presence of two Bounded Metric TLV of the same type with a different value of the L flag is allowed. 4.2. RRO IPv4/IPv6 Sub-Object Flag FRR_EXT protection: TBA2 The PLR MUST set this bit in the RESV RRO IPv4/IPv6 sub-object when it has successfully catered to the optimization objective and/or bounded metrics specified in the FAST_REROUTE_EXT object received in the corresponding PATH message. The PLR MUST NOT set this bit if the request was not catered to. 5. Security Considerations The security considerations pertaining to the original RSVP protocol ([RFC2205], [RFC3209], and [RFC5920]) remain relevant. When using RSVP cryptographic authentication [RFC2747], more robust algorithms such as HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 [RFC2104] [FIPS-180-4] SHOULD be used when computing the keyed message digest where possible. 6. IANA Considerations 6.1. FAST_REROUTE_EXT Object IANA maintains the Class Names, Class Numbers, and Class Types registries in the "RSVP parameters" registry group (see http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml (http://www.iana.org/assignments/rsvp-parameters/rsvp- parameters.xml)). IANA is requested to extend these registries by adding a new Class Number (in the 11bbbbbb range) and assign a new C-Type under this Class Number, as described below: Class Number Class Name Reference TBA1 FAST_REROUTE_EXT This document Class Type of C-types - TBA1 FAST_REROUTE_EXT Value Description Reference 1 FAST_REROUTE_EXT This document IANA is requested to add a new sub-registry for "FAST_REROUTE_EXT TLVs" as shown below. New registrations can be added via "IETF Review" [RFC8126]. Deshmukh & Beeram Expires 1 September 2026 [Page 8] Internet-Draft MPLS FRR EXT February 2026 Type Description Reference 1 Optimization Metric This document 2 Bounded Metric This document 6.1.1. Metrics IANA manages several registries as part of the 'Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters' registry located at http://www.iana.org/assignments/rsvp-te-parameters (http://www.iana.org/assignments/rsvp-te-parameters). IANA is requested to extend this list of registries by adding two new registries - "FAST_REROUTE_EXT - Optimization Metric Types" and "FAST_REROUTE_EXT - Bounded Metric Types" as shown below. New registrations can be added via "IETF Review" [RFC8126]. FAST_REROUTE_EXT - Optimization Metric Types Value Metric Type 1 IGP 2 TE 3 Unreserved-Bandwidth 4 Delay-Minimum 5 Delay-Average 6 Delay-Maximum FAST_REROUTE_EXT - Bounded Metric Types Value Metric Type Path Link Scope Scope 1 IGP Y Y 2 TE Y Y 3 Unreserved-Bandwidth Y Y 4 Delay-Minimum Y Y 5 Delay-Average Y Y 6 Delay-Maximum Y Y 7 Delay-Variation-Threshold N Y 6.2. Record Route Object Sub-object Flags: FRR_EXT Protection IANA manages the 'Record Route Object Sub-object Flags' registry as part of the 'Resource Reservation Protocol-Traffic Engineering (RSVP- TE) Parameters' registry located at http://www.iana.org/assignments/ rsvp-te-parameters (http://www.iana.org/assignments/rsvp-te- parameters). IANA is requested to extend this registry by adding a new Flag as described below: Flag Description Reference TBA2 FRR_EXT protection This document Deshmukh & Beeram Expires 1 September 2026 [Page 9] Internet-Draft MPLS FRR EXT February 2026 6.3. Error Codes and Error Values IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a subregistry called "Error Codes and Globally-Defined Error Value Sub-Codes". Within this subregistry there is a definition of the "Policy Control Failure" error code with error code value 2. The definition lists a number of error values that may be used with this error code. IANA is requested to allocate a new value for use with this error code as described in this document. The resulting entry in the registry should look as follows: Sub-Codes - 2 Policy Control Failure This Error Code has the following globally-defined Error Value sub- codes: Value Description Reference TBA3 Missing FAST_REROUTE object This document 7. References 7.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, . [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, . [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, . Deshmukh & Beeram Expires 1 September 2026 [Page 10] Internet-Draft MPLS FRR EXT February 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [FIPS-180-4] National Institute of Standards and Technology, "Secure Hash Standard", , August 2015. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, DOI 10.17487/RFC2747, January 2000, . [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, . Acknowledgments The authors would like to thank Minjie Dai for his input from discussions. This document was prepared using kramdown. Contributors Chandrasekar Ramachandran HPE Email: chandrasekar.ramachandran@hpe.com Colby Barth HPE Email: jonathan.barth@hpe.com Authors' Addresses Abhishek Deshmukh HPE Email: abhishek.deshmukh@hpe.com Deshmukh & Beeram Expires 1 September 2026 [Page 11] Internet-Draft MPLS FRR EXT February 2026 Vishnu Pavan Beeram HPE Email: vishnupavan.ietf@gmail.com Deshmukh & Beeram Expires 1 September 2026 [Page 12]