rfc9705v1.txt   rfc9705.txt 
Internet Engineering Task Force (IETF) C. Ramachandran Internet Engineering Task Force (IETF) C. Ramachandran
Request for Comments: 9705 Juniper Networks, Inc. Request for Comments: 9705 Juniper Networks, Inc.
Updates: 4090 T. Saad Updates: 4090 T. Saad
Category: Standards Track Cisco Systems, Inc. Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 I. Minei ISSN: 2070-1721 D. Pacella
Google, Inc.
D. Pacella
Verizon, Inc. Verizon, Inc.
December 2024 March 2025
Refresh-Interval Independent Fast Reroute (FRR) Facility Protection Refresh-Interval Independent RSVP Fast Reroute Facility Protection
Abstract Abstract
The RSVP-TE Fast Reroute (FRR) extensions specified in RFC 4090 The RSVP-TE Fast Reroute (FRR) extensions specified in RFC 4090
define two local repair techniques to reroute Label Switched Path define two local repair techniques to reroute Label Switched Path
(LSP) traffic over pre-established backup tunnels. Facility backup (LSP) traffic over pre-established backup tunnels. Facility backup
methods allow one or more LSPs traversing a connected link or node to method allows one or more LSPs traversing a connected link or node to
be protected using a bypass tunnel. The many-to-one nature of local be protected using a bypass tunnel. The many-to-one nature of local
repair techniques is attractive from a scalability point of view. repair technique is attractive from a scalability point of view.
This document enumerates facility backup procedures in RFC 4090 that This document enumerates facility backup procedures in RFC 4090 that
rely on refresh timeout, hence, making facility backup methods rely on refresh timeout, hence, making facility backup method
refresh-interval dependent. The RSVP-TE extensions defined in this refresh-interval dependent. The RSVP-TE extensions defined in this
document will enhance the facility backup protection mechanism by document will enhance the facility backup protection mechanism by
making the corresponding procedures refresh-interval independent, and making the corresponding procedures refresh-interval independent, and
hence, compatible with the Refresh-Interval Independent RSVP (RI- hence, compatible with the Refresh-Interval Independent RSVP (RI-
RSVP) capability specified in RFC 8370. Hence, this document updates RSVP) capability specified in RFC 8370. Hence, this document updates
RFC 4090 in order to support the RI-RSVP capability specified in RFC RFC 4090 in order to support the RI-RSVP capability specified in RFC
8370. 8370.
Status of This Memo Status of This Memo
skipping to change at line 48 skipping to change at line 46
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9705. https://www.rfc-editor.org/info/rfc9705.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described Trust Legal Provisions and are provided without warranty as described
skipping to change at line 77 skipping to change at line 75
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1. Motivation 1.1. Motivation
2. Terminology 2. Abbreviations and Terminology
2.1. Requirements Language 2.1. Abbreviations
2.2. Terminology
3. Problem Description 3. Problem Description
4. Solution Aspects 4. Solution Aspects
4.1. Requirement on RFC 4090 Capable Node to Advertise the 4.1. Requirement for RFC 4090 Capable Nodes to Advertise the
RI-RSVP Capability RI-RSVP Capability
4.2. Signaling Handshake Between PLR and MP 4.2. Signaling Handshake Between PLR and MP
4.2.1. PLR Behavior 4.2.1. PLR Behavior
4.2.2. Remote Signaling Adjacency 4.2.2. Remote Signaling Adjacency
4.2.3. MP Behavior 4.2.3. MP Behavior
4.2.4. "Remote" State on MP 4.2.4. "Remote" State on MP
4.3. Impact of Failures on LSP State 4.3. Impact of Failures on LSP State
4.3.1. Non-MP Behavior 4.3.1. Non-MP Behavior
4.3.2. LP-MP Behavior 4.3.2. LP-MP Behavior
4.3.3. NP-MP Behavior 4.3.3. NP-MP Behavior
4.3.4. Behavior of a Router That Is Both the LP-MP and NP-MP 4.3.4. Behavior of a Router That Is Both the LP-MP and NP-MP
4.4. Conditional PathTear 4.4. Conditional PathTear
4.4.1. Sending the Conditional PathTear 4.4.1. Sending the Conditional PathTear
4.4.2. Processing the Conditional PathTear 4.4.2. Processing the Conditional PathTear
4.4.3. CONDITIONS Object 4.4.3. CONDITIONS Object
4.5. Remote State Teardown 4.5. Remote State Teardown
4.5.1. PLR Behavior on Local Repair Failure 4.5.1. PLR Behavior on Local Repair Failure
4.5.2. PLR Behavior on Resv RRO Change 4.5.2. PLR Behavior on Resv RRO Change
4.5.3. LSP Preemption During Local Repair 4.5.3. LSP Preemption During Local Repair
4.5.3.1. Preemption on LP-MP After Phop Link Failure 4.5.3.1. Preemption on LP-MP After PHOP Link Failure
4.5.3.2. Preemption on NP-MP After Phop Link Failure 4.5.3.2. Preemption on NP-MP After PHOP Link Failure
4.6. Backward Compatibility Procedures 4.6. Backward Compatibility Procedures
4.6.1. Detecting Support for Refresh-Interval Independent FRR 4.6.1. Detecting Support for Refresh-Interval Independent RSVP
FRR
4.6.2. Procedures for Backward Compatibility 4.6.2. Procedures for Backward Compatibility
4.6.2.1. Lack of Support on Downstream Nodes 4.6.2.1. Lack of Support on Downstream Nodes
4.6.2.2. Lack of Support on Upstream Nodes 4.6.2.2. Lack of Support on Upstream Nodes
4.6.2.3. Incremental Deployment 4.6.2.3. Incremental Deployment
4.7. Consequences of Advertising RI-RSVP Without RI-RSVP-FRR 4.7. Consequences of Advertising RI-RSVP Without RI-RSVP-FRR
5. Security Considerations 5. Security Considerations
6. IANA Considerations 6. IANA Considerations
6.1. CONDITIONS Object 6.1. CONDITIONS Object
7. References 7. References
7.1. Normative References 7.1. Normative References
skipping to change at line 143 skipping to change at line 143
to increase the message refresh interval to values much longer than to increase the message refresh interval to values much longer than
the default 30 seconds defined in [RFC2205]. However, the protocol the default 30 seconds defined in [RFC2205]. However, the protocol
extensions defined in [RFC4090] for supporting Fast Reroute (FRR) extensions defined in [RFC4090] for supporting Fast Reroute (FRR)
using bypass tunnels implicitly rely on short refresh timeouts to using bypass tunnels implicitly rely on short refresh timeouts to
clean up stale states. clean up stale states.
In order to eliminate the reliance on refresh timeouts, the routers In order to eliminate the reliance on refresh timeouts, the routers
should unambiguously determine when a particular LSP state should be should unambiguously determine when a particular LSP state should be
deleted. In scenarios involving FRR using bypass tunnels [RFC4090], deleted. In scenarios involving FRR using bypass tunnels [RFC4090],
additional explicit teardown messages are necessary. The Refresh- additional explicit teardown messages are necessary. The Refresh-
Interval Independent RSVP FRR (RI-RSVP-FRR) extensions specified in Interval Independent RSVP-TE FRR (RI-RSVP-FRR) extensions specified
this document consist of procedures to enable LSP state cleanup that in this document consist of procedures to enable LSP state cleanup
are essential in supporting the RI-RSVP capability for FRR using that are essential in supporting the RI-RSVP capability for FRR using
bypass tunnels from [RFC4090]. bypass tunnels from [RFC4090].
1.1. Motivation 1.1. Motivation
Base RSVP [RFC2205] maintains state via the generation of RSVP Path Base RSVP [RFC2205] maintains state via the generation of RSVP Path
and Resv refresh messages. Refresh messages are used to both and Resv refresh messages. Refresh messages are used to both
synchronize state between RSVP neighbors and to recover from lost synchronize state between RSVP neighbors and to recover from lost
RSVP messages. The use of Refresh messages to cover many possible RSVP messages. The use of Refresh messages to cover many possible
failures has resulted in a number of operational problems. failures has resulted in a number of operational problems.
* One problem relates to RSVP control plane scaling due to periodic * One problem relates to RSVP control plane scaling due to periodic
refreshes of Path and Resv messages and another relates to the refreshes of Path and Resv messages.
reliability and latency of RSVP signaling.
* Another problem relates to the reliability and latency of RSVP
signaling.
* An additional problem is the time to clean up the stale state * An additional problem is the time to clean up the stale state
after a tear message is lost. For more on these problems, see after a tear message is lost. For more on these problems, see
Section 1 of [RFC2961]. Section 1 of [RFC2961].
The problems listed above adversely affect RSVP control plane The problems listed above adversely affect RSVP control plane
scalability, and RSVP-TE [RFC3209] inherited these problems from scalability, and RSVP-TE [RFC3209] inherited these problems from
standard RSVP. Procedures specified in [RFC2961] address the above- standard RSVP. Procedures specified in [RFC2961] address the above-
mentioned problems by eliminating dependency on refreshes for state mentioned problems by eliminating dependency on refreshes for state
synchronization and for recovering from lost RSVP messages, and also synchronization and for recovering from lost RSVP messages, and also
skipping to change at line 183 skipping to change at line 185
Section 3 of [RFC8370]. Section 3 of [RFC8370].
However, the facility backup protection procedures specified in However, the facility backup protection procedures specified in
[RFC4090] do not fully address stale state cleanup as the procedures [RFC4090] do not fully address stale state cleanup as the procedures
depend on refresh timeouts for stale state cleanup. The updated depend on refresh timeouts for stale state cleanup. The updated
facility backup protection procedures specified in this document, in facility backup protection procedures specified in this document, in
combination with RSVP-TE Scaling Techniques [RFC8370], eliminate this combination with RSVP-TE Scaling Techniques [RFC8370], eliminate this
dependency on refresh timeouts for stale state cleanup. dependency on refresh timeouts for stale state cleanup.
The procedures specified in this document assume reliable delivery of The procedures specified in this document assume reliable delivery of
RSVP messages, as specified in [RFC2961]. Therefore, this document RSVP messages, as specified in [RFC2961]. Therefore, [RFC2961] is a
makes support for [RFC2961] a prerequisite. prerequisite for this document.
2. Terminology 2. Abbreviations and Terminology
The reader is expected to be familiar with the terminology in The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
[RFC2205], [RFC3209], [RFC4090], [RFC4558], [RFC8370], and [RFC8796]. "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.
Phop node: Previous-Hop router along the LSP In addition, the reader is expected to be familiar with the
terminology in [RFC2205], [RFC3209], [RFC4090], [RFC4558], [RFC8370],
and [RFC8796].
PPhop node: Previous-Previous-Hop router along the LSP 2.1. Abbreviations
Nhop node: Next-Hop router along the LSP PHOP: Previous-Hop (can refer to a router or node along the LSP)
NNhop node: Next-Next-Hop router along the LSP PPHOP: Previous-Previous-Hop (can refer to a router or node along
the LSP)
PLR: Point of Local Repair router as defined in [RFC4090] NHOP: Next-Hop (can refer to a router or node along the LSP)
MP: Merge Point router as defined in [RFC4090] NNHOP: Next-Next-Hop (can refer to a router or node along the LSP)
LP-MP node: Merge Point router at the tail of Link-Protecting bypass PLR: Point of Local Repair (can refer to a router as defined in
tunnel [RFC4090])
NP-MP node: Merge Point router at the tail of Node-Protecting bypass MP: Merge Point (can refer to a router as defined in [RFC4090])
tunnel
LP-MP: Link-Protecting Merge Point (can refer to a router or node at
the tail of a Link-Protecting bypass tunnel
NP-MP: Node-Protecting Merge Point (can refer to a router or node at
the tail of a Node-Protecting bypass tunnel
PSB: Path State Block PSB: Path State Block
RSB: Reservation State Block RSB: Reservation State Block
RRO: Record Route Object as defined in [RFC3209] RRO: Record Route Object (as defined in [RFC3209])
TED: Traffic Engineering Database TED: Traffic Engineering Database
LSP state: The combination of "path state" maintained as a PSB and RI-RSVP: Refresh-Interval Independent RSVP (the set of procedures
"reservation state" maintained as an RSB forms an individual LSP defined in Section 3 of [RFC8370] to eliminate RSVP's reliance on
state on an RSVP-TE speaker periodic message refreshes)
RI-RSVP: The set of procedures defined in Section 3 of [RFC8370] to RI-RSVP-FRR: Refresh-Interval Independent RSVP-TE FRR (the set of
eliminate RSVP's reliance on periodic message refreshes procedures defined in this document to eliminate RSVP's reliance
on periodic message refreshes when supporting facility backup
protection [RFC4090])
B-SFRR-Ready: Bypass Summary FRR Ready Extended Association object 2.2. Terminology
B-SFRR-Ready: Bypass Summary FRR Ready Extended ASSOCIATION object
as defined in [RFC8796] and added by the PLR for each protected as defined in [RFC8796] and added by the PLR for each protected
LSP LSP
RI-RSVP-FRR: The set of procedures defined in this document to
eliminate RSVP's reliance on periodic message refreshes when
supporting facility backup protection [RFC4090]
Conditional PathTear: A PathTear message containing a suggestion to Conditional PathTear: A PathTear message containing a suggestion to
a receiving downstream router to retain the path state if the a receiving downstream router to retain the path state if the
receiving router is an NP-MP receiving router is an NP-MP
Remote PathTear: A PathTear message sent from a PLR to the MP to Remote PathTear: A PathTear message sent from a PLR to the MP to
delete the LSP state on the MP if the PLR had not previously sent delete the LSP state on the MP if the PLR had not previously sent
the backup path state reliably the backup path state reliably
2.1. Requirements Language LSP state The combination of "path state" maintained as a PSB and
"reservation state" maintained as an RSB forms an individual LSP
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", state on an RSVP-TE speaker
"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.
3. Problem Description 3. Problem Description
E E
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
skipping to change at line 270 skipping to change at line 279
\ / \ /
\ / \ /
\ / \ /
\ / \ /
F F
Figure 1: Example Topology Figure 1: Example Topology
In the topology in Figure 1, consider a large number of LSPs from A In the topology in Figure 1, consider a large number of LSPs from A
to D transiting B and C. Assume that refresh interval has been to D transiting B and C. Assume that refresh interval has been
configured to be long of the order of minutes and refresh reduction configured to be as long as the order of minutes and that refresh
extensions are enabled on all routers. reduction extensions are enabled on all routers.
In addition, assume that node protection has been configured for the In addition, assume that node protection has been configured for the
LSPs and the LSPs are protected by each router in the following way: LSPs and the LSPs are protected by each router in the following way:
* A has made node protection available using bypass LSP A -> E -> C; * A has made node protection available using bypass LSP A -> E -> C;
A is the PLR and C is the NP-MP. A is the PLR and C is the NP-MP.
* B has made node protection available using bypass LSP B -> F -> D; * B has made node protection available using bypass LSP B -> F -> D;
B is the PLR and D is the NP-MP. B is the PLR and D is the NP-MP.
skipping to change at line 348 skipping to change at line 357
problems, which will then make it practical to scale up to a large problems, which will then make it practical to scale up to a large
number of protected LSPs in the network. number of protected LSPs in the network.
4. Solution Aspects 4. Solution Aspects
The solution consists of five parts: The solution consists of five parts:
1. Utilize the MP determination mechanism specified in RSVP-TE 1. Utilize the MP determination mechanism specified in RSVP-TE
Summary FRR [RFC8796] that enables the PLR to signal the Summary FRR [RFC8796] that enables the PLR to signal the
availability of local protection to the MP. In addition, availability of local protection to the MP. In addition,
introduce PLR and MP procedures to establish Node-ID-based Hello introduce PLR and MP procedures to establish a Node-ID-based
sessions between the PLR and the MP to detect router failures and Hello session between the PLR and the MP to detect router
to determine capability. See Section 4.2 of this document for failures and to determine capability. See Section 4.2 of this
more details. This part of the solution reuses some of the document for more details. This part of the solution reuses some
extensions defined in [RFC8796] and [RFC8370], and the subsequent of the extensions defined in [RFC8796] and [RFC8370], and the
subsections will list the extensions in these documents that are subsequent subsections will list the extensions in these
utilized in this document. documents that are utilized in this document.
2. Handle upstream link or node failures by cleaning up LSP states 2. Handle upstream link or node failures by cleaning up LSP states
if the node has not found itself as an MP through the MP if the node has not found itself as an MP through the MP
determination mechanism. See Section 4.3 of this document for determination mechanism. See Section 4.3 of this document for
more details. more details.
3. Introduce extensions to enable a router to send a teardown 3. Introduce extensions to enable a router to send a teardown
message to the downstream router that enables the receiving message to the downstream router that enables the receiving
router to conditionally delete its local LSP state. See router to conditionally delete its local LSP state. See
Section 4.4 of this document for more details. Section 4.4 of this document for more details.
4. Enhance facility backup protection by allowing a PLR to directly 4. Enhance facility backup protection by allowing a PLR to directly
send a teardown message to the MP without requiring the PLR to send a teardown message to the MP without requiring the PLR to
either have a working bypass LSP or have already signaled the either have a working bypass LSP or have already signaled the
backup LSP state. See Section 4.5 of this document for more backup LSP state. See Section 4.5 of this document for more
details. details.
5. Introduce extensions to enable the above procedures to be 5. Introduce extensions to enable the above procedures to be
backward compatible with routers along the LSP path running backward compatible with routers along the LSP running
implementations that do not support these procedures. See implementations that do not support these procedures. See
Section 4.6 of this document for more details. Section 4.6 of this document for more details.
4.1. Requirement on RFC 4090 Capable Node to Advertise the RI-RSVP 4.1. Requirement for RFC 4090 Capable Nodes to Advertise the RI-RSVP
Capability Capability
A node supporting facility backup protection [RFC4090] MUST NOT set A node supporting facility backup protection [RFC4090] MUST NOT set
the RI-RSVP flag (I-bit) that is defined in Section 3.1 of [RFC8370] the RI-RSVP flag (I-bit) that is defined in Section 3.1 of [RFC8370]
unless it supports all the extensions specified in the rest of this unless it supports all the extensions specified in the rest of this
document. Hence, this document updates [RFC4090] by defining document. Hence, this document updates [RFC4090] by defining
extensions and additional procedures over facility backup protection extensions and additional procedures over facility backup protection
[RFC4090] in order to advertise the RI-RSVP capability [RFC8370]. [RFC4090] in order to advertise the RI-RSVP capability [RFC8370].
However, if a node supporting facility backup protection [RFC4090] However, if a node supporting facility backup protection [RFC4090]
does set the RI-RSVP capability (I-bit) but does not support all the does set the RI-RSVP capability (I-bit) but does not support all the
skipping to change at line 406 skipping to change at line 415
4.2.1. PLR Behavior 4.2.1. PLR Behavior
As per the facility backup procedures [RFC4090], when an LSP becomes As per the facility backup procedures [RFC4090], when an LSP becomes
operational on a node and the "local protection desired" flag has operational on a node and the "local protection desired" flag has
been set in the SESSION_ATTRIBUTE object carried in the Path message been set in the SESSION_ATTRIBUTE object carried in the Path message
corresponding to the LSP, then the node attempts to make local corresponding to the LSP, then the node attempts to make local
protection available for the LSP. protection available for the LSP.
* If the "node protection desired" flag is set, then the node tries * If the "node protection desired" flag is set, then the node tries
to become a PLR by attempting to create an NP-bypass LSP to the to become a PLR by attempting to create an NP-bypass LSP to the
NNhop node avoiding the Nhop node on a protected LSP path. In NNHOP node avoiding the NHOP node on a protected LSP. In case
case node protection could not be made available, the node node protection could not be made available, the node attempts to
attempts to create an LP-bypass LSP to the Nhop node avoiding only create an LP-bypass LSP to the NHOP node avoiding only the link
the link that the protected LSP takes to reach the Nhop. that the protected LSP takes to reach the NHOP.
* If the "node protection desired" flag is not set, then the PLR * If the "node protection desired" flag is not set, then the PLR
attempts to create an LP-bypass LSP to the Nhop node avoiding the attempts to create an LP-bypass LSP to the NHOP node avoiding the
link that the protected LSP takes to reach the Nhop. link that the protected LSP takes to reach the NHOP.
With regard to the PLR procedures described above and specified in With regard to the PLR procedures described above and specified in
[RFC4090], this document specifies the following additional [RFC4090], this document specifies the following additional
procedures to support RI-RSVP [RFC8370]. procedures to support RI-RSVP [RFC8370].
* While selecting the destination address of the bypass LSP, the PLR * While selecting the destination address of the bypass LSP, the PLR
MUST select the router ID of the NNhop or Nhop node from the Node- MUST select the router ID of the NNHOP or NHOP node from the Node-
ID sub-object included in the RRO object that is carried in the ID sub-object included in the RRO that is carried in the most
most recent Resv message corresponding to the LSP. If the MP has recent Resv message corresponding to the LSP. If the MP has not
not included a Node-ID sub-object in the Resv RRO and if the PLR included a Node-ID sub-object in the Resv RRO and if the PLR and
and the MP are in the same area, then the PLR may utilize the TED the MP are in the same area, then the PLR may utilize the TED to
to determine the router ID corresponding to the interface address determine the router ID corresponding to the interface address
that is included by the MP in the RRO object. If the NP-MP in a that is included by the MP in the RRO. If the NP-MP in a
different IGP area has not included a Node-ID sub-object in the different IGP area has not included a Node-ID sub-object in the
RRO object, then the PLR MUST execute backward compatibility RRO, then the PLR MUST execute backward compatibility procedures
procedures as if the downstream nodes along the LSP do not support as if the downstream nodes along the LSP do not support the
the extensions defined in the document (see Section 4.6.2.1). extensions defined in the document (see Section 4.6.2.1).
* The PLR MUST also include its router ID in a Node-ID sub-object in * The PLR MUST also include its router ID in a Node-ID sub-object in
the RRO object that is carried in any subsequent Path message the RRO that is carried in any subsequent Path message
corresponding to the LSP. While including its router ID in the corresponding to the LSP. While doing so, the PLR MUST include
Node-ID sub-object carried in the outgoing Path message, the PLR the Node-ID sub-object after including its IPv4/IPv6 address or
MUST include the Node-ID sub-object after including its IPv4/IPv6 unnumbered interface ID sub-object.
address or unnumbered interface ID sub-object.
* In parallel to the attempt made to create an NP-bypass or an LP- * In parallel to the attempt made to create an NP-bypass or an LP-
bypass, the PLR MUST initiate a Node-ID-based Hello session to the bypass, the PLR MUST initiate a Node-ID-based Hello session to the
NNhop or Nhop node respectively along the LSP to establish the NNHOP or NHOP node respectively along the LSP to establish the
RSVP-TE signaling adjacency. This Hello session is used to detect RSVP-TE signaling adjacency. This Hello session is used to detect
MP node failure as well as to determine the capability of the MP MP node failure as well as to determine the capability of the MP
node. If the MP has set the I-bit in the CAPABILITY object node. The PLR MUST conclude that the MP supports the refresh-
[RFC8370] carried in the Hello message corresponding to the Node- interval independent FRR procedures defined in this document if
ID-based Hello session, then the PLR MUST conclude that the MP the MP has set the I-bit in the CAPABILITY object [RFC8370]
supports refresh-interval independent FRR procedures defined in carried in the Hello message corresponding to the Node-ID-based
this document. If the MP has not sent Node-ID-based Hello Hello session. If the MP has not sent Node-ID-based Hello
messages or has not set the I-bit in the CAPABILITY object messages or has not set the I-bit in the CAPABILITY object
[RFC8370], then the PLR MUST execute backward compatibility [RFC8370], then the PLR MUST execute backward compatibility
procedures defined in Section 4.6.2.1 of this document. procedures defined in Section 4.6.2.1 of this document.
* When the PLR associates a bypass to a protected LSP, it MUST * When the PLR associates a bypass to a protected LSP, it MUST
include a B-SFRR-Ready Extended Association object [RFC8796] and include a B-SFRR-Ready Extended ASSOCIATION object [RFC8796] and
trigger a Path message to be sent for the LSP. If a B-SFRR-Ready trigger a Path message to be sent for the LSP. If a B-SFRR-Ready
Extended Association object is included in the Path message Extended ASSOCIATION object is included in the Path message
corresponding to the LSP, the encoding and object ordering rules corresponding to the LSP, the encoding and object ordering rules
specified in RSVP-TE Summary FRR [RFC8796] MUST be followed. In specified in RSVP-TE Summary FRR [RFC8796] MUST be followed. In
addition to those rules, the PLR MUST set the Association Source addition to those rules, the PLR MUST set the Association Source
in the object to its Node-ID address. in the object to its Node-ID address.
4.2.2. Remote Signaling Adjacency 4.2.2. Remote Signaling Adjacency
A Node-ID-based RSVP-TE Hello session is one in which a Node-ID is A Node-ID-based RSVP-TE Hello session is one in which a Node-ID is
used in the source and the destination address fields of RSVP Hello used in the source and the destination address fields of RSVP Hello
messages [RFC4558]. This document extends Node-ID-based RSVP Hello messages [RFC4558]. This document extends Node-ID-based RSVP Hello
skipping to change at line 486 skipping to change at line 494
In the rest of the document, the terms "signaling adjacency" and In the rest of the document, the terms "signaling adjacency" and
"remote signaling adjacency" refer specifically to the RSVP-TE "remote signaling adjacency" refer specifically to the RSVP-TE
signaling adjacency. signaling adjacency.
4.2.3. MP Behavior 4.2.3. MP Behavior
With regard to the MP procedures that are defined in [RFC4090], this With regard to the MP procedures that are defined in [RFC4090], this
document specifies the following additional procedures to support RI- document specifies the following additional procedures to support RI-
RSVP as defined in [RFC8370]. RSVP as defined in [RFC8370].
Each node along an LSP path supporting the extensions defined in this Each node along an LSP supporting the extensions defined in this
document MUST also include its router ID in the Node-ID sub-object of document MUST also include its router ID in the Node-ID sub-object of
the RRO object that is carried in the Resv message of the the RRO that is carried in the Resv message of the corresponding LSP.
corresponding LSP. If the PLR has not included a Node-ID sub-object If the PLR has not included a Node-ID sub-object in the RRO that is
in the RRO object that is carried in the Path message and if the PLR carried in the Path message and if the PLR is in a different IGP
is in a different IGP area, then the router MUST NOT execute the MP area, then the router MUST NOT execute the MP procedures specified in
procedures specified in this document for those LSPs. Instead, the this document for those LSPs. Instead, the node MUST execute
node MUST execute backward compatibility procedures defined in backward compatibility procedures defined in Section 4.6.2.2 of this
Section 4.6.2.2 of this document as if the upstream nodes along the document as if the upstream nodes along the LSP do not support the
LSP do not support the extensions defined in this document. extensions defined in this document.
A node receiving a Path message should determine: A node receiving a Path message should determine:
* whether the message contains a B-SFRR-Ready Extended Association * whether the message contains a B-SFRR-Ready Extended ASSOCIATION
object with its own address as the bypass destination address and object with its own address as the bypass destination address and
* whether it has an operational Node-ID signaling adjacency with the * whether it has an operational Node-ID signaling adjacency with the
Association source. Association Source.
The node MUST execute the backward compatibility procedures defined The node MUST execute the backward compatibility procedures defined
in Section 4.6.2.2 of this document if: in Section 4.6.2.2 of this document if:
* the PLR has not included the B-SFRR-Ready Extended Association * the PLR has not included the B-SFRR-Ready Extended ASSOCIATION
object, object,
* there is no operational Node-ID signaling adjacency with the PLR * there is no operational Node-ID signaling adjacency with the PLR
identified by the Association source address, or identified by the Association Source address, or
* the PLR has not advertised the RI-RSVP capability in its Node-ID- * the PLR has not advertised the RI-RSVP capability in its Node-ID-
based Hello messages. based Hello messages.
If a matching B-SFRR-Ready Extended Association object is found in If a matching B-SFRR-Ready Extended ASSOCIATION object is found in
the Path message and if there is an operational remote Node-ID the Path message and if there is an operational remote Node-ID
signaling adjacency with the PLR (identified by the Association signaling adjacency with the PLR (identified by the Association
source) that has advertised the RI-RSVP capability (I-bit) [RFC8370], Source) that has advertised the RI-RSVP capability (I-bit) [RFC8370],
then the node MUST consider itself as the MP for the PLR. The then the node MUST consider itself as the MP for the PLR. The
matching and ordering rules for Bypass Summary FRR Extended matching and ordering rules for Bypass Summary FRR Extended
Association specified in RSVP-TE Summary FRR [RFC8796] MUST be Association specified in RSVP-TE Summary FRR [RFC8796] MUST be
followed by the implementations supporting this document. followed by the implementations supporting this document.
* If a matching Bypass Summary FRR Extended Association object is * If a matching Bypass Summary FRR Extended Association object is
included by the PPhop node of an LSP and if a corresponding Node- included by the PPHOP node of an LSP and if a corresponding Node-
ID signaling adjacency exists with the PPhop node, then the router ID signaling adjacency exists with the PPHOP node, then the router
MUST conclude it is the NP-MP. MUST conclude it is the NP-MP.
* If a matching Bypass Summary FRR Extended Association object is * If a matching Bypass Summary FRR Extended Association object is
included by the Phop node of an LSP and if a corresponding Node-ID included by the PHOP node of an LSP and if a corresponding Node-ID
signaling adjacency exists with the Phop node, then the router signaling adjacency exists with the PHOP node, then the router
MUST conclude it is the LP-MP. MUST conclude it is the LP-MP.
4.2.4. "Remote" State on MP 4.2.4. "Remote" State on MP
Once a router concludes it is the MP for a PLR running refresh- Once a router concludes it is the MP for a PLR running refresh-
interval independent FRR procedures as described in the preceding interval independent FRR procedures as described in the preceding
section, it MUST create a remote path state for the LSP. The only section, it MUST create a remote path state for the LSP. The only
difference between the "remote" path state and the LSP state is the difference between the "remote" path state and the LSP state is the
RSVP_HOP object. The RSVP_HOP object in a "remote" path state RSVP_HOP object. The RSVP_HOP object in a "remote" path state
contains the address that the PLR uses to send Node-ID Hello messages contains the address that the PLR uses to send Node-ID Hello messages
to the MP. to the MP.
The MP MUST consider the "remote" path state corresponding to the LSP The MP MUST consider the "remote" path state corresponding to the LSP
automatically deleted if: automatically deleted if:
* the MP later receives a Path message for the LSP with no matching * the MP later receives a Path message for the LSP with no matching
B-SFRR-Ready Extended Association object corresponding to the B-SFRR-Ready Extended ASSOCIATION object corresponding to the
PLR's IP address contained in the Path RRO, PLR's IP address contained in the Path RRO,
* the Node-ID signaling adjacency with the PLR goes down, * the Node-ID signaling adjacency with the PLR goes down,
* the MP receives backup LSP signaling for the LSP from the PLR, * the MP receives backup LSP signaling for the LSP from the PLR,
* the MP receives a PathTear for the LSP, or * the MP receives a PathTear for the LSP, or
* the MP deletes the LSP state on a local policy or an exception * the MP deletes the LSP state on a local policy or an exception
event. event.
skipping to change at line 591 skipping to change at line 599
Node failures are detected from the state of Node-ID Hello sessions Node failures are detected from the state of Node-ID Hello sessions
established with immediate neighbors. RSVP-TE Scaling Techniques established with immediate neighbors. RSVP-TE Scaling Techniques
[RFC8370] recommends that each node establish Node-ID Hello sessions [RFC8370] recommends that each node establish Node-ID Hello sessions
with all its immediate neighbors. A non-immediate PLR or MP failure with all its immediate neighbors. A non-immediate PLR or MP failure
is detected from the state of remote signaling adjacency established is detected from the state of remote signaling adjacency established
according to Section 4.2.2 of this document. according to Section 4.2.2 of this document.
4.3.1. Non-MP Behavior 4.3.1. Non-MP Behavior
When a router detects the Phop link or the Phop node failure for an When a router detects the PHOP link or the PHOP node failure for an
LSP and the router is not an MP for the LSP, then it MUST send a LSP and the router is not an MP for the LSP, then it MUST send a
Conditional PathTear (refer to Section 4.4 of this document) and Conditional PathTear (refer to Section 4.4 of this document) and
delete the PSB and RSB states corresponding to the LSP. delete the PSB and RSB states corresponding to the LSP.
4.3.2. LP-MP Behavior 4.3.2. LP-MP Behavior
When the Phop link for an LSP fails on a router that is an LP-MP for When the PHOP link for an LSP fails on a router that is an LP-MP for
the LSP, the LP-MP MUST retain the PSB and RSB states corresponding the LSP, the LP-MP MUST retain the PSB and RSB states corresponding
to the LSP until the occurrence of any of the following events: to the LSP until the occurrence of any of the following events:
* the Node-ID signaling adjacency with the Phop PLR goes down, * the Node-ID signaling adjacency with the PHOP PLR goes down,
* the MP receives a normal or "Remote" PathTear for its PSB, or * the MP receives a normal or "Remote" PathTear for its PSB, or
* the MP receives a ResvTear for its RSB. * the MP receives a ResvTear for its RSB.
When a router that is an LP-MP for an LSP detects Phop node failure When a router that is an LP-MP for an LSP detects PHOP node failure
from the Node-ID signaling adjacency state, the LP-MP MUST send a from the Node-ID signaling adjacency state, the LP-MP MUST send a
normal PathTear and delete the PSB and RSB states corresponding to normal PathTear and delete the PSB and RSB states corresponding to
the LSP. the LSP.
4.3.3. NP-MP Behavior 4.3.3. NP-MP Behavior
When a router that is an NP-MP for an LSP detects Phop link failure When a router that is an NP-MP for an LSP detects PHOP link failure
or Phop node failure from the Node-ID signaling adjacency, the router or PHOP node failure from the Node-ID signaling adjacency, the router
MUST retain the PSB and RSB states corresponding to the LSP until the MUST retain the PSB and RSB states corresponding to the LSP until the
occurrence of any of the following events: occurrence of any of the following events:
* the remote Node-ID signaling adjacency with the PPhop PLR goes * the remote Node-ID signaling adjacency with the PPHOP PLR goes
down, down,
* the MP receives a normal or "Remote" PathTear for its PSB, or * the MP receives a normal or "Remote" PathTear for its PSB, or
* the MP receives a ResvTear for its RSB. * the MP receives a ResvTear for its RSB.
When a router that is an NP-MP for an LSP does not detect the Phop When a router that is an NP-MP for an LSP does not detect the PHOP
link or the Phop node failure but receives a Conditional PathTear link or the PHOP node failure but receives a Conditional PathTear
from the Phop node, then the router MUST retain the PSB and RSB from the PHOP node, then the router MUST retain the PSB and RSB
states corresponding to the LSP until the occurrence of any of the states corresponding to the LSP until the occurrence of any of the
following events: following events:
* the remote Node-ID signaling adjacency with the PPhop PLR goes * the remote Node-ID signaling adjacency with the PPHOP PLR goes
down, down,
* the MP receives a normal or "Remote" PathTear for its PSB, or * the MP receives a normal or "Remote" PathTear for its PSB, or
* the MP receives a ResvTear for its RSB. * the MP receives a ResvTear for its RSB.
Receiving a Conditional PathTear from the Phop node will not impact Receiving a Conditional PathTear from the PHOP node will not impact
the "remote" state from the PPhop PLR. Note that the Phop node must the "remote" state from the PPHOP PLR. Note that the PHOP node must
have sent the Conditional PathTear as it was not an MP for the LSP have sent the Conditional PathTear as it was not an MP for the LSP
(see Section 4.3.1 of this document). (see Section 4.3.1 of this document).
In the example topology in Figure 1, we assume C and D are the NP-MPs In the example topology in Figure 1, we assume C and D are the NP-MPs
for the PLRs A and B, respectively. Now, when the A-B link fails, B for the PLRs A and B, respectively. Now, when the A-B link fails, B
will delete the LSP state, because B is not an MP and its Phop link will delete the LSP state, because B is not an MP and its PHOP link
has failed (this behavior is required for unprotected LSPs; refer to has failed (this behavior is required for unprotected LSPs; refer to
Section 4.3.1 of this document). In the data plane, that would Section 4.3.1 of this document). In the data plane, that would
require B to delete the label forwarding entry corresponding to the require B to delete the label forwarding entry corresponding to the
LSP. Thus, if B's downstream nodes C and D continue to retain state, LSP. Thus, if B's downstream nodes C and D continue to retain state,
it would not be correct for D to continue to assume itself as the NP- it would not be correct for D to continue to assume itself as the NP-
MP for the PLR B. MP for the PLR B.
The mechanism that enables D to stop considering itself as the NP-MP The mechanism that enables D to stop considering itself as the NP-MP
for B and delete the corresponding "remote" path state is given for B and delete the corresponding "remote" path state is given
below. below.
1. When C receives a Conditional PathTear from B, it decides to 1. When C receives a Conditional PathTear from B, it decides to
retain the LSP state as it is the NP-MP of the PLR A. It also retain the LSP state as it is the NP-MP of the PLR A. It also
checks whether Phop B had previously signaled availability of checks whether PHOP B had previously signaled availability of
node protection. As B had previously signaled NP availability by node protection. As B had previously signaled NP availability by
including the B-SFRR-Ready Extended Association object, C removes including the B-SFRR-Ready Extended ASSOCIATION object, C removes
the B-SFRR-Ready Extended Association object containing the the B-SFRR-Ready Extended ASSOCIATION object containing the
Association Source set to B from the Path message and triggers a Association Source set to B from the Path message and triggers a
Path to D. Path to D.
2. When D receives the Path message, it realizes that it is no 2. When D receives the Path message, it realizes that it is no
longer the NP-MP for B and so it deletes the corresponding longer the NP-MP for B and so it deletes the corresponding
"remote" path state. D does not propagate the Path further down "remote" path state. D does not propagate the Path further down
because the only change is that the B-SFRR-Ready Extended because the only change is that the B-SFRR-Ready Extended
Association object corresponding to Association Source B is no ASSOCIATION object corresponding to Association Source B is no
longer present in the Path message. longer present in the Path message.
4.3.4. Behavior of a Router That Is Both the LP-MP and NP-MP 4.3.4. Behavior of a Router That Is Both the LP-MP and NP-MP
A router may simultaneously be the LP-MP and the NP-MP for the Phop A router may simultaneously be the LP-MP and the NP-MP for the PHOP
and PPhop nodes of an LSP, respectively. If the Phop link fails on and PPHOP nodes of an LSP, respectively. If the PHOP link fails on
such a node, the node MUST retain the PSB and RSB states such a node, the node MUST retain the PSB and RSB states
corresponding to the LSP until the occurrence of any of the following corresponding to the LSP until the occurrence of any of the following
events: events:
* both Node-ID signaling adjacencies with Phop and PPhop nodes go * both Node-ID signaling adjacencies with PHOP and PPHOP nodes go
down, down,
* the MP receives a normal or "Remote" PathTear for its PSB, or * the MP receives a normal or "Remote" PathTear for its PSB, or
* the MP receives a ResvTear for its RSB. * the MP receives a ResvTear for its RSB.
If a router that is both an LP-MP and an NP-MP detects Phop node If a router that is both an LP-MP and an NP-MP detects PHOP node
failure, then the node MUST retain the PSB and RSB states failure, then the node MUST retain the PSB and RSB states
corresponding to the LSP until the occurrence of any of the following corresponding to the LSP until the occurrence of any of the following
events: events:
* the remote Node-ID signaling adjacency with the PPhop PLR goes * the remote Node-ID signaling adjacency with the PPHOP PLR goes
down, down,
* the MP receives a normal or "Remote" PathTear for its PSB, or * the MP receives a normal or "Remote" PathTear for its PSB, or
* the MP receives a ResvTear for its RSB. * the MP receives a ResvTear for its RSB.
4.4. Conditional PathTear 4.4. Conditional PathTear
In the example provided in Section 4.3.3 of this document, B deletes In the example provided in Section 4.3.3 of this document, B deletes
the PSB and RSB states corresponding to the LSP once B detects its the PSB and RSB states corresponding to the LSP once B detects its
Phop link that went down as B is not an MP. If B were to send a PHOP link has gone down as B is not an MP. If B were to send a
PathTear normally, then C would delete the LSP state immediately. In PathTear normally, then C would delete the LSP state immediately. In
order to avoid this, there should be some mechanism by which B can order to avoid this, there should be some mechanism by which B can
indicate to C that B does not require the receiving node to indicate to C that B does not require the receiving node to
unconditionally delete the LSP state immediately. For this, B MUST unconditionally delete the LSP state immediately. For this, B MUST
add a new optional CONDITIONS object in the PathTear. The CONDITIONS add a new optional CONDITIONS object in the PathTear. The CONDITIONS
object is defined in Section 4.4.3 of this document. If node C also object is defined in Section 4.4.3 of this document. If node C also
understands the new object, then C MUST NOT delete the LSP state if understands the new object, then C MUST NOT delete the LSP state if
it is an NP-MP. it is an NP-MP.
4.4.1. Sending the Conditional PathTear 4.4.1. Sending the Conditional PathTear
A router that is not an MP for an LSP MUST delete the PSB and RSB A router that is not an MP for an LSP MUST delete the PSB and RSB
states corresponding to the LSP if the Phop link or the Phop Node-ID states corresponding to the LSP if the PHOP link or the PHOP Node-ID
signaling adjacency goes down (see Section 4.3.1 of this document). signaling adjacency goes down (see Section 4.3.1 of this document).
The router MUST send a Conditional PathTear if the following are also The router MUST send a Conditional PathTear if the following are also
true: true:
* the ingress has requested node protection for the LSP and * the ingress has requested node protection for the LSP and
* no PathTear is received from the upstream node. * no PathTear is received from the upstream node.
4.4.2. Processing the Conditional PathTear 4.4.2. Processing the Conditional PathTear
When a router that is not an NP-MP receives a Conditional PathTear, When a router that is not an NP-MP receives a Conditional PathTear,
the node MUST delete the PSB and RSB states corresponding to the LSP the node MUST delete the PSB and RSB states corresponding to the LSP
and process the Conditional PathTear by considering it as a normal and process the Conditional PathTear by considering it as a normal
PathTear. Specifically, the node MUST NOT propagate the Conditional PathTear. Specifically, the node MUST NOT propagate the Conditional
PathTear downstream but remove the optional object and send a normal PathTear downstream but remove the optional object and send a normal
PathTear downstream. PathTear downstream.
When a node that is an NP-MP receives a Conditional PathTear, it MUST When a node that is an NP-MP receives a Conditional PathTear, it MUST
NOT delete the LSP state. The node MUST check whether the Phop node NOT delete the LSP state. The node MUST check whether the PHOP node
had previously included the B-SFRR-Ready Extended Association object had previously included the B-SFRR-Ready Extended ASSOCIATION object
in the Path. If the object had been included previously by the Phop, in the Path. If the object had been included previously by the PHOP,
then the node processing the Conditional PathTear from the Phop MUST then the node processing the Conditional PathTear from the PHOP MUST
remove the corresponding object and trigger a Path downstream. remove the corresponding object and trigger a Path downstream.
If a Conditional PathTear is received from a neighbor that has not If a Conditional PathTear is received from a neighbor that has not
advertised support (refer to Section 4.6 of this document) for the advertised support (refer to Section 4.6 of this document) for the
new procedures defined in this document, then the node MUST consider new procedures defined in this document, then the node MUST consider
the message as a normal PathTear. The node MUST propagate the normal the message as a normal PathTear. The node MUST propagate the normal
PathTear downstream and delete the LSP state. PathTear downstream and delete the LSP state.
4.4.3. CONDITIONS Object 4.4.3. CONDITIONS Object
skipping to change at line 827 skipping to change at line 835
4.5.1. PLR Behavior on Local Repair Failure 4.5.1. PLR Behavior on Local Repair Failure
If local repair fails on the PLR after a failure, the PLR MUST send a If local repair fails on the PLR after a failure, the PLR MUST send a
"Remote" PathTear to the MP. The purpose of this is to clean up LSP "Remote" PathTear to the MP. The purpose of this is to clean up LSP
state from the PLR to the egress. Upon receiving the PathTear, the state from the PLR to the egress. Upon receiving the PathTear, the
MP MUST delete the states corresponding to the LSP and also propagate MP MUST delete the states corresponding to the LSP and also propagate
the PathTear downstream, thereby achieving state cleanup from all the PathTear downstream, thereby achieving state cleanup from all
downstream nodes up to the LSP egress. Note that in the case of link downstream nodes up to the LSP egress. Note that in the case of link
protection, the PathTear MUST be directed to the LP-MP's Node-ID IP protection, the PathTear MUST be directed to the LP-MP's Node-ID IP
address rather than the Nhop interface address. address rather than the NHOP interface address.
4.5.2. PLR Behavior on Resv RRO Change 4.5.2. PLR Behavior on Resv RRO Change
When a PLR router that has already made NP available for an LSP When a PLR router that has already made NP available for an LSP
detects a change in the RRO carried in the Resv message that detects a change in the RRO carried in the Resv message that
indicates that the router's former NP-MP is no longer present on the indicates that the router's former NP-MP is no longer present on the
path of the LSP, then the router MUST send a "Remote" PathTear path of the LSP, then the router MUST send a "Remote" PathTear
directly to its former NP-MP. directly to its former NP-MP.
In the example topology in Figure 1, assume node A has made node In the example topology in Figure 1, assume node A has made node
skipping to change at line 862 skipping to change at line 870
not contain C. When A processes the Resv message with a new RRO not not contain C. When A processes the Resv message with a new RRO not
containing C, its former NP-MP, A, sends a "Remote" PathTear to C. containing C, its former NP-MP, A, sends a "Remote" PathTear to C.
When C receives the "Remote" PathTear for its PSB state, C will send When C receives the "Remote" PathTear for its PSB state, C will send
a normal PathTear downstream to D and delete both the PSB and RSB a normal PathTear downstream to D and delete both the PSB and RSB
states corresponding to the LSP. As D has already received backup states corresponding to the LSP. As D has already received backup
LSP signaling from B, D will retain the control plane and forwarding LSP signaling from B, D will retain the control plane and forwarding
states corresponding to the LSP. states corresponding to the LSP.
4.5.3. LSP Preemption During Local Repair 4.5.3. LSP Preemption During Local Repair
4.5.3.1. Preemption on LP-MP After Phop Link Failure 4.5.3.1. Preemption on LP-MP After PHOP Link Failure
If an LSP is preempted on an LP-MP after its Phop link has already If an LSP is preempted on an LP-MP after its PHOP link has already
failed but the backup LSP has not been signaled yet as part of the failed but the backup LSP has not been signaled yet as part of the
local repair procedure, then the node MUST send a normal PathTear and local repair procedure, then the node MUST send a normal PathTear and
delete both the PSB and RSB states corresponding to the LSP. As the delete both the PSB and RSB states corresponding to the LSP. As the
LP-MP has retained the LSP state expecting the PLR to initiate backup LP-MP has retained the LSP state expecting the PLR to initiate backup
LSP signaling, preemption would bring down the LSP and the node would LSP signaling, preemption would bring down the LSP and the node would
not be LP-MP anymore, requiring the node to clean up the LSP state. not be LP-MP anymore, requiring the node to clean up the LSP state.
4.5.3.2. Preemption on NP-MP After Phop Link Failure 4.5.3.2. Preemption on NP-MP After PHOP Link Failure
If an LSP is preempted on an NP-MP after its Phop link has already If an LSP is preempted on an NP-MP after its PHOP link has already
failed but the backup LSP has not been signaled yet, then the node failed but the backup LSP has not been signaled yet, then the node
MUST send a normal PathTear and delete the PSB and RSB states MUST send a normal PathTear and delete the PSB and RSB states
corresponding to the LSP. As the NP-MP has retained the LSP state corresponding to the LSP. As the NP-MP has retained the LSP state
expecting the PLR to initiate backup LSP signaling, preemption would expecting the PLR to initiate backup LSP signaling, preemption would
bring down the LSP and the node would not be NP-MP anymore, requiring bring down the LSP and the node would not be NP-MP anymore, requiring
the node to clean up LSP state. the node to clean up LSP state.
Consider that the B-C link goes down on the same example topology Consider that the B-C link goes down on the same example topology
(Figure 1). As C is the NP-MP for the PLR A, C will retain the LSP (Figure 1). As C is the NP-MP for the PLR A, C will retain the LSP
state. state.
1. The LSP is preempted on C. 1. The LSP is preempted on C.
2. C will delete the RSB state corresponding to the LSP. However, C 2. C will delete the RSB state corresponding to the LSP. However, C
cannot send a PathErr or a ResvTear to the PLR A because the cannot send a PathErr or a ResvTear to the PLR A because the
backup LSP has not been signaled yet. backup LSP has not been signaled yet.
3. As the only reason for C having retained state after Phop node 3. As the only reason for C having retained state after PHOP node
failure was that it was an NP-MP, C sends a normal PathTear to D failure was that it was an NP-MP, C sends a normal PathTear to D
and also deletes its PSB state. D would also delete the PSB and and also deletes its PSB state. D would also delete the PSB and
RSB states on receiving a PathTear from C. RSB states on receiving a PathTear from C.
4. B starts backup LSP signaling to D. However, as D does not have 4. B starts backup LSP signaling to D. However, as D does not have
the LSP state, it will reject the backup LSP Path and send a the LSP state, it will reject the backup LSP Path message and
PathErr to B. send a PathErr to B.
5. B will delete its reservation and send a ResvTear to A. 5. B will delete its reservation and send a ResvTear to A.
4.6. Backward Compatibility Procedures 4.6. Backward Compatibility Procedures
"Refresh-Interval Independent FRR" and "RI-RSVP-FRR" refer to the set "Refresh-Interval Independent RSVP FRR" and "RI-RSVP-FRR" refer to
of procedures defined in this document to eliminate the reliance on the set of procedures defined in this document to eliminate the
periodic refreshes. The extensions proposed in RSVP-TE Summary FRR reliance on periodic refreshes. The extensions proposed in RSVP-TE
[RFC8796] may apply to implementations that do not support RI-RSVP- Summary FRR [RFC8796] may apply to implementations that do not
FRR. On the other hand, RI-RSVP-FRR extensions relating to LSP state support RI-RSVP-FRR. On the other hand, RI-RSVP-FRR extensions
cleanup, namely Conditional and "Remote" PathTears, require support relating to LSP state cleanup, namely Conditional and "Remote"
from one-hop and two-hop neighboring nodes along the LSP path. Thus, PathTears, require support from one-hop and two-hop neighboring nodes
procedures that fall under the LSP state cleanup category MUST NOT be along the LSP. Thus, procedures that fall under the LSP state
turned on if any of the nodes involved in the node protection FRR cleanup category MUST NOT be turned on if any of the nodes involved
(i.e., the PLR, the MP, and the intermediate node in the case of NP) in the node protection FRR (i.e., the PLR, the MP, and the
do not support RI-RSVP-FRR extensions. Note that for LSPs requesting intermediate node in the case of NP) do not support RI-RSVP-FRR
link protection, only the PLR and the LP-MP MUST support the extensions. Note that for LSPs requesting link protection, only the
extensions. PLR and the LP-MP MUST support the extensions.
4.6.1. Detecting Support for Refresh-Interval Independent FRR 4.6.1. Detecting Support for Refresh-Interval Independent RSVP FRR
An implementation supporting RI-RSVP-FRR extensions MUST set the flag An implementation supporting RI-RSVP-FRR extensions MUST set the RI-
"Refresh interval Independent RSVP" or RI-RSVP flag in the CAPABILITY RSVP Capable flag in the CAPABILITY object carried in Hello messages
object carried in Hello messages as specified in RSVP-TE Scaling as specified in RSVP-TE Scaling Techniques [RFC8370]. If an
Techniques [RFC8370]. If an implementation does not set the flag implementation does not set the flag even if it supports RI-RSVP-FRR
even if it supports RI-RSVP-FRR extensions, then its neighbors will extensions, then its neighbors will view the node as any node that
view the node as any node that does not support the extensions. does not support the extensions.
* As nodes supporting the RI-RSVP-FRR extensions initiate Node-ID- * As nodes supporting the RI-RSVP-FRR extensions initiate Node-ID-
based signaling adjacency with all immediate neighbors, such a based signaling adjacency with all immediate neighbors, such a
node on the path of a protected LSP can determine whether its Phop node on the path of a protected LSP can determine whether its PHOP
and Nhop neighbors support RI-RSVP-FRR enhancements. and NHOP neighbors support RI-RSVP-FRR enhancements.
* As nodes supporting the RI-RSVP-FRR extensions also initiate Node- * As nodes supporting the RI-RSVP-FRR extensions also initiate Node-
ID-based signaling adjacency with the NNhop along the path of the ID-based signaling adjacency with the NNHOP along the path of the
LSP requesting node protection (see Section 4.2.1 of this LSP requesting node protection (see Section 4.2.1 of this
document), each node along the LSP path can determine whether its document), each node along the LSP can determine whether its NNHOP
NNhop node supports RI-RSVP-FRR enhancements. If the NNhop (a) node supports RI-RSVP-FRR enhancements. If the NNHOP (a) does not
does not reply to remote Node-ID Hello messages or (b) does not reply to remote Node-ID Hello messages or (b) does not set the RI-
set the RI-RSVP flag in the CAPABILITY object carried in its Node- RSVP flag in the CAPABILITY object carried in its Node-ID Hello
ID Hello messages, then the node acting as the PLR can conclude messages, then the node acting as the PLR can conclude that NNHOP
that NNhop does not support RI-RSVP-FRR extensions. does not support RI-RSVP-FRR extensions.
* If node protection is requested for an LSP and if (a) the PPhop * If node protection is requested for an LSP and if (a) the PPHOP
node has not included a matching B-SFRR-Ready Extended Association node has not included a matching B-SFRR-Ready Extended ASSOCIATION
object in its Path messages, (b) the PPhop node has not initiated object in its Path messages, (b) the PPHOP node has not initiated
remote Node-ID Hello messages, or (c) the PPhop node does not set remote Node-ID Hello messages, or (c) the PPHOP node does not set
the RI-RSVP flag in the CAPABILITY object carried in its Node-ID the RI-RSVP flag in the CAPABILITY object carried in its Node-ID
Hello messages, then the node MUST conclude that the PLR does not Hello messages, then the node MUST conclude that the PLR does not
support RI-RSVP-FRR extensions. support RI-RSVP-FRR extensions.
4.6.2. Procedures for Backward Compatibility 4.6.2. Procedures for Backward Compatibility
Every node that supports RI-RSVP-FRR MUST support the procedures Every node that supports RI-RSVP-FRR MUST support the procedures
defined in this section in order to support backward compatibility defined in this section in order to support backward compatibility
for those subsets of LSPs that also traverse nodes that do not for those subsets of LSPs that also traverse nodes that do not
support RI-RSVP-FRR. support RI-RSVP-FRR.
4.6.2.1. Lack of Support on Downstream Nodes 4.6.2.1. Lack of Support on Downstream Nodes
The procedures on the downstream direction are as follows: The procedures on the downstream direction are as follows:
* If a node finds that the Nhop node along the LSP does not support * If a node finds that the NHOP node along the LSP does not support
the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh
period" in the TIME_VALUES object carried in the Path messages to period" in the TIME_VALUES object carried in the Path messages to
the default short refresh interval. the default short refresh interval.
* If node protection is requested for the LSP and the NNhop node * If node protection is requested for the LSP and the NNHOP node
along the LSP path does not support the RI-RSVP-FRR extensions, along the LSP does not support the RI-RSVP-FRR extensions, then
then the node MUST reduce the "refresh period" in the TIME_VALUES the node MUST reduce the "refresh period" in the TIME_VALUES
object carried in the Path messages to the default short refresh object carried in the Path messages to the default short refresh
interval. interval.
If a node reduces the refresh time using the above procedures, it If a node reduces the refresh time using the above procedures, it
MUST NOT send any "Remote" PathTear or Conditional PathTear message MUST NOT send any "Remote" PathTear or Conditional PathTear message
to the downstream node. to the downstream node.
Consider the example topology in Figure 1. If C does not support the Consider the example topology in Figure 1. If C does not support the
RI-RSVP-FRR extensions, then: RI-RSVP-FRR extensions, then:
* A and B reduce the refresh time to the default short refresh * A and B reduce the refresh time to the default short refresh
interval of 30 seconds and trigger a Path message. interval of 30 seconds and trigger a Path message.
* If B is not an MP and if the Phop link of B fails, B cannot send a * If B is not an MP and if the PHOP link of B fails, B cannot send a
Conditional PathTear to C but times out the PSB state from A Conditional PathTear to C but times out the PSB state from A
normally. Note that B can only normally time out the PSB state A normally. Note that B can only normally time out the PSB state A
if A did not set the long refresh in the TIME_VALUES object if A did not set the long refresh in the TIME_VALUES object
carried in the Path messages sent earlier. carried in the Path messages sent earlier.
4.6.2.2. Lack of Support on Upstream Nodes 4.6.2.2. Lack of Support on Upstream Nodes
The procedures on the upstream direction are as follows: The procedures on the upstream direction are as follows:
* If a node finds that the Phop node along the LSP path does not * If a node finds that the PHOP node along the LSP does not support
support the RI-RSVP-FRR extensions, then the node MUST reduce the the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh
"refresh period" in the TIME_VALUES object carried in the Resv period" in the TIME_VALUES object carried in the Resv messages to
messages to the default short refresh interval. the default short refresh interval.
* If node protection is requested for the LSP and the Phop node * If node protection is requested for the LSP and the PHOP node
along the LSP path does not support the RI-RSVP-FRR extensions, along the LSP does not support the RI-RSVP-FRR extensions, then
then the node MUST reduce the "refresh period" in the TIME_VALUES the node MUST reduce the "refresh period" in the TIME_VALUES
object carried in the Path messages to the default short refresh object carried in the Path messages to the default short refresh
interval (thus, the Nhop can use compatible values when sending a interval (thus, the NHOP can use compatible values when sending a
Resv). Resv).
* If node protection is requested for the LSP and the PPhop node * If node protection is requested for the LSP and the PPHOP node
does not support the RI-RSVP-FRR extensions, then the node MUST does not support the RI-RSVP-FRR extensions, then the node MUST
reduce the "refresh period" in the TIME_VALUES object carried in reduce the "refresh period" in the TIME_VALUES object carried in
the Resv messages to the default short refresh interval. the Resv messages to the default short refresh interval.
* If the node reduces the refresh time using the above procedures, * If the node reduces the refresh time using the above procedures,
it MUST NOT execute MP procedures specified in Section 4.3 of this it MUST NOT execute MP procedures specified in Section 4.3 of this
document. document.
4.6.2.3. Incremental Deployment 4.6.2.3. Incremental Deployment
The backward compatibility procedures described in the previous The backward compatibility procedures described in the previous
subsections imply that a router supporting the RI-RSVP-FRR extensions subsections imply that a router supporting the RI-RSVP-FRR extensions
specified in this document can apply the procedures specified in this specified in this document can apply the procedures specified in this
document either in the downstream or upstream direction of an LSP, document either in the downstream or upstream direction of an LSP,
depending on the capability of the routers downstream or upstream in depending on the capability of the routers downstream or upstream in
the LSP path. the LSP.
* RI-RSVP-FRR extensions and procedures are enabled for downstream * RI-RSVP-FRR extensions and procedures are enabled for downstream
Path, PathTear, and ResvErr messages corresponding to an LSP if Path, PathTear, and ResvErr messages corresponding to an LSP if
link protection is requested for the LSP and the Nhop node link protection is requested for the LSP and the NHOP node
supports the extensions. supports the extensions.
* RI-RSVP-FRR extensions and procedures are enabled for downstream * RI-RSVP-FRR extensions and procedures are enabled for downstream
Path, PathTear, and ResvErr messages corresponding to an LSP if Path, PathTear, and ResvErr messages corresponding to an LSP if
node protection is requested for the LSP and both Nhop and NNhop node protection is requested for the LSP and both NHOP and NNHOP
nodes support the extensions. nodes support the extensions.
* RI-RSVP-FRR extensions and procedures are enabled for upstream * RI-RSVP-FRR extensions and procedures are enabled for upstream
PathErr, Resv, and ResvTear messages corresponding to an LSP if PathErr, Resv, and ResvTear messages corresponding to an LSP if
link protection is requested for the LSP and the Phop node link protection is requested for the LSP and the PHOP node
supports the extensions. supports the extensions.
* RI-RSVP-FRR extensions and procedures are enabled for upstream * RI-RSVP-FRR extensions and procedures are enabled for upstream
PathErr, Resv, and ResvTear messages corresponding to an LSP if PathErr, Resv, and ResvTear messages corresponding to an LSP if
node protection is requested for the LSP and both Phop and PPhop node protection is requested for the LSP and both PHOP and PPHOP
nodes support the extensions. nodes support the extensions.
For example, if an implementation supporting the RI-RSVP-FRR For example, if an implementation supporting the RI-RSVP-FRR
extensions specified in this document is deployed on all routers in a extensions specified in this document is deployed on all routers in a
particular region of the network and if all the LSPs in the network particular region of the network and if all the LSPs in the network
request node protection, then the FRR extensions will only be applied request node protection, then the FRR extensions will only be applied
for the LSP segments that traverse the particular region. This will for the LSP segments that traverse the particular region. This will
aid incremental deployment of these extensions and also allow reaping aid incremental deployment of these extensions and also allow reaping
the benefits of the extensions in portions of the network where it is the benefits of the extensions in portions of the network where it is
supported. supported.
skipping to change at line 1064 skipping to change at line 1072
If a node supporting facility backup protection [RFC4090] sets the If a node supporting facility backup protection [RFC4090] sets the
RI-RSVP capability (I-bit) but does not support the RI-RSVP-FRR RI-RSVP capability (I-bit) but does not support the RI-RSVP-FRR
extensions, due to an implementation bug or configuration error, then extensions, due to an implementation bug or configuration error, then
it leaves room for the stale state to linger around for an inordinate it leaves room for the stale state to linger around for an inordinate
period of time or for disruption of normal FRR operations (see period of time or for disruption of normal FRR operations (see
Section 3 of this document). Consider the example topology Section 3 of this document). Consider the example topology
(Figure 1) provided in this document. (Figure 1) provided in this document.
* Assume node B does set the RI-RSVP capability in its Node-ID-based * Assume node B does set the RI-RSVP capability in its Node-ID-based
Hello messages even though it does not support RI-RSVP-FRR Hello messages even though it does not support RI-RSVP-FRR
extensions. When B detects the failure of its Phop link along an extensions. When B detects the failure of its PHOP link along an
LSP, it will not send a Conditional PathTear to C as required by LSP, it will not send a Conditional PathTear to C as required by
the RI-RSVP-FRR procedures. If B simply leaves the LSP state the RI-RSVP-FRR procedures. If B simply leaves the LSP state
without deleting, then B may end up holding on to the stale state without deleting, then B may end up holding on to the stale state
until the (long) refresh timeout. until the (long) refresh timeout.
* Instead of node B, assume node C does set the RI-RSVP capability * Instead of node B, assume node C does set the RI-RSVP capability
in its Node-ID-based Hello messages even though it does not in its Node-ID-based Hello messages even though it does not
support RI-RSVP-FRR extensions. When B details the failure of its support RI-RSVP-FRR extensions. When B details the failure of its
Phop link along an LSP, it will send a Conditional PathTear to C PHOP link along an LSP, it will send a Conditional PathTear to C
as required by the RI-RSVP-FRR procedures. However, C would not as required by the RI-RSVP-FRR procedures. However, C would not
recognize the condition encoded in the PathTear and end up tearing recognize the condition encoded in the PathTear and end up tearing
down the LSP. down the LSP.
* Assume node B does set the RI-RSVP capability in its Node-ID-based * Assume node B does set the RI-RSVP capability in its Node-ID-based
Hello messages even though it does not support RI-RSVP-FRR Hello messages even though it does not support RI-RSVP-FRR
extensions. In addition, assume local repair is about to commence extensions. In addition, assume local repair is about to commence
on node B for an LSP that has only requested link protection, that on node B for an LSP that has only requested link protection, that
is, B has not initiated the backup LSP signaling for the LSP. If is, B has not initiated the backup LSP signaling for the LSP. If
node B receives a normal PathTear at this time from ingress A node B receives a normal PathTear at this time from ingress A
because of a management event initiated on A, then B simply because of a management event initiated on A, then B simply
deletes the LSP state without sending a Remote PathTear to the LP- deletes the LSP state without sending a Remote PathTear to the LP-
MP C, so C may end up holding on to the stale state until the MP C, so C may end up holding on to the stale state until the
(long) refresh timeout. (long) refresh timeout.
5. Security Considerations 5. Security Considerations
The security considerations pertaining to the original RSVP protocols The security considerations pertaining to the original RSVP protocol
([RFC2205], [RFC3209], and [RFC5920]) remain relevant. When using ([RFC2205], [RFC3209], and [RFC5920]) remain relevant. When using
RSVP cryptographic authentication [RFC2747], more robust algorithms RSVP cryptographic authentication [RFC2747], more robust algorithms
such as HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 [RFC2104] such as HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 [RFC2104]
[FIPS-180-4] SHOULD be used when computing the keyed message digest [FIPS-180-4] SHOULD be used when computing the keyed message digest
where possible. where possible.
This document extends the applicability of Node-ID-based Hello This document extends the applicability of Node-ID-based Hello
sessions between immediate neighbors. The Node-ID-based Hello sessions between immediate neighbors. The Node-ID-based Hello
session between the PLR and the NP-MP may require the two routers to session between the PLR and the NP-MP may require the two routers to
exchange Hello messages with a non-immediate neighbor. Therefore, exchange Hello messages with a non-immediate neighbor. Therefore,
the implementations SHOULD provide the option to configure a Node-ID the implementations SHOULD provide the option to configure either a
neighbor specific or global authentication key to authentication specific neighbor or global Node-ID authentication key to
messages received from Node-ID neighbors. The network administrator authentication messages received from Node-ID neighbors. The network
SHOULD utilize this option to enable RSVP-TE routers to authenticate administrator SHOULD utilize this option to enable RSVP-TE routers to
Node-ID Hello messages received with a TTL greater than 1. authenticate Node-ID Hello messages received with a TTL greater than
Implementations SHOULD also provide the option to specify a limit on 1. Implementations SHOULD also provide the option to specify a limit
the number of Node-ID-based Hello sessions that can be established on on the number of Node-ID-based Hello sessions that can be established
a router supporting the extensions defined in this document. on a router supporting the extensions defined in this document.
6. IANA Considerations 6. IANA Considerations
6.1. CONDITIONS Object 6.1. CONDITIONS Object
IANA maintains the "Class Names, Class Numbers, and Class Types" IANA maintains the "Class Names, Class Numbers, and Class Types"
registry in the "RSVP Parameters" registry group (see registry in the "RSVP Parameters" registry group (see
http://www.iana.org/assignments/rsvp-parameters/). IANA has extended <http://www.iana.org/assignments/rsvp-parameters/>). IANA has
these registries by adding a new Class Number (in the 10bbbbbb range) extended these registries by adding a new Class Number (in the
and assigning a new C-Type under this Class Number, as described 10bbbbbb range) and assigning a new C-Type under this Class Number,
below (see Section 4.4.3): as described below (see Section 4.4.3). New Class Type values for
Class Name "CONDITIONS" can be added via "IETF Review" [RFC8126].
+==============+============+===========+ +==============+============+===========+
| Class Number | Class Name | Reference | | Class Number | Class Name | Reference |
+==============+============+===========+ +==============+============+===========+
| 135 | CONDITIONS | RFC 9705 | | 135 | CONDITIONS | RFC 9705 |
+--------------+------------+-----------+ +--------------+------------+-----------+
Table 1: Class Names, Class Numbers, Table 1: Class Names, Class Numbers,
and Class Types and Class Types
+=======+=============+===========+ +=======+=============+===========+
| Value | Description | Reference | | Value | Description | Reference |
+=======+=============+===========+ +=======+=============+===========+
| 1 | CONDITIONS | RFC 9705 | | 1 | CONDITIONS | RFC 9705 |
+-------+-------------+-----------+ +-------+-------------+-----------+
Table 2: Class Type or C-Types Table 2: Class Types or C-Types
- 135 CONDITIONS - 135 CONDITIONS
IANA has added a subregistry called "CONDITIONS Object Flags" as IANA has added a subregistry called "CONDITIONS Object Flags" as
shown below. Assignments of additional Class Type values for Class shown below. New registrations can be added via "IETF Review"
Name "CONDITIONS" are to be performed via "IETF Review" [RFC8126]. [RFC8126].
+============+==============+=============+===========+ +============+==============+=============+===========+
| Bit Number | 32-Bit Value | Name | Reference | | Bit Number | 32-Bit Value | Name | Reference |
+============+==============+=============+===========+ +============+==============+=============+===========+
| 0-30 | | Unassigned | | | 0-30 | | Unassigned | |
+------------+--------------+-------------+-----------+ +------------+--------------+-------------+-----------+
| 31 | 0x0001 | Merge-point | RFC 9705 | | 31 | 0x0001 | Merge-point | RFC 9705 |
+------------+--------------+-------------+-----------+ +------------+--------------+-------------+-----------+
Table 3: CONDITIONS Object Flags Table 3: CONDITIONS Object Flags
skipping to change at line 1256 skipping to change at line 1265
We are very grateful to Yakov Rekhter for his contributions to the We are very grateful to Yakov Rekhter for his contributions to the
development of the idea and thorough review of the content of the development of the idea and thorough review of the content of the
document. We are thankful to Raveendra Torvi and Yimin Shen for document. We are thankful to Raveendra Torvi and Yimin Shen for
their comments and inputs on early versions of the document. We also their comments and inputs on early versions of the document. We also
thank Alexander Okonnikov for his review and comments on the thank Alexander Okonnikov for his review and comments on the
document. document.
Contributors Contributors
Ina Minei
Google, Inc.
Email: inaminei@google.com
Markus Jork Markus Jork
Juniper Networks, Inc. Juniper Networks, Inc.
Email: mjork@juniper.net Email: mjork@juniper.net
Harish Sitaraman Harish Sitaraman
Individual Contributor Individual Contributor
Email: harish.ietf@gmail.com Email: harish.ietf@gmail.com
Vishnu Pavan Beeram Vishnu Pavan Beeram
Juniper Networks, Inc. Juniper Networks, Inc.
skipping to change at line 1286 skipping to change at line 1299
Authors' Addresses Authors' Addresses
Chandra Ramachandran Chandra Ramachandran
Juniper Networks, Inc. Juniper Networks, Inc.
Email: csekar@juniper.net Email: csekar@juniper.net
Tarek Saad Tarek Saad
Cisco Systems, Inc. Cisco Systems, Inc.
Email: tsaad@cisco.com Email: tsaad@cisco.com
Ina Minei
Google, Inc.
Email: inaminei@google.com
Dante Pacella Dante Pacella
Verizon, Inc. Verizon, Inc.
Email: dante.j.pacella@verizon.com Email: dante.j.pacella@verizon.com
 End of changes. 109 change blocks. 
224 lines changed or deleted 233 lines changed or added

This html diff was produced by rfcdiff 1.48.