draft-ietf-mpls-summary-frr-rsvpte-00.txt   draft-ietf-mpls-summary-frr-rsvpte-01.txt 
MPLS Working Group M. Taillon MPLS Working Group M. Taillon
Internet-Draft T. Saad, Ed. Internet-Draft T. Saad, Ed.
Intended status: Standards Track R. Gandhi Intended status: Standards Track R. Gandhi
Expires: March 19, 2018 Cisco Systems, Inc. Expires: November 1, 2018 Cisco Systems, Inc.
A. Deshmukh A. Deshmukh
M. Jork M. Jork
V. Beeram V. Beeram
Juniper Networks Juniper Networks
September 15, 2017 April 30, 2018
RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels
draft-ietf-mpls-summary-frr-rsvpte-00 draft-ietf-mpls-summary-frr-rsvpte-01
Abstract Abstract
This document defines Resource Reservation Protocol (RSVP) Traffic- This document defines Resource Reservation Protocol (RSVP) Traffic-
Engineering (TE) signaling extensions that reduce the amount of RSVP Engineering (TE) signaling extensions that reduce the amount of RSVP
signaling required for Fast Reroute (FRR) procedures and subsequently signaling required for Fast Reroute (FRR) procedures and subsequently
improve the scalability of the RSVP-TE signaling when undergoing FRR improve the scalability of the RSVP-TE signaling when undergoing FRR
convergence after a link or node failure. Such extensions allow the convergence after a link or node failure. Such extensions allow the
RSVP message exchange between the Point of Local Repair (PLR) and the RSVP message exchange between the Point of Local Repair (PLR) and the
Merge Point (MP) to be independent of the number of protected Label Merge Point (MP) to be independent of the number of protected Label
skipping to change at page 1, line 37 skipping to change at page 1, line 37
compatible with nodes that do not support them. compatible with nodes that do not support them.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 2017. This Internet-Draft will expire on November 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://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 Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . 3 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Summary FRR Signaling Procedures . . . . . . . . . . . . . . 3 3. Extensions for Summary FRR Signaling . . . . . . . . . . . . 4
3.1. Signaling Procedures Prior to Failure . . . . . . . . . . 4 3.1. B-SFRR-Ready Extended ASSOCIATION Object . . . . . . . . 5
3.1.1. Extended ASSOCIATION Object . . . . . . . . . . . . . 5 3.1.1. IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID . . . 5
3.1.2. PLR Summary FRR Signaling Procedure . . . . . . . . . 9 3.1.2. IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID . . . 6
3.1.3. MP Summary FRR Signaling Procedure . . . . . . . . . 9 3.2. B-SFRR-Active Extended ASSOCIATION Object . . . . . . . . 9
3.2. Signaling Procedures Post Failure . . . . . . . . . . . . 10 3.2.1. B-SFRR-Active Extended ASSOCIATION ID . . . . . . . . 10
3.2.1. SUMMARY_FRR_BYPASS Object . . . . . . . . . . . . . . 10 3.3. Signaling Procedures Prior to Failure . . . . . . . . . . 11
3.2.2. PLR Summary FRR Signaling Procedure . . . . . . . . . 12 3.3.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 11
3.2.3. MP Summary FRR Signaling Procedure . . . . . . . . . 12 3.3.2. MP Signaling Procedure . . . . . . . . . . . . . . . 11
3.3. Refreshing Summary FRR Active LSPs . . . . . . . . . . . 13 3.4. Signaling Procedures Post Failure . . . . . . . . . . . . 12
4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 3.4.2. MP Signaling Procedure . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 3.5. Refreshing Summary FRR Active LSPs . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Normative References . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The Fast Reroute (FRR) procedures defined in [RFC4090] describe the The Fast Reroute (FRR) procedures defined in [RFC4090] describe the
mechanisms for the Point of Local Repair (PLR) to reroute traffic and mechanisms for the Point of Local Repair (PLR) to reroute traffic and
signaling of a protected RSVP-TE LSP onto the bypass tunnel in the signaling of a protected RSVP-TE LSP onto the bypass tunnel in the
event of a TE link or node failure. Such signaling procedures are event of a TE link or node failure. Such signaling procedures are
performed individually for each affected protected LSP. This may performed individually for each affected protected LSP. This may
eventually lead to control plane scalability and latency issues under eventually lead to control plane scalability and latency issues on
limited (memory and CPU processing) resources after a failure that the PLR and/or the MP due to limited memory and CPU processing
affects a large number of protected LSPs traversing the same PLR and resources. This condition is exacerbated when the failure affects
Merge Point (MP) nodes. large number of protected LSPs that traverse the same PLR and Merge
Point (MP) nodes.
For example, in a large RSVP-TE LSPs scale deployment, a single LSR For example, in a large scale RSVP-TE LSPs deployment, a single LSR
acting as a PLR node may host tens of thousands of protected RSVP-TE acting as a PLR node may host tens of thousands of protected RSVP-TE
LSPs egressing the same link, and also act as a MP node for similar LSPs egressing the same link, and also act as a MP node for similar
number of LSPs ingressing the same link. In the event of the failure number of LSPs ingressing the same link. In the event of the failure
of the link or neighbor node, the RSVP-TE control plane of the node of the link or neighbor node, the RSVP-TE control plane of the node
when acting as PLR becomes busy rerouting protected LSPs signaling when acting as PLR becomes busy rerouting protected LSPs signaling
over the bypass tunnel(s) in one direction, and when acting as an MP over the bypass tunnel(s) in one direction, and when acting as an MP
node becomes busy merging RSVP states from signaling received over node becomes busy merging RSVP states from signaling received over
bypass tunnels for LSP(s) in the reverse direction. Subsequently, bypass tunnels for LSP(s) in the reverse direction. Subsequently,
the head-end LER(s) that are notified of the local repair at the head-end LER(s) that are notified of the local repair at
downstream LSR will attempt to (re)converge affected RSVP- TE LSPs downstream LSR will attempt to (re)converge affected RSVP- TE LSPs
onto newly computed paths - possibly traversing the same previously onto newly computed paths - possibly traversing the same previously
affected LSR(s). As a result, the RSVP-TE control plane at the PLR affected LSR(s). As a result, the RSVP-TE control plane at the PLR
and MP becomes overwhelmed by the amount of FRR RSVP-TE processing and MP becomes overwhelmed by the amount of FRR RSVP-TE processing
overhead following the link or node failure, and the competing other overhead following the link or node failure, and the competing other
control plane protocol(s) (e.g. the IGP) that undergo their control plane protocol(s) (e.g. the IGP) that undergo their
convergence at the same time. convergence at the same time.
The extensions defined in this document enable a MP node to become The extensions defined in this document enable a MP node to become
aware of the PLR node's bypass tunnel assignment group and allow FRR aware of the PLR node's bypass tunnel assignment group and allow FRR
procedures between PLR node and MP node to be signaled and processed procedures between PLR node and MP node to be signaled and processed
on groups of LSPs. Further, the MESSAGE_ID for the rerouted PATH and on groups of LSPs.
RESV states are exchanged a priori to the fault such that Summary As defined in [RFC2961], Summary Refresh procedures use MESSAGE_ID to
Refresh procedures defined in [RFC2961] can continue to be used to refresh the RSVP Path and Resv states to help with the scale. The
refresh the rerouted state(s) after FRR has occurred. MESSAGE_ID information for the rerouted PATH and RESV states are
exchanged between PLR and MP nodes between PLR and MP nodes a priori
to the fault such that Summary Refresh procedures defined in
[RFC2961] can continue to be used to refresh the rerouted state(s)
after FRR has occurred.
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Key Word Definitions 2.1. Key Word Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
2.2. Terminology 2.2. Terminology
The reader is assumed to be familiar with the terminology in The reader is assumed to be familiar with the terminology in
skipping to change at page 3, line 47 skipping to change at page 4, line 16
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
2.2. Terminology 2.2. Terminology
The reader is assumed to be familiar with the terminology in The reader is assumed to be familiar with the terminology in
[RFC3209] and [RFC4090]. [RFC3209] and [RFC4090].
3. Summary FRR Signaling Procedures 3. Extensions for Summary FRR Signaling
The RSVP ASSOCIATION object is defined in [RFC4872] as a means to The RSVP ASSOCIATION object is defined in [RFC4872] as a means to
associate LSPs with each other. For example, in the context of associate LSPs with each other. For example, in the context of
GMPLS-controlled LSP(s), the object is used to associate recovery GMPLS-controlled LSP(s), the object is used to associate recovery
LSPs with the LSP they are protecting. The Extended ASSOCIATION LSPs with the LSP they are protecting. The Extended ASSOCIATION
object is introduced in [RFC6780] to expand on the possible usage of object is introduced in [RFC6780] to expand on the possible usage of
the ASSOCIATION object and generalize the definition of the the ASSOCIATION object and generalize the definition of the Extended
Association ID field. Association ID field.
This document proposes the use of the Extended ASSOCIATION object to This document proposes the use of the Extended ASSOCIATION object to
carry the Summary FRR information and associate the protected LSP(s) carry the Summary FRR information and associate the protected LSP(s)
with the bypass tunnel that protects them. To this extent, a new with the bypass tunnel that protects them. Two new Association Types
Association Type for the Extended ASSOCIATION object, and a new for the Extended ASSOCIATION object, and new Extended Association IDs
Association ID are proposed in this draft to describe the Bypass are proposed in this draft to describe the Bypass Summary FRR Ready
Summary FRR (B-SFRR) association. (B-SFRR-Ready) and the Bypass Summary FRR Active (B-SFRR-Active)
associations.
The PLR creates and manages the Summary FRR LSP groups The PLR creates and manages the Summary FRR LSP groups
(Bypass_Group_Identifiers) and shares them with the MP via signaling. (Bypass_Group_Identifiers) and shares them with the MP via signaling.
Protected LSPs sharing the same egress link and bypass assignment are Protected LSPs sharing the same egress link and bypass assignment are
grouped together and are assigned the same group. The MP maintains grouped together and are assigned the same group. The MP maintains
the PLR group assignments learned via signaling, and acknowledges the the PLR group assignments learned via signaling, and acknowledges the
group assignments via signaling. Once the PLR receives the group assignments via signaling. Once the PLR receives the
acknowledgment, FRR signaling can proceed as group based. acknowledgment, FRR signaling can proceed as group based.
The PLR node that supports Summary FRR procedures adds the Extended The PLR node that supports Summary FRR procedures adds the Extended
ASSOCIATION object with Bypass Summary FRR Association Type - ASSOCIATION object with Type B-SFRR-Ready and respective Extended
referred to thereon in this document as B-SFRR Extended ASSOCIATION Association ID in the RSVP Path message of the protected LSP to
object- in the RSVP Path message of the protected LSP to inform the inform the MP of the PLR's assigned bypass tunnel, Summary FRR
MP of the PLR's assigned bypass tunnel, Summary FRR Bypass_Group_Identifier, and the MESSAGE_ID that the PLR will use to
Bypass_Group_Identifier, and the MESSAGE_ID object that the PLR will refresh the protected LSP PATH state after FRR occurs.
use to refresh the protected LSP PATH state after FRR occurs.
The MP node that supports Summary FRR procedures adds the B-SFRR
Extended ASSOCIATION object in a RSVP Resv message of the protected
LSP to acknowledge the PLR's bypass tunnel assignment, and provide
the MESSAGE_ID object that the MP node will use to refresh the
protected LSP RESV state after FRR occurs.
This document also defines a new RSVP FRR_ACTIVE SUMMARY_FRR_BYPASS
object that is sent within the RSVP Path message of a bypass LSP to
inform the MP node that one or more groups of protected LSPs that are
being protected by the bypass tunnel are being rerouted i.e.
signaling is rerouted over the bypass tunnel.
3.1. Signaling Procedures Prior to Failure The MP node that supports Summary FRR procedures adds the B-SFRR-
Ready Extended ASSOCIATION object and respective Extended Association
ID in the RSVP Resv message of the protected LSP to acknowledge the
PLR's bypass tunnel assignment, and provide the MESSAGE_ID object
that the MP node will use to refresh the protected LSP RESV state
after FRR occurs.
Before Summary FRR procedures can be used, a handshake MUST be This document also defines a new Association Type for the Extended
completed between the PLR and MP. This handshake is performed using ASSOCIATION object and new Extended Association ID to describe the B-
B-SFRR Extended ASSOCIATION object that is carried in both the RSVP SFRR-Active association. The B-SFRR-Active Extended ASSOCIATION
Path and Resv messages of the protected LSP. object and Extended Association ID are sent by PLR after activating
FRR procedures on the PLR. The B-SFRR-Active Extended ASSOCIATION
object and Extended Association ID are sent within the RSVP Path
message of the bypass LSP to inform the MP node that one or more
groups of protected LSPs protected by the bypass tunnel are now being
rerouted over the bypass tunnel.
3.1.1. Extended ASSOCIATION Object 3.1. B-SFRR-Ready Extended ASSOCIATION Object
The B-SFRR Extended ASSOCIATION object is populated using the rules The Extended ASSOCIATION object is populated using the rules defined
defined below to associate the Summary FRR enabled protected LSP with below to associate a protected LSP with the bypass LSP that is
the bypass LSP that is protecting it. protecting it when Summary FRR procedures are enabled.
The Association Type, Association ID, and Association Source MUST be The Association Type, Association ID, and Association Source MUST be
set as defined in [RFC4872] for the ASSOCIATION Object. More set as defined in [RFC4872] for the ASSOCIATION Object. More
specifically: specifically:
Association Source: Association Source:
The Association Source is set to an address selected by the node The Association Source is set to an address of the PLR node.
that originates the association. For Bypass Summary FRR association
it is set to an address of the PLR node.
Association Type: Association Type:
The Association Type is set to indicate the Bypass Summary FRR A new Association Type is defined for B-SFRR-Ready as follows:
association. A new Association Type is defined as follows:
Value Type Value Type
------- ------ ------- ------
(TBD-1) Bypass Summary FRR Association (B-SFRR) (TBD-1) Bypass Summary FRR Ready Association (B-SFRR-Ready)
Extended Association ID: Extended ASSOCIATION ID for B-SFRR-Ready:
The Extended Association ID is populated by the node originating the The B-SFRR-Ready Extended ASSOCIATION ID is
association -- i.e. the PLR for the Bypass Summary FRR association. populated by the PLR for the Bypass Summary FRR Ready association.
The rules to populate the Extended Association ID in this case is The rules to populate the Extended ASSOCIATION ID in this case are
described below. described below.
3.1.1.1. IPv4 Extended Association ID 3.1.1. IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID
The IPv4 Extended Association ID for Summary FRR bypass assignment The IPv4 Extended ASSOCIATION ID for the B-SFRR-Ready association
has the following format: type has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Tunnel_ID | Reserved | | Bypass_Tunnel_ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Source_IPv4_Address | | Bypass_Source_IPv4_Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Destination_IPv4_Address | | Bypass_Destination_IPv4_Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Group_Identifier | | Bypass_Group_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MESSAGE_ID | | MESSAGE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The IPv4 Extended Association ID field Figure 1: The IPv4 Extended ASSOCIATION ID for B-SFRR-Ready
Bypass_Tunnel_ID: 16 bits Bypass_Tunnel_ID: 16 bits
The bypass tunnel identifier. The bypass tunnel identifier.
Reserved: 16 bits Reserved: 16 bits
Reserved for future use. Reserved for future use.
Bypass_Source_IPv4_Address: 32 bits Bypass_Source_IPv4_Address: 32 bits
skipping to change at page 6, line 45 skipping to change at page 6, line 45
The bypass tunnel destination IPV4 address. The bypass tunnel destination IPV4 address.
Bypass_Group_Identifier: 32 bits Bypass_Group_Identifier: 32 bits
The bypass tunnel group identifier. The bypass tunnel group identifier.
MESSAGE_ID MESSAGE_ID
A MESSAGE_ID object as defined by [RFC2961]. A MESSAGE_ID object as defined by [RFC2961].
3.1.1.2. IPv6 Extended Association ID 3.1.2. IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID
The IPv6 Extended Association ID field for the Summary FRR The IPv6 Extended ASSOCIATION ID field for the B-SFRR-Ready
information has the following format: association type has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Tunnel_ID | Reserved | | Bypass_Tunnel_ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Bypass_Source_IPv6_Address + + Bypass_Source_IPv6_Address +
skipping to change at page 7, line 31 skipping to change at page 7, line 31
+ Bypass_Destination_IPv6_Address + + Bypass_Destination_IPv6_Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Group_Identifier | | Bypass_Group_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MESSAGE_ID | | MESSAGE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The IPv6 Extended Association ID field Figure 2: The IPv6 Extended ASSOCIATION ID for B-SFRR-Ready
Bypass_Tunnel_ID: 16 bits Bypass_Tunnel_ID: 16 bits
The bypass tunnel identifier. The bypass tunnel identifier.
Reserved: 16 bits Reserved: 16 bits
Reserved for future use. Reserved for future use.
Bypass_Source_IPv6_Address: 128 bits Bypass_Source_IPv6_Address: 128 bits
skipping to change at page 8, line 37 skipping to change at page 8, line 37
A MESSAGE_ID object as defined by [RFC2961]. A MESSAGE_ID object as defined by [RFC2961].
The PLR assigns a bypass tunnel and Bypass_Group_Identifier for each The PLR assigns a bypass tunnel and Bypass_Group_Identifier for each
protected LSP. The same Bypass_Group_Identifier is used for the set protected LSP. The same Bypass_Group_Identifier is used for the set
of protected LSPs that share the same bypass tunnel and traverse the of protected LSPs that share the same bypass tunnel and traverse the
same egress link and are not already rerouted. The PLR also same egress link and are not already rerouted. The PLR also
generates a MESSAGE_ID object (flags SHOULD be clear, Epoch and generates a MESSAGE_ID object (flags SHOULD be clear, Epoch and
Message_Identifier MUST be set according to [RFC2961]). Message_Identifier MUST be set according to [RFC2961]).
The PLR MUST generate a new Message_Identifier each time the contents The PLR MUST generate a new Message_Identifier each time the contents
of the B-SFRR Extended ASSOCIATION object change; for example, when of the B-SFRR-Ready Extended ASSOCIATION ID changes; for example,
PLR node changes the bypass tunnel assignment. when PLR node changes the bypass tunnel assignment.
The PLR node notifies the MP node of the bypass tunnel assignment via The PLR node notifies the MP node of the bypass tunnel assignment via
adding a B-SFRR Extended ASSOCIATION object in the RSVP Path message adding a B-SFRR-Ready Extended ASSOCIATION object and Association ID
for the protected LSP using procedures described in Section 3.2. in the RSVP Path message for the protected LSP using procedures
described in Section 3.4.
The MP node acknowledges the PLR node assignment by signaling the The MP node acknowledges the PLR node assignment by signaling the B-
B-SFRR Extended Association object within the RSVP Resv message of SFRR-Ready Extended ASSOCIATION object and Association ID within the
the protected LSP. With exception of the MESSAGE_ID objects, all RSVP Resv message of the protected LSP. With exception of the
other fields of the received B-SFRR Extended ASSOCIATION object in MESSAGE_ID objects, all other fields of the received in the B-SFRR-
the RSVP Path message are copied into the B-SFRR Extended ASSOCIATION Ready Extended ASSOCIATION ID in the RSVP Path message are copied
object to be added in the Resv message. The MESSAGE_ID object is set into the B-SFRR-Ready Extended ASSOCIATION ID to be added in the Resv
according to [RFC2961] with the Flags being clear. A new message. The MESSAGE_ID object is set according to [RFC2961] with
Message_Identifier MUST be used to acknowledge an updated PLR the Flags being clear. A new Message_Identifier MUST be used to
assignment. acknowledge an updated PLR assignment.
The PLR considers the protected LSP as Summary FRR capable only if The PLR considers the protected LSP as Summary FRR capable only if
the B-SFRR Extended ASSOCIATION objects sent in the RSVP Path message all the fields in the B-SFRR-Ready Extended ASSOCIATION ID that are
and the one received in the RSVP Resv message (with exception of the sent in the RSVP Path message and the ones received in the RSVP Resv
MESSAGE_ID) match. If it does not match, or if B-SFRR Extended message (with exception of the MESSAGE_ID) match. If it does not
Association object is absent in a subsequent refresh, the PLR node match, or if B-SFRR-Ready Extended ASSOCIATION object is absent in a
MUST consider the protected LSP as not Summary FRR capable. subsequent refresh, the PLR node MUST consider the protected LSP as
not Summary FRR capable.
3.1.2. PLR Summary FRR Signaling Procedure
The B-SFRR Extended ASSOCIATION object is added by each PLR in the
RSVP Path message of the protected LSP to record the bypass tunnel
assignment. This object is updated every time the PLR updates the
bypass tunnel assignment (which triggers an RSVP Path change
message).
Upon receiving an RSVP Resv message with B-SFRR Extended ASSOCIATION
object, the PLR node checks if the expected subobjects in the B-SFRR
Extended ASSOCIATION ID are present. If present, the PLR determines
if the MP has acknowledged the current PLR assignment.
To be a valid acknowledgement, the received B-SFRR Extended
ASSOCIATION object contents within the RSVP Resv message of the
protected LSP MUST match the latest B-SFRR Extended ASSOCIATION
object contents that the PLR node had sent within the RSVP Path
message (with exception of the MESSAGE_ID).
Note, when forwarding an RSVP Resv message upstream, the PLR node
SHOULD remove any/all B-SFRR Extended ASSOCIATION objects whose
Association Source matches the PLR node address.
3.1.3. MP Summary FRR Signaling Procedure 3.2. B-SFRR-Active Extended ASSOCIATION Object
Upon receiving an RSVP Path message with an B-SFRR Extended The Extended ASSOCIATION object for B-SFRR-Active association type is
ASSOCIATION object, the MP node processes all (there may be multiple populated by a PLR node to indicate to the MP node (bypass tunnel
PLRs for a single MP) B-SFRR Extended ASSOCIATION objects that have destination) that one or more groups of protected LSPs that are being
the MP node address as Bypass Destination address in the Association protected by the specified bypass tunnel are being rerouted over the
ID. bypass tunnel.
The MP node first ensures the existence of the bypass tunnel and that The B-SFRR-Active Extended ASSOCIATION object is carried in the RSVP
the Bypass_Group_Identifier is not already FRR active. That is, an Path message of a bypass LSP and signaled downstream towards the MP
LSP cannot join a group that is already FRR rerouted. (bypass LSP destination).
The MP node builds a mirrored Summary FRR Group database per PLR, The Association Type, Association ID, and Association Source MUST be
which is determined using the Bypass_Source_Address field. The set as defined in [RFC4872] for the ASSOCIATION Object. More
MESSAGE_ID is extracted and recorded for the protected LSP PATH specifically:
state. The MP node signals a B-SFRR Extended Association object
within the RSVP Resv message of the protected LSP. With exception of
the MESSAGE_ID objects, all other fields of the received B-SFRR
Extended ASSOCIATION object in the RSVP Path message are copied into
the B-SFRR Extended ASSOCIATION object to be added in the Resv
message. The MESSAGE_ID object is set according to [RFC2961] with
the Flags being clear.
Note, an MP may receive more than one RSVP Path message with the Association Source:
B-SFRR Extended ASSOCIATION object from different upstream PLR
node(s). In this case, the MP node is expected to save all the
received MESSAGE_IDs from the different upstream PLR node(s). After
a failure, the MP node determines and activates the associated
Summary Refresh ID to use once it receives and processes the RSVP
Path message with FRR_ACTIVE SUMMARY_FRR_BYPASS object over the
bypass LSP from the PLR.
When forwarding an RSVP Path message downstream, the MP SHOULD remove The Association Source is set to an address of the PLR node.
any/all B-SFRR Extended ASSOCIATION object(s) whose Association ID
contains Bypass_Destination_Address matching the MP node address.
3.2. Signaling Procedures Post Failure Association Type:
Upon detection of the fault (egress link or node failure) the PLR A new Association Type is defined for B-SFRR-Active as follows:
first performs the object modification procedures described by
Section 6.4.3 of [RFC4090] for all affected protected LSPs. For
Summary FRR LSPs assigned to the same bypass tunnel a common RSVP_HOP
and SENDER_TEMPLATE MUST be used.
The PLR MUST signal non-Summary FRR enabled LSPs over the bypass Value Type
tunnel before signaling the Summary FRR enabled LSPs. This is needed ------- ------
to allow for the case when the PLR node has recently changed a bypass (TBD-2) Bypass Summary FRR Active Association (B-SFRR-Active)
assignment and the MP has not processed the change yet.
A new object FRR_ACTIVE SUMMARY_FRR_BYPASS is defined in Extended ASSOCIATION ID for B-SFRR-Active:
Section 3.2.1 and sent within the RSVP Path message of the bypass LSP
to reroute RSVP state of Summary FRR enabled LSPs.
3.2.1. SUMMARY_FRR_BYPASS Object The B-SFRR-Active Extended ASSOCIATION ID is
populated by the PLR for the Bypass Summary FRR Active association.
The rules to populate the Extended ASSOCIATION ID in this case are
described below.
The SUMMARY_FRR_BYPASS Object with Type FRR_ACTIVE is carried in the 3.2.1. B-SFRR-Active Extended ASSOCIATION ID
Path message of a bypass LSP. This object is added by the PLR node
to indicate to the MP node (bypass tunnel destination) that one or
more groups of protected LSPs that are being protected by the
specified bypass tunnel are being rerouted over the bypass tunnel.
The FRR_ACTIVE SUMMARY_FRR_BYPASS object is assigned the C-Type (TBD- The Extended ASSOCIATION ID for the B-SFRR-Active association type
3). The FRR_ACTIVE SUMMARY_FRR_BYPASS object has the below format. has the following format:
SUMMARY_FRR_BYPASS Class-Num = (TBD-2) (of the form 11bbbbbb) Class-
Name = SUMMARY_FRR_BYPASS Class, FRR_ACTIVE C-Type = (TBD-3)
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-N(TBD-2)| C-Type (TBD-3)| | Num-BGIDs | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num-BGIDs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Group_Identifier | | Bypass_Group_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | | : |
// : // // : //
| : | | : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Group_Identifier | | Bypass_Group_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RSVP_HOP_Object | | RSVP_HOP_Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TIME_VALUES | | TIME_VALUES |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Summary FRR Bypass Object Figure 3: The Extended ASSOCIATION ID for B-SFRR-Active
Reserved: 16 bits
Reserved for future use.
Num-BGIDs: 16 bits Num-BGIDs: 16 bits
Number of Bypass_Group_Identifier fields. Number of Bypass_Group_Identifier fields.
Reserved: 16 bits
Reserved for future use.
Bypass_Group_Identifier: 32 bits Bypass_Group_Identifier: 32 bits
The Bypass_Group_Identifier that is previously advertised by the The Bypass_Group_Identifier that is previously signaled by the
PLR using the Extended Association object. One or PLR using the Extended Association object. One or
more Bypass_Group_Identifiers may be included. more Bypass_Group_Identifiers may be included.
RSVP_HOP_Object: Class 3, as defined by [RFC2205] RSVP_HOP_Object: Class 3, as defined by [RFC2205]
Replacement RSVP HOP object to be applied to all LSPs associated Replacement RSVP HOP object to be applied to all LSPs associated
with each of the following Bypass_Group_Identifiers. This corresponds with each of the following Bypass_Group_Identifiers. This corresponds
to C-Type = 1 for IPv4 RSVP HOP, or C-Type = 2 for IPv6 RSVP HOP to C-Type = 1 for IPv4 RSVP HOP, or C-Type = 2 for IPv6 RSVP HOP
depending on the IP address family carried within the object. depending on the IP address family carried within the object.
skipping to change at page 11, line 48 skipping to change at page 11, line 4
more Bypass_Group_Identifiers may be included. more Bypass_Group_Identifiers may be included.
RSVP_HOP_Object: Class 3, as defined by [RFC2205] RSVP_HOP_Object: Class 3, as defined by [RFC2205]
Replacement RSVP HOP object to be applied to all LSPs associated Replacement RSVP HOP object to be applied to all LSPs associated
with each of the following Bypass_Group_Identifiers. This corresponds with each of the following Bypass_Group_Identifiers. This corresponds
to C-Type = 1 for IPv4 RSVP HOP, or C-Type = 2 for IPv6 RSVP HOP to C-Type = 1 for IPv4 RSVP HOP, or C-Type = 2 for IPv6 RSVP HOP
depending on the IP address family carried within the object. depending on the IP address family carried within the object.
TIME_VALUES object: Class 5, as defined by [RFC2205] TIME_VALUES object: Class 5, as defined by [RFC2205]
Replacement TIME_VALUES object to be applied to all LSPs associated Replacement TIME_VALUES object to be applied to all LSPs associated
with each of the following Bypass_Group_Identifiers after receiving with each of the following Bypass_Group_Identifiers after receiving
the FRR_ACTIVE SUMMARY_FRR_BYPASS object. the B-SFRR-Active Extended ASSOCIATION Object.
3.2.2. PLR Summary FRR Signaling Procedure 3.3. Signaling Procedures Prior to Failure
Before Summary FRR procedures can be used, a handshake MUST be
completed between the PLR and MP. This handshake is performed using
Extended ASSOCIATION object that carries the B-SFRR-Ready Extended
Association ID in both the RSVP Path and Resv messages of the
protected LSP.
3.3.1. PLR Signaling Procedure
The B-SFRR-Ready Extended ASSOCIATION object is added by each PLR in
the RSVP Path message of the protected LSP to record the bypass
tunnel assignment. This object is updated every time the PLR updates
the bypass tunnel assignment and that triggers an RSVP Path change
message.
Upon receiving an RSVP Resv message with B-SFRR-Ready Extended
ASSOCIATION object, the PLR node checks if the expected subobjects
from the B-SFRR-Ready ASSOCIATION ID are present. If present, the
PLR determines if the MP has acknowledged the current PLR assignment.
To be a valid acknowledgement, the received B-SFRR-Ready ASSOCIATION
ID contents within the RSVP Resv message of the protected LSP MUST
match the latest B-SFRR-Ready Extended ASSOCIATION object and
Association ID contents that the PLR node had sent within the RSVP
Path message (with exception of the MESSAGE_ID).
Note, when forwarding an RSVP Resv message upstream, the PLR node
SHOULD remove any/all B-SFRR-Ready Extended ASSOCIATION objects whose
Association Source matches the PLR node address.
3.3.2. MP Signaling Procedure
Upon receiving an RSVP Path message with a B-SFRR-Ready Extended
ASSOCIATION object, the MP node processes all (there may be multiple
PLRs for a single MP) B-SFRR-Ready Extended ASSOCIATION objects that
have the MP node address as Bypass Destination address in the
Association ID.
The MP node first ensures the existence of the bypass tunnel and that
the Bypass_Group_Identifier is not already FRR active. That is, an
LSP cannot join a group that is already FRR rerouted.
The MP node builds a mirrored Summary FRR Group database per PLR,
which is determined using the Bypass_Source_Address field. The
MESSAGE_ID is extracted and recorded for the protected LSP PATH
state. The MP node signals a B-SFRR-Ready Extended Association
object and Association ID in the RSVP Resv message of the protected
LSP. With exception of the MESSAGE_ID objects, all other fields of
the received B-SFRR-Ready Extended ASSOCIATION object in the RSVP
Path message are copied into the B-SFRR-Ready Extended ASSOCIATION
object to be added in the Resv message. The MESSAGE_ID object is set
according to [RFC2961] with the Flags being clear.
Note, an MP may receive more than one RSVP Path message with the B-
SFRR-Ready Extended ASSOCIATION object from different upstream PLR
node(s). In this case, the MP node is expected to save all the
received MESSAGE_IDs from the different upstream PLR node(s). After
a failure, the MP node determines and activates the associated
Summary Refresh ID to use once it receives and processes the RSVP
Path message containing B-SFRR-Active Extended ASSOCIATION object
that is signaled over the bypass LSP from the PLR, as described
Section 3.4
When forwarding an RSVP Path message downstream, the MP SHOULD remove
any/all B-SFRR-Ready Extended ASSOCIATION object(s) whose Association
ID contains Bypass_Destination_Address matching the MP node address.
3.4. Signaling Procedures Post Failure
Upon detection of the fault (egress link or node failure) the PLR
first performs the object modification procedures described by
Section 6.4.3 of [RFC4090] for all affected protected LSPs. For
Summary FRR LSPs assigned to the same bypass tunnel a common RSVP_HOP
and SENDER_TEMPLATE MUST be used.
The PLR MUST signal non-Summary FRR enabled LSPs over the bypass
tunnel before signaling the Summary FRR enabled LSPs. This is needed
to allow for the case when the PLR node has recently changed a bypass
assignment and the MP has not processed the change yet.
The B-SFRR-Active Extended ASSOCIATION object is sent within the RSVP
Path message of the bypass LSP to reroute RSVP state of Summary FRR
enabled LSPs.
3.4.1. PLR Signaling Procedure
After a failure event, when using the Summary FRR path signaling After a failure event, when using the Summary FRR path signaling
procedures, an individual RSVP Path message for each Summary FRR LSP procedures, an individual RSVP Path message for each Summary FRR LSP
is not signaled. Instead, to reroute Summary FRR LSPs via the bypass is not signaled. Instead, to reroute Summary FRR LSPs via the bypass
tunnel, the PLR adds the FRR_ACTIVE SUMMARY_FRR_BYPASS object in the tunnel, the PLR adds the B-SFRR-Active Extended Association object in
RSVP Path message of the RSVP session of the bypass tunnel. the RSVP Path message of the RSVP session of the bypass tunnel.
The RSVP_HOP_Object field of the FRR_ACTIVE SUMMARY_FRR_BYPASS object The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION
is set to the common RSVP_HOP that was used by the PLR in Section 3.2 ID is set to the common RSVP_HOP that was used by the PLR in
of this document. Section 3.4 of this document.
The previously received MESSAGE_ID from the MP is activated. As a The previously received MESSAGE_ID from the MP is activated. As a
result, the MP may refresh the protected rerouted RESV state using result, the MP may refresh the protected rerouted RESV state using
Summary Refresh procedures. Summary Refresh procedures.
For each affected Summary FRR group, its Bypass_Group_Identifier is For each affected Summary FRR group, its Bypass_Group_Identifier is
added to the FRR_ACTIVE SUMMARY_FRR_BYPASS object. added to B-SFRR-Active Extended ASSOCIATION ID.
3.2.3. MP Summary FRR Signaling Procedure 3.4.2. MP Signaling Procedure
Upon receiving an RSVP Path message with a FRR_ACTIVE Upon receiving an RSVP Path message with a B-SFRR-Active Extended
SUMMARY_FRR_BYPASS object, the MP performs normal merge point Association object, the MP performs normal merge point processing for
processing for each protected LSP associated with each each protected LSP associated with each Bypass_Group_Identifier, as
Bypass_Group_Identifier, as if it received individual RSVP Path if it received individual RSVP Path messages for the LSP.
messages for the LSP.
For each Summary FRR LSP being merged, the MP first modifies the Path For each Summary FRR LSP being merged, the MP first modifies the Path
state as follows: state as follows:
1. The RSVP_HOP object is copied from the FRR_ACTIVE 1. The RSVP_HOP object is copied from the B-SFRR-Active Extended
SUMMARY_FRR_BYPASS RSVP_HOP_Object field. ASSOCIATION ID.
2. The TIME_VALUES object is copied from the FRR_ACTIVE 2. The TIME_VALUES object is copied from the TIMES_VALUE field in
SUMMARY_FRR_BYPASS TIMES_VALUE field. The TIME_VALUES object the B-SFRR-Active Extended ASSOCIATION ID. The TIME_VALUES
contains the refresh time of the PLR to generate refreshes and object contains the refresh time of the PLR to generate refreshes
that would have exchanged in a Path message sent to the MP after and that would have exchanged in a Path message sent to the MP
the failure when no SFRR procedures are in effect. after the failure when no SFRR procedures are in effect.
3. The SENDER_TEMPLATE object SrcAddress field is copied from the 3. The SENDER_TEMPLATE object SrcAddress field is copied from the
bypass tunnel SENDER_TEMPLATE object. For the case where PLR is bypass tunnel SENDER_TEMPLATE object. For the case where PLR is
also the head-end, and SENDER_TEMPLATE SrcAddress of the also the head-end, and SENDER_TEMPLATE SrcAddress of the
protected LSP and bypass tunnel are the same, the MP MUST use the protected LSP and bypass tunnel are the same, the MP MUST use the
modified HOP Address field instead. modified HOP Address field instead.
4. The ERO object is modified as per Section 6.4.4. of [RFC4090]. 4. The ERO object is modified as per Section 6.4.4. of [RFC4090].
Once the above modifications are completed, the MP then performs Once the above modifications are completed, the MP then performs
the merge processing as per [RFC4090]. the merge processing as per [RFC4090].
skipping to change at page 13, line 16 skipping to change at page 14, line 12
meaning that the PLR may now refresh the protected rerouted PATH meaning that the PLR may now refresh the protected rerouted PATH
state using Summary Refresh procedures. state using Summary Refresh procedures.
A failure during merge processing of any individual rerouted LSP MUST A failure during merge processing of any individual rerouted LSP MUST
result in an RSVP Path Error message. result in an RSVP Path Error message.
An individual RSVP Resv message for each successfully merged Summary An individual RSVP Resv message for each successfully merged Summary
FRR LSP is not signaled. The MP node SHOULD immediately use Summary FRR LSP is not signaled. The MP node SHOULD immediately use Summary
Refresh procedures to refresh the protected LSP RESV state. Refresh procedures to refresh the protected LSP RESV state.
3.3. Refreshing Summary FRR Active LSPs 3.5. Refreshing Summary FRR Active LSPs
Refreshing of Summary FRR active LSPs is performed using Summary Refreshing of Summary FRR active LSPs is performed using Summary
Refresh as defined by [RFC2961]. Refresh as defined by [RFC2961].
4. Compatibility 4. Compatibility
The (Extended) ASSOCIATION object is defined in [RFC4872] with a The (Extended) ASSOCIATION object is defined in [RFC4872] with a
class number in the form 11bbbbbb, which ensures compatibility with class number in the form 11bbbbbb, which ensures compatibility with
non-supporting node(s). Such nodes will ignore the object and non-supporting node(s). Such nodes will ignore the object and
forward it without modification. forward it without modification.
The new FRR_ACTIVE SUMMARY_FRR_BYPASS object is to be defined with a
class number in the form 11bbbbbb, which ensures compatibility with
non-supporting nodes. Per [RFC2205], the nodes not supporting this
extension will ignore the object but forward it, unexamined and
unmodified, in all messages.
5. Security Considerations 5. Security Considerations
This document updates an existing RSVP object, and introduces a new This document updates an existing RSVP object. Thus, in the event of
RSVP object. Thus, in the event of the interception of a signaling the interception of a signaling message, a slightly more information
message, a slightly more information could be deduced about the state could be deduced about the state of the network than was previously
of the network than was previously the case. Existing mechanisms for the case. Existing mechanisms for maintaining the integrity and
maintaining the integrity and authenticity of RSVP protocol messages authenticity of RSVP protocol messages [RFC2747] can be applied.
[RFC2747] can be applied.
6. IANA Considerations 6. IANA Considerations
IANA maintains the "Generalized Multi-Protocol Label Switching IANA maintains the "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Parameters" registry (see (GMPLS) Signaling Parameters" registry (see
http://www.iana.org/assignments/gmpls-sig-parameters ). The http://www.iana.org/assignments/gmpls-sig-parameters [1]). The
"Association Type" subregistry is included in this registry. "Association Type" subregistry is included in this registry.
This registry has been updated by new Association Type for Extended This registry has been updated by new Association Type for Extended
ASSOCIATION Object defined in this document as follows: ASSOCIATION Object defined in this document as follows:
Value Name Reference Value Name Reference
----- ---- --------- ----- ---- ---------
TBD-1 Bypass Summary FRR Association (B-SFRR) Section 2.1.1 TBD-1 B-SFRR-Ready Association Section 3.1
TBD-2 B-SFRR-Active Association Section 3.2
IANA also maintains and assigns the values for the RSVP-TE protocol IANA also maintains and assigns the values for the RSVP-TE protocol
parameters "Resource Reservation Protocol (RSVP) Parameters" (see parameters "Resource Reservation Protocol (RSVP) Parameters" (see
http://www.iana.org/assignments/rsvp-parameters). http://www.iana.org/assignments/rsvp-parameters).
From this registry, a new RSVP Class (TBD-2) and of the form 11bbbbbb
and a new C-Type (TBD-3) are requested for the new FRR_ACTIVE
SUMMARY_FRR_BYPASS object defined in this document.
Class-Number = (TBD-2), Class-Name = SUMMARY_FRR_BYPASS
C-Type = (TBD-3) Name = FRR_ACTIVE
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Loa Andersson, Lou Berger, Eric The authors would like to thank Loa Andersson, Lou Berger, Eric
Osborne, Gregory Mirsky, and Mach Chen for reviewing and providing Osborne, Gregory Mirsky, and Mach Chen for reviewing and providing
valuable comments to this document. valuable comments to this document.
8. Contributors 8. Contributors
Nicholas Tan Nicholas Tan
Arista Networks Arista Networks
Email: ntan@arista.com Email: ntan@arista.com
9. Normative References 9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <http://www.rfc-editor.org/info/rfc2205>. September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, DOI 10.17487/RFC2747, January Authentication", RFC 2747, DOI 10.17487/RFC2747, January
2000, <http://www.rfc-editor.org/info/rfc2747>. 2000, <https://www.rfc-editor.org/info/rfc2747>.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001,
<http://www.rfc-editor.org/info/rfc2961>. <https://www.rfc-editor.org/info/rfc2961>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005, DOI 10.17487/RFC4090, May 2005,
<http://www.rfc-editor.org/info/rfc4090>. <https://www.rfc-editor.org/info/rfc4090>.
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS) Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
<http://www.rfc-editor.org/info/rfc4872>. <https://www.rfc-editor.org/info/rfc4872>.
[RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
ASSOCIATION Object Extensions", RFC 6780, DOI 10.17487/ ASSOCIATION Object Extensions", RFC 6780,
RFC6780, October 2012, DOI 10.17487/RFC6780, October 2012,
<http://www.rfc-editor.org/info/rfc6780>. <https://www.rfc-editor.org/info/rfc6780>.
9.2. URIs
[1] http://www.iana.org/assignments/gmpls-sig-parameters
Authors' Addresses Authors' Addresses
Mike Taillon Mike Taillon
Cisco Systems, Inc. Cisco Systems, Inc.
Email: mtaillon@cisco.com Email: mtaillon@cisco.com
Tarek Saad (editor) Tarek Saad (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 79 change blocks. 
252 lines changed or deleted 282 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/