



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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [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, <https://www.rfc-editor.org/rfc/rfc2205>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc3209>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc4090>.

   [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/rfc/rfc8126>.



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, <https://www.rfc-editor.org/rfc/rfc8174>.

7.2.  Informative References

   [FIPS-180-4]
              National Institute of Standards and Technology, "Secure
              Hash Standard", <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.180-4.pdf> , August 2015.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/rfc/rfc2104>.

   [RFC2747]  Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
              Authentication", RFC 2747, DOI 10.17487/RFC2747, January
              2000, <https://www.rfc-editor.org/rfc/rfc2747>.

   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
              <https://www.rfc-editor.org/rfc/rfc5920>.

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]
