rfc8796xml2.original.xml   rfc8796.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
docName="draft-ietf-mpls-summary-frr-rsvpte-09" number="8796"
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ category="std" updates="4090" obsoletes="" submissionType="IETF"
]> consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="t
rue" version="3">
<?rfc toc="yes"?> <!-- xml2rfc v2v3 conversion 2.41.0 -->
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-mpls-summary-frr-rsvpte-09" category=
"std" updates="4090">
<front> <front>
<title abbrev="RSVP-TE Summary FRR">RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels</title>
<title abbrev="RSVP-TE Summary FRR">RSVP-TE Summary Fast Reroute
Extensions for Label Switched Path (LSP) Tunnels</title>
<seriesInfo name="RFC" value="8796"/>
<author initials="M." surname="Taillon" fullname="Mike Taillon"> <author initials="M." surname="Taillon" fullname="Mike Taillon">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<email>mtaillon@cisco.com</email> <email>mtaillon@cisco.com</email>
</address> </address>
</author> </author>
<author initials="T." surname="Saad" fullname="Tarek Saad" role="editor"> <author initials="T." surname="Saad" fullname="Tarek Saad" role="editor">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>tsaad@juniper.net</email> <email>tsaad@juniper.net</email>
skipping to change at line 47 skipping to change at line 44
<address> <address>
<email>adeshmukh@juniper.net</email> <email>adeshmukh@juniper.net</email>
</address> </address>
</author> </author>
<author initials="M." surname="Jork" fullname="Markus Jork"> <author initials="M." surname="Jork" fullname="Markus Jork">
<organization>128 Technology</organization> <organization>128 Technology</organization>
<address> <address>
<email>mjork@128technology.com</email> <email>mjork@128technology.com</email>
</address> </address>
</author> </author>
<author initials="V.P." surname="Beeram" fullname="Vishnu Pavan Beeram"> <author initials="V." surname="Beeram" fullname="Vishnu Pavan Beeram">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>vbeeram@juniper.net</email> <email>vbeeram@juniper.net</email>
</address> </address>
</author> </author>
<date year="2020" month="March" day="17"/> <date month="July" year="2020"/>
<workgroup>MPLS Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>This document updates RFC 4090 for the Resource Reservation Protocol (R
<t>This document updates RFC 4090 for the Resource Reservation Protocol (RSVP) SVP)
Traffic-Engineering (TE) procedures defined for facility Traffic Engineering (TE) procedures defined for facility
backup protection. The updates include extensions that reduce the amount of backup protection. The updates include extensions that reduce the amount of
signaling and processing that occurs during Fast Reroute (FRR), and signaling and processing that occurs during Fast Reroute (FRR); as a result,
subsequently, improves scalability when undergoing FRR convergence after a link scalability when undergoing FRR convergence after a link or node failure is
or node failure. These extensions allow the RSVP message exchange between the improved. These extensions allow the RSVP message exchange between the
Point of Local Repair (PLR) and the Merge Point (MP) nodes to be independent of the Point of Local Repair (PLR) and the Merge Point (MP) nodes to be independent of the
number of protected Label Switched Paths (LSPs) traversing between them when number of protected Label Switched Paths (LSPs) traversing between them when
facility bypass FRR protection is used. The signaling extensions are fully facility bypass FRR protection is used. The signaling extensions are fully
backwards compatible with nodes that do not support them.</t> backwards compatible with nodes that do not support them.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<section anchor="introduction" title="Introduction"> <name>Introduction</name>
<t>The Fast Reroute (FRR) procedures defined in <xref target="RFC4090" for
<t>The Fast Reroute (FRR) procedures defined in <xref target="RFC4090"/> describ mat="default"/> describe the
e the
mechanisms for the Point of Local Repair (PLR) to reroute traffic and signaling mechanisms for the Point of Local Repair (PLR) to reroute traffic and signaling
of a protected RSVP-TE Label Switched Path (LSP) onto the bypass tunnel in the of a protected RSVP-TE Label Switched Path (LSP) onto the bypass tunnel in the
event of a TE link or node failure. Such signaling procedures are performed event of a TE link or node failure. Such signaling procedures are performed
individually for each affected protected LSP. This may eventually lead to individually for each affected protected LSP. This may eventually lead to
control plane scalability and latency issues on the PLR and/or the Merge Point control-plane scalability and latency issues on the PLR and/or the Merge Point
(MP) nodes due to limited memory and CPU processing resources. This condition (MP) nodes due to limited memory and CPU processing resources. This condition
is exacerbated when the failure affects a large number of protected LSPs that is exacerbated when the failure affects a large number of protected LSPs that
traverse the same PLR and MP nodes.</t> traverse the same PLR and MP nodes.</t>
<t>For example, in a large-scale deployment of RSVP-TE LSPs, a single Labe
<t>For example, in a large-scale RSVP-TE LSPs deployment, a single Label Switche l
d Switching Router (LSR) acting as a PLR node may host tens of thousands of prote
Router (LSR) acting as a PLR node may host tens of thousands of protected cted
RSVP-TE LSPs egressing the same protected link, and also act as an MP node for RSVP-TE LSPs egressing the same protected link and also act as an MP node for
a similar number of LSPs that ingress on the same link. In the event of the a similar number of LSPs that ingress on the same link. In the event of the
failure of the link or neighbor node, the RSVP-TE control plane of the node failure of the link or neighbor node, the RSVP-TE control plane of the node
(when acting as a PLR node) becomes busy rerouting protected LSPs over the (when acting as a PLR node) becomes busy rerouting protected LSPs over the
bypass tunnel(s) in one direction, and (when acting as an MP node) becomes busy bypass tunnel(s) in one direction and (when acting as an MP node) becomes busy
merging RSVP states from signaling received over bypass tunnels for LSP(s) in merging RSVP states from signaling received over bypass tunnels for one or
more LSPs in
the reverse direction. Subsequently, the head-end Label Edge Routers (LERs) the reverse direction. Subsequently, the head-end Label Edge Routers (LERs)
that are notified of the local repair at downstream LSR will attempt to that are notified of the local repair at any downstream LSRs will attempt to
(re)converge the affected RSVP-TE LSPs onto newly computed paths - possibly (re)converge the affected RSVP-TE LSPs onto newly computed paths -- possibly
traversing the same previously affected LSR(s). As a result, the RSVP-TE traversing the same previously affected LSR(s). As a result, the RSVP-TE
control plane becomes overwhelmed by the amount of FRR RSVP-TE processing control plane becomes overwhelmed (1)&nbsp;by the amount of FRR RSVP-TE processi
overhead following the link or node failure, and due to other control plane ng
protocol(s) (e.g. the IGP) that undergo convergence on the same node at the overhead following the link or node failure and (2)&nbsp;due to other control-pl
same time too.</t> ane
protocols (e.g., IGP) that undergo convergence on the same node at the
<t>Today, each protected RSVP-TE LSP is signaled individually over the bypass same time.</t>
<t>Today, each protected RSVP-TE LSP is signaled individually over the byp
ass
tunnel after FRR. The changes introduced in this document allow the PLR node to tunnel after FRR. The changes introduced in this document allow the PLR node to
assign multiple protected LSPs to a bypass tunnel group and to communicate this assign multiple protected LSPs to a bypass tunnel group and to communicate this
assignment to the MP, such that upon failure, the signaling over the bypass assignment to the MP, such that upon failure, the signaling over the bypass
tunnel happens on bypass tunnel group(s). New extensions are defined in this tunnel happens on one or more bypass tunnel groups. This document defines new
document to update the procedures defined in <xref target="RFC4090"/> for facili extensions that</t>
ty backup
protection to enable the MP node to become aware of the PLR node’s bypass
tunnel assignment group(s) and to allow FRR procedures between the PLR and
the MP nodes to be signaled and processed on per bypass tunnel group(s).</t>
<t>As defined in <xref target="RFC2961"/>, Summary Refresh procedures use MESSAG <ol>
E_ID to <li>update the procedures defined in <xref target="RFC4090" format="default"/> f
or facility backup
protection, to enable the MP node to become aware of the PLR node's bypass
tunnel assignment group or groups.</li>
<li>allow FRR procedures between the PLR and
the MP nodes to be signaled and processed on one or more per-bypass tunnel
groups.</li>
</ol>
<t>As defined in <xref target="RFC2961" format="default"/>, summary refres
h procedures use MESSAGE_ID to
refresh the RSVP Path and Resv states to help with scaling. The Summary FRR refresh the RSVP Path and Resv states to help with scaling. The Summary FRR
procedures introduced in this document build on those concepts to allow the procedures introduced in this document build on those concepts to allow the
MESSAGE_ID(s) to be exchanged on per bypass tunnel assignment group, and continu MESSAGE_ID(s) to be exchanged on one or more per-bypass tunnel assignment groups
e and
use Summary Refresh procedures while reducing the amount of messaging that occur continue to
s use summary refresh procedures while reducing the amount of messaging that occur
after rerouting signaling over the bypass tunnel post FRR.</t> s
after rerouting signaling over the bypass tunnel post-FRR.</t>
</section> </section>
<section anchor="conventions-used-in-this-document" title="Conventions Used in T <section anchor="conventions-used-in-this-document" numbered="true" toc="def
his Document"> ault">
<name>Conventions Used in This Document</name>
<section anchor="terminology" title="Terminology"> <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name>
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
“MAY”, and “OPTIONAL” in this document are to be interpreted as "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>SHOULD NOT</bcp14>",
only when, they "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
</section> <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
<section anchor="acronyms-and-abbreviations" title="Acronyms and Abbreviations"> when, they appear in all capitals, as shown here.</t>
</section>
<t>The reader is assumed to be familiar with terms and abbreviations used in <section anchor="acronyms-and-abbreviations" numbered="true" toc="default"
<xref target="RFC3209"/> and <xref target="RFC4090"/>.</t> >
<name>Acronyms and Abbreviations</name>
<t>The following abbreviations are also used in this document:</t> <t>It is assumed that the reader is familiar with the terms and abbrevia
tions used in
<t><list style='empty'> <xref target="RFC3209" format="default"/> and <xref target="RFC4090" format="def
<t>LSR: Label Switching Router</t> ault"/>.</t>
</list></t> <t>The following abbreviations are also used in this document:</t>
<t><list style='empty'>
<t>LER: Label Edge Router</t>
</list></t>
<t><list style='empty'>
<t>MPLS: Multiprotocol Label Switching</t>
</list></t>
<t><list style='empty'>
<t>LSP: Label Switched Path</t>
</list></t>
<t><list style='empty'>
<t>MP: Merge Point node as defined in <xref target="RFC4090"/></t>
</list></t>
<t><list style='empty'>
<t>PLR: Point of Local Repair node as defined in <xref target="RFC4090"/></t>
</list></t>
<t><list style='empty'>
<t>FRR: Fast Reroute as defined in <xref target="RFC4090"/></t>
</list></t>
<t><list style='empty'>
<t>B-SFRR-Ready: Bypass Summary FRR Ready Extended ASSOCIATION object. Added
by the PLR node for each LSP protected by the bypass tunnel.</t>
</list></t>
<t><list style='empty'> <dl newline="false" spacing="normal">
<t>B-SFRR-Active: Bypass Summary FRR Active Extended ASSOCIATION <dt>LSR:</dt><dd>Label Switching Router</dd>
<dt>LER:</dt><dd>Label Edge Router</dd>
<dt>MPLS:</dt><dd>Multiprotocol Label Switching</dd>
<dt>LSP:</dt><dd>Label Switched Path</dd>
<dt>MP:</dt><dd>Merge Point node as defined in <xref target="RFC4090"
format="default"/></dd>
<dt>PLR:</dt><dd>Point of Local Repair node as defined in <xref target
="RFC4090" format="default"/></dd>
<dt>FRR:</dt><dd>Fast Reroute as defined in <xref target="RFC4090" for
mat="default"/></dd>
<dt>B-SFRR-Ready:</dt><dd>Bypass Summary FRR Ready Extended ASSOCIATIO
N object. Added
by the PLR node for each LSP protected by the bypass tunnel</dd>
<dt>B-SFRR-Active:</dt><dd>Bypass Summary FRR Active Extended ASSOCIAT
ION
object. Used to notify the MP node that one or more groups of object. Used to notify the MP node that one or more groups of
protected LSP(s) have been rerouted over the associated bypass tunnel.</t> protected LSPs have been rerouted over the associated bypass tunnel</dd>
</list></t> <dt>MTU:</dt><dd>Maximum Transmission Unit</dd>
</dl>
<t><list style='empty'> </section>
<t>MTU: Maximum transmission unit.</t> </section>
</list></t> <section anchor="extensions-for-summary-frr-signaling" numbered="true"
toc="default">
</section> <name>Extensions for Summary FRR Signaling</name>
</section> <t>The RSVP ASSOCIATION object is defined in <xref target="RFC4872" format
<section anchor="extensions-for-summary-frr-signaling" title="Extensions for Sum ="default"/> as a means to associate
mary FRR Signaling"> LSPs with each other. For example, in the context of one or more GMPLS-controlle
d LSPs,
<t>The RSVP ASSOCIATION object is defined in <xref target="RFC4872"/> as a means
to associate
LSPs with each other. For example, in the context of GMPLS-controlled LSP(s),
the ASSOCIATION object is used to associate a recovery LSP with the LSP(s) it the ASSOCIATION object is used to associate a recovery LSP with the LSP(s) it
is protecting. The Extended ASSOCIATION object is introduced in <xref target="R FC6780"/> is protecting. The Extended ASSOCIATION object is introduced in <xref target="R FC6780" format="default"/>
to expand on the possible usage of the ASSOCIATION object and generalize the to expand on the possible usage of the ASSOCIATION object and generalize the
definition of the Extended Association ID field.</t> definition of the Extended Association ID field.</t>
<t>This document defines the use of the Extended ASSOCIATION object to car
<t>This document defines the use of the Extended ASSOCIATION object to carry the ry the
Summary FRR information and associate the protected LSP(s) with the bypass Summary FRR information and associate the protected LSP or LSPs with the bypass
tunnel that protects them. Two new Association Types for the Extended tunnel that protects them. Two new Association Types for the Extended
ASSOCIATION object, and new Extended Association IDs are proposed in this ASSOCIATION object, and new Extended Association IDs, are defined in this
document to describe the Bypass Summary FRR Ready (B-SFRR-Ready) and the Bypass document to describe the Bypass Summary FRR Ready (B-SFRR-Ready) and Bypass
Summary FRR Active (B-SFRR-Active) associations.</t> Summary FRR Active (B&nbhy;SFRR-Active) associations.
</t>
<t>The PLR node creates and manages the Summary FRR LSP groups (identified by <t>The PLR node creates and manages the Summary FRR LSP groups (identified
Bypass_Group_Identifiers) and shares the group identifier(s) with the MP via by
Bypass_Group_Identifiers) and shares the group identifiers with the MP via
signaling.</t> signaling.</t>
<t>A PLR node <bcp14>SHOULD</bcp14> assign the same Bypass_Group_Identifie
<t>A PLR node SHOULD assign the same Bypass_Group_Identifier to all r to all
protected LSPs provided that the protected LSPs:</t> protected LSPs provided that the protected LSPs:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>share the same outgoing protected interface,</li>
<t>share the same outgoing protected interface,</t> <li>are protected by the same bypass tunnel, and</li>
<t>are protected by the same bypass tunnel, and</t> <li>are assigned the same tunnel sender address that is used for
<t>are assigned the same tunnel sender address that is used for backup path identification after FRR as described in <xref target="RFC4090" form
backup path identification after FRR as described in <xref target="RFC4090"/>.</ at="default"/>.</li>
t> </ul>
</list></t> <t>This minimizes the number of bypass tunnel Summary FRR groups and optim
izes the
<t>This minimizes the number of bypass tunnel SFRR groups, and optimizes the
amount of signaling that occurs between the PLR and the MP nodes after FRR.</t> amount of signaling that occurs between the PLR and the MP nodes after FRR.</t>
<t>A PLR node that supports Summary FRR procedures adds an Extended ASSOCI
<t>A PLR node that supports Summary FRR procedures adds an Extended ASSOCIATION ATION
object with B-SFRR-Ready Extended Association ID in the RSVP Path message of object with a B-SFRR-Ready Extended Association ID in the RSVP Path message of
the protected LSP. The PLR node adds the protected LSP Bypass_Group_Identifier, the protected LSP. The PLR node adds the protected LSP Bypass_Group_Identifier,
information from the assigned bypass tunnel, and MESSAGE_ID object into the information from the assigned bypass tunnel, and a MESSAGE_ID object into the
B-SFRR-Ready Extended Association ID. The MP uses the information contained in B-SFRR-Ready Extended Association ID. The MP uses the information contained in
the received B-SFRR-Ready Extended Association ID to refresh and merge the the received B-SFRR-Ready Extended Association ID to refresh and merge the
protected LSP Path state after FRR occurs.</t> protected LSP Path state after FRR occurs.</t>
<t>An MP node that supports Summary FRR procedures adds the B-SFRR-Ready E
<t>An MP node that supports Summary FRR procedures adds the B-SFRR-Ready Extende xtended
d
ASSOCIATION object and respective Extended Association ID in the RSVP Resv ASSOCIATION object and respective Extended Association ID in the RSVP Resv
message of the protected LSP to acknowledge the PLR’s bypass tunnel assignment, 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 and provide the MESSAGE_ID object that the MP node will use to refresh the
protected LSP Resv state after FRR occurs.</t> protected LSP Resv state after FRR occurs.</t>
<t>The MP maintains the PLR node group assignments learned from signaling
<t>The MP maintains the PLR node group assignments learned from signaling, and and
acknowledges the group assignments to the PLR node via signaling. Once the PLR acknowledges the group assignments to the PLR node via signaling. Once the PLR
node receives the group assignment acknowledgment from the MP, the FRR node receives the group assignment acknowledgment from the MP, the FRR
signaling can proceed based on Summary FRR procedures as described in this signaling can proceed based on Summary FRR procedures as described in this
document.</t> document.</t>
<t>The B-SFRR-Active Extended ASSOCIATION object with Extended Association
<t>The B-SFRR-Active Extended ASSOCIATION object with Extended Association ID is ID is
sent by the PLR node after activating the Summary FRR procedures. The sent by the PLR node after activating the Summary FRR procedures. The
B-SFRR-Active Extended ASSOCIATION object with Extended Association ID is sent B-SFRR-Active Extended ASSOCIATION object with Extended Association ID is sent
within the RSVP Path message of the bypass tunnel to inform the MP node that within the RSVP Path message of the bypass tunnel to inform the MP node that
one or more groups of protected LSPs protected by the bypass tunnel are now one or more groups of protected LSPs protected by the bypass tunnel are now
being rerouted over the bypass tunnel.</t> being rerouted over the bypass tunnel.</t>
<section anchor="sfrr-bypass-ready" numbered="true" toc="default">
<section anchor="ext-assoc-obj" title="B-SFRR-Ready Extended ASSOCIATION Object" <name>B-SFRR-Ready Extended ASSOCIATION Object</name>
> <t>The Extended ASSOCIATION object is populated using the rules defined
below to
<t>The Extended ASSOCIATION object is populated using the rules defined below to
associate a protected LSP with the bypass tunnel that is protecting it when associate a protected LSP with the bypass tunnel that is protecting it when
Summary FRR procedures are enabled.</t> Summary FRR procedures are enabled.</t>
<t>The Association Type, Association ID, and Association Source <bcp14>M
<t>The Association Type, Association ID, and Association Source MUST be set as UST</bcp14> be set as
defined in <xref target="RFC4872"/> for the ASSOCIATION Object. More specificall defined in <xref target="RFC4872" format="default"/> for the ASSOCIATION
y:</t> object. More specifically:</t>
<dl newline="true" spacing="normal">
<t>Association Source:</t> <dt>Association Source:</dt>
<dd>The Association Source is set to an address of the PLR node.</dd>
<figure><artwork><![CDATA[ <dt>Association Type:</dt>
The Association Source is set to an address of the PLR node. <dd>A new Association Type is defined for B-SFRR-Ready as
]]></artwork></figure> follows:</dd>
</dl>
<t>Association Type:</t> <table anchor="tab-1">
<name>The B-SFRR-Ready Association Type</name>
<figure><artwork><![CDATA[ <thead>
A new Association Type is defined for B-SFRR-Ready as follows: <tr>
<th>Value</th>
Value Type <th>Type</th>
------- ------ </tr>
(TBD-1) Bypass Summary FRR Ready Association (B-SFRR-Ready) </thead>
]]></artwork></figure> <tbody>
<tr>
<t>The Extended ASSOCIATION object’s Global Association Source MUST be set <td>5</td>
according to the rules defined in <xref target="RFC6780"/>.</t> <td>Bypass Summary FRR Ready Association (B-SFRR-Ready)</td>
</tr>
<t>The B-SFRR-Ready Extended ASSOCIATION ID is populated by the PLR node when </tbody>
</table>
<t>The Extended ASSOCIATION object's Global Association Source <bcp14>MU
ST</bcp14> be set
according to the rules defined in <xref target="RFC6780" format="default"/>.</t>
<t>The B-SFRR-Ready Extended Association ID is populated by the PLR node
when
performing Bypass Summary FRR Ready association for a protected LSP. The rules performing Bypass Summary FRR Ready association for a protected LSP. The rules
governing its population are described in the subsequent sections.</t> governing its population are described in the subsequent sections.</t>
<section anchor="ipv4-b-sfrr-ready-extended-association-id" numbered="tr
<section anchor="ipv4-b-sfrr-ready-extended-association-id" title="IPv4 B-SFRR-R ue" toc="default">
eady Extended ASSOCIATION ID"> <name>IPv4 B-SFRR-Ready Extended Association ID</name>
<t>The IPv4 Extended Association ID for the B-SFRR-Ready Association
<t>The IPv4 Extended ASSOCIATION ID for the B-SFRR-Ready association Type is carried inside the IPv4 Extended ASSOCIATION object and has
type is carried inside the IPv4 Extended ASSOCIATION object and has
the following format:</t> the following format:</t>
<figure anchor="fig_IPv4_Extended_Association_ID">
<name>The IPv4 Extended Association ID for B-SFRR-Ready</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Tunnel_ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Source_IPv4_Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Destination_IPv4_Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Group_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MESSAGE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork
> </figure>
<figure title="The IPv4 Extended ASSOCIATION ID for B-SFRR-Ready" anchor="fig_IP <dl newline="false" spacing="normal">
v4_Extended_Association_ID"><artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Tunnel_ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Source_IPv4_Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Destination_IPv4_Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Group_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MESSAGE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<figure><artwork><![CDATA[
Bypass_Tunnel_ID: 16 bits
The bypass tunnel identifier.
Reserved: 16 bits
Reserved for future use. MUST be set to zero when sending
and ignored on receipt.
Bypass_Source_IPv4_Address: 32 bits
The bypass tunnel source IPV4 address.
Bypass_Destination_IPv4_Address: 32 bits
The bypass tunnel destination IPV4 address.
Bypass_Group_Identifier: 32 bits <dt>Bypass_Tunnel_ID:</dt><dd><t>16 bits</t>
<t>The bypass tunnel identifier.</t></dd>
The bypass tunnel group identifier that is assigned to the <dt>Reserved:</dt><dd><t>16 bits</t>
LSP. <t>Reserved for future use. <bcp14>MUST</bcp14> be set to zero when
sending and ignored on receipt.</t></dd>
MESSAGE_ID <dt>Bypass_Source_IPv4_Address:</dt><dd><t>32 bits</t>
<t>The bypass tunnel source IPv4 address.</t></dd>
A MESSAGE_ID object as defined by [RFC2961]. <dt>Bypass_Destination_IPv4_Address:</dt><dd><t>32 bits</t>
]]></artwork></figure> <t>The bypass tunnel destination IPv4 address.</t></dd>
</section> <dt>Bypass_Group_Identifier:</dt><dd><t>32 bits</t>
<section anchor="ipv6-b-sfrr-ready-extended-association-id" title="IPv6 B-SFRR-R <t>The bypass tunnel group identifier that is assigned to the
eady Extended ASSOCIATION ID"> LSP.</t></dd>
<t>The IPv6 Extended ASSOCIATION ID for the B-SFRR-Ready association <dt>MESSAGE_ID:</dt><dd>A MESSAGE_ID object as defined by
type is carried inside the IPv6 Extended ASSOCIATION object and has <xref target="RFC2961"/>.</dd>
</dl>
</section>
<section anchor="ipv6-b-sfrr-ready-extended-association-id" numbered="tr
ue" toc="default">
<name>IPv6 B-SFRR-Ready Extended Association ID</name>
<t>The IPv6 Extended Association ID for the B-SFRR-Ready Association
Type is carried inside the IPv6 Extended ASSOCIATION object and has
the following format:</t> the following format:</t>
<figure anchor="fig_IPv6_Extended_Association_ID">
<name>The IPv6 Extended Association ID for B-SFRR-Ready</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Tunnel_ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Bypass_Source_IPv6_Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Bypass_Destination_IPv6_Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Group_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MESSAGE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork
> </figure>
<figure title="The IPv6 Extended ASSOCIATION ID for B-SFRR-Ready" anchor="fig_IP <dl newline="false" spacing="normal">
v6_Extended_Association_ID"><artwork><![CDATA[ <dt>Bypass_Tunnel_ID:</dt><dd><t>16 bits</t>
0 1 2 3 <t>The bypass tunnel identifier.</t></dd>
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_Source_IPv6_Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Bypass_Destination_IPv6_Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Group_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MESSAGE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<figure><artwork><![CDATA[
Bypass_Tunnel_ID: 16 bits
The bypass tunnel identifier.
Reserved: 16 bits
Reserved for future use. MUST be set to zero when sending
and ignored on receipt.
Bypass_Source_IPv6_Address: 128 bits
The bypass tunnel source IPV6 address.
Bypass_Destination_IPv6_Address: 128 bits
The bypass tunnel destination IPV6 address.
Bypass_Group_Identifier: 32 bits
The bypass tunnel group identifier that is assigned to the <dt>Reserved:</dt><dd><t>16 bits</t>
LSP. <t>Reserved for future use. <bcp14>MUST</bcp14> be set to zero when send
ing
and ignored on receipt.</t></dd>
MESSAGE_ID <dt>Bypass_Source_IPv6_Address:</dt><dd><t>128 bits</t>
<t>The bypass tunnel source IPv6 address.</t></dd>
A MESSAGE_ID object as defined by [RFC2961]. <dt>Bypass_Destination_IPv6_Address:</dt><dd><t>128 bits</t>
]]></artwork></figure> <t>The bypass tunnel destination IPv6 address.</t></dd>
</section> <dt>Bypass_Group_Identifier:</dt><dd><t>32 bits</t>
<section anchor="processing-rules-for-b-sfrr-ready-extended-association-object" <t>The bypass tunnel group identifier that is assigned to the
title="Processing Rules for B-SFRR-Ready Extended ASSOCIATION Object"> LSP.</t></dd>
<t>A PLR node assigns a bypass tunnel and Bypass_Group_Identifier for each <dt>MESSAGE_ID:</dt>
<dd>A MESSAGE_ID object as defined by <xref target="RFC2961"/>.</dd>
</dl>
</section>
<section anchor="processing-rules-for-b-sfrr-ready-extended-association-
object" numbered="true" toc="default">
<name>Processing Rules for B-SFRR-Ready Extended ASSOCIATION Object</n
ame>
<t>A PLR node assigns a bypass tunnel and Bypass_Group_Identifier for
each
protected LSP. The same Bypass_Group_Identifier is used for the set of protected LSP. The same Bypass_Group_Identifier is used for the set of
protected LSPs that share the same bypass tunnel, traverse the same egress link protected LSPs that share the same bypass tunnel, traverse the same egress link,
and are not already rerouted. The PLR node MUST generate a MESSAGE_ID object and are not already rerouted. The PLR node <bcp14>MUST</bcp14> generate a MESSAG
with Epoch and Message_Identifier set according to <xref target="RFC2961"/>. The E_ID object
MESSAGE_ID with Epoch and Message_Identifier set according to <xref target="RFC2961" format
object flags MUST be cleared when transmitted by the PLR node and ignored ="default"/>. The MESSAGE_ID
object Flags <bcp14>MUST</bcp14> be cleared when transmitted by the PLR node and
ignored
when received at the MP node.</t> when received at the MP node.</t>
<t>A PLR node <bcp14>MUST</bcp14> generate a new Message_Identifier ea
<t>A PLR node MUST generate a new Message_Identifier each time the contents of t ch time the contents of the
he B-SFRR-Ready Extended Association ID change (e.g., when the PLR node
B-SFRR-Ready Extended ASSOCIATION ID changes (e.g. when the PLR node
changes the bypass tunnel assignment).</t> changes the bypass tunnel assignment).</t>
<t>A PLR node notifies the MP node of the bypass tunnel assignment via
<t>A PLR node notifies the MP node of the bypass tunnel assignment via adding a adding a
B-SFRR-Ready Extended ASSOCIATION object and Extended Association ID in the RSVP Path B-SFRR-Ready Extended ASSOCIATION object and Extended Association ID in the RSVP Path
message for the protected LSP using procedures described in <xref target="sig-pr message for the protected LSP, using the procedures described in <xref target="s
ior-failure"> </xref>.</t> ig-prior-failure" format="default"> </xref>.</t>
<t>An MP node acknowledges the assignment to the PLR node by signaling
<t>An MP node acknowledges the assignment to the PLR node by signaling the B-SFR the B-SFRR-Ready
R-Ready
Extended ASSOCIATION object and Extended Association ID within the RSVP Resv mes sage of Extended ASSOCIATION object and Extended Association ID within the RSVP Resv mes sage of
the protected LSP. With the exception of the MESSAGE_ID objects, all other field the protected LSP. With the exception of the MESSAGE_ID object, all other
s fields from the received B-SFRR-Ready Extended Association ID in the RSVP Path
of the received in the B-SFRR-Ready Extended ASSOCIATION ID in the RSVP Path message are copied into the B-SFRR-Ready Extended Association ID to be added in
message are copied into the B-SFRR-Ready Extended ASSOCIATION ID to be added in the Resv message.
the Resv message. The MESSAGE_ID object is set according to <xref target="RFC296 The MESSAGE_ID object is set according to <xref target="RFC2961" format="defaul
1"/>. t"/>.
The MESSAGE_ID object flags MUST be cleared when transmitted by the MP node and The MESSAGE_ID object Flags <bcp14>MUST</bcp14> be cleared when transmitted by t
ignored he MP node and ignored
when received at the PLR node. A new Message_Identifier MUST be used to acknowle when received at the PLR node. A new Message_Identifier <bcp14>MUST</bcp14> be u
dge an sed to acknowledge an
updated PLR node’s assignment.</t> updated PLR node's assignment.</t>
<t>A PLR node considers the protected LSP as Summary FRR capable only
<t>A PLR node considers the protected LSP as Summary FRR capable only if all the if all the
fields in the B-SFRR-Ready Extended ASSOCIATION ID that are sent in the RSVP fields in the B-SFRR-Ready Extended Association ID that are sent in the RSVP
Path message match the fields received in the RSVP Resv message (with exception Path message match the fields received in the RSVP Resv message (with the except
of the MESSAGE_ID). If the fields do not match, or if B-SFRR-Ready Extended ion
ASSOCIATION object is absent in a subsequent refresh, the PLR node MUST of the MESSAGE_ID). If the fields do not match or if the B-SFRR-Ready Extended
ASSOCIATION object is absent in a subsequent refresh, the PLR node <bcp14>MUST</
bcp14>
consider the protected LSP as not Summary FRR capable.</t> consider the protected LSP as not Summary FRR capable.</t>
<t>A race condition may arise for a previously Summary FRR-capable pro
<t>A race condition may arise for a previously Summary FRR capable protected LSP tected LSP
when the MP node triggers a refresh that does not contain the B-SFRR-Ready when the MP node triggers a refresh that does not contain the B-SFRR-Ready
Extended ASSOCIATION object, while at the same time, the PLR triggers Summary Extended ASSOCIATION object, while at the same time the PLR triggers Summary
FRR procedures due to a fault occurring concurrently. In this case, it is FRR procedures due to a fault occurring concurrently. In this case, it is
possible that the PLR triggers Summary FRR procedurees on the protected LSP possible that the PLR triggers Summary FRR procedures on the protected LSP
before it can receive and process the refresh from the MP node. As a result, before it can receive and process the refresh from the MP node. As a result,
the MP will receive a Srefresh with a Message_Identifier that is not associated the MP will receive an Srefresh with a Message_Identifier that is not associated
with any state. As per <xref target="RFC2961"/>, this results in the MP generati with any state. As per <xref target="RFC2961" format="default"/>, this results
ng an in the MP generating an Srefresh NACK for this Message_Identifier and sending it
Srefresh NACK for this Message_Identifier and sending it back to the PLR. The back to the PLR. The
PLR processes the Srefresh NACK and replays the full Path state associated with PLR processes the Srefresh NACK, replays the full Path state associated with
the Message_Identifier, and subsequently recovering from this condition.</t> the Message_Identifier, and subsequently recovers from this condition.</t>
</section>
</section> </section>
</section> <section anchor="sfrr-bypass-active" numbered="true" toc="default">
<section anchor="sfrr-bypass-active" title="B-SFRR-Active Extended ASSOCIATION O <name>B-SFRR-Active Extended ASSOCIATION Object</name>
bject"> <t>The Extended ASSOCIATION object for the B-SFRR-Active Association Typ
e is populated
<t>The Extended ASSOCIATION object for B-SFRR-Active association type is populat by a PLR node to indicate to the MP node (the bypass tunnel destination) that on
ed e
by a PLR node to indicate to the MP node (bypass tunnel destination) that one or more groups of Summary FRR&nbhy;capable protected LSPs that are being protect
or more groups of Summary FRR protected LSPs that are being protected by the ed by the
bypass tunnel are being rerouted over the bypass tunnel.</t> bypass tunnel are being rerouted over the bypass tunnel.</t>
<t>The B-SFRR-Active Extended ASSOCIATION object is carried in the RSVP
<t>The B-SFRR-Active Extended ASSOCIATION object is carried in the RSVP Path Path
message of the bypass tunnel and signaled downstream towards the MP (bypass tunn message of the bypass tunnel and signaled downstream towards the MP (the bypass
el tunnel
destination).</t> destination).</t>
<t>The Association Type, Association ID, and Association Source <bcp14>M
UST</bcp14> be set as
defined in <xref target="RFC4872" format="default"/> for the ASSOCIATION object.
More specifically:</t>
<t>The Association Type, Association ID, and Association Source MUST be set as <dl newline="true" spacing="normal">
defined in <xref target="RFC4872"/> for the ASSOCIATION Object. More specificall <dt>Association Source:</dt>
y:</t> <dd>The Association Source is set to an address of the PLR node.</dd>
<dt>Association Type:</dt>
<t>Association Source:</t> <dd>A new Association Type is defined for B-SFRR-Active as follows:</dd
>
<figure><artwork><![CDATA[ </dl>
The Association Source is set to an address of the PLR node. <table anchor="tab-2">
]]></artwork></figure> <name>The B-SFRR-Active Association Type</name>
<thead>
<t>Association Type:</t> <tr>
<th>Value</th>
<figure><artwork><![CDATA[ <th>Type</th>
A new Association Type is defined for B-SFRR-Active as follows: </tr>
</thead>
Value Type <tbody>
------- ------ <tr>
(TBD-2) Bypass Summary FRR Active Association (B-SFRR-Active) <td>6</td>
]]></artwork></figure> <td>Bypass Summary FRR Active Association (B-SFRR-Active)</td>
</tr>
<t>Extended ASSOCIATION ID for B-SFRR-Active:</t> </tbody>
</table>
<figure><artwork><![CDATA[ <dl newline="true" spacing="normal">
The B-SFRR-Active Extended ASSOCIATION ID is <dt>Extended Association ID for B-SFRR-Active:</dt>
<dd>The B-SFRR-Active Extended Association ID is
populated by the PLR node for the Bypass Summary FRR Active populated by the PLR node for the Bypass Summary FRR Active
association. The rules to populate the Extended ASSOCIATION ID association. The rules to populate the Extended Association ID
in this case are described below. in this case are described below.</dd>
]]></artwork></figure> </dl>
<section anchor="V4_SFRR_ACTIVE" numbered="true" toc="default">
<section anchor="V4_SFRR_ACTIVE" title="IPv4 B-SFRR-Active Extended ASSOCIATION <name>IPv4 B-SFRR-Active Extended Association ID</name>
ID"> <t>The IPv4 Extended Association ID for the B-SFRR-Active Association
Type is
<t>The IPv4 Extended ASSOCIATION ID for the B-SFRR-Active association type is
carried inside the IPv4 Extended ASSOCIATION object and has the following carried inside the IPv4 Extended ASSOCIATION object and has the following
format:</t> format:</t>
<figure anchor="fig_IPv4_SFRR_ACTIVE">
<figure title="The IPv4 Extended ASSOCIATION ID for B-SFRR-Active" anchor="fig_I <name>The IPv4 Extended Association ID for B-SFRR-Active</name>
PV4_SFRR_ACTIVE"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num-BGIDs | Reserved | | Num-BGIDs | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Group_Identifier | | Bypass_Group_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | | : |
// : // // : //
| : | | : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Group_Identifier | | Bypass_Group_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// RSVP_HOP_Object // // RSVP_HOP_Object //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TIME_VALUES // // TIME_VALUES //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address | | IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork
> </figure>
]]></artwork></figure>
<t>Num-BGIDs: 16 bits</t>
<t><list style='empty'>
<t>Number of Bypass_Group_Identifier fields.</t>
</list></t>
<t>Reserved: 16 bits</t>
<t><list style='empty'>
<t>Reserved for future use.</t>
</list></t>
<t>Bypass_Group_Identifier: 32 bits each</t>
<t><list style='empty'> <dl newline="false" spacing="normal">
<t>A Bypass_Group_Identifier that was previously signaled by the PLR <dt>Num-BGIDs:</dt><dd><t>16 bits</t>
<t>Number of Bypass_Group_Identifier fields.</t></dd>
<dt>Reserved:</dt><dd><t>16 bits</t>
<t>Reserved for future use.</t></dd>
<dt>Bypass_Group_Identifier:</dt><dd><t>32 bits each</t>
<t>A Bypass_Group_Identifier that was previously signaled by the PLR
using the Extended ASSOCIATION object in the B-SFRR-Ready Extended using the Extended ASSOCIATION object in the B-SFRR-Ready Extended
Association ID. One or more Bypass_Group_Identifiers MAY be included.</t> Association ID. One or more Bypass_Group_Identifiers <bcp14>MAY</bcp14> be inclu
</list></t> ded.</t></dd>
<dt>RSVP_HOP_Object:</dt><dd><t>Class 3, as defined by <xref
<t>RSVP_HOP_Object: Class 3, as defined by <xref target="RFC2205"/></t> target="RFC2205" format="default"/></t>
<t>Replacement RSVP_HOP object to be applied to all LSPs associated
<t><list style='empty'>
<t>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.</t> to C-Type = 1 for IPv4 RSVP_HOP.</t>
</list></t> </dd>
<dt>TIME_VALUES object:</dt><dd><t>Class 5, as defined by <xref target
<t>TIME_VALUES object: Class 5, as defined by <xref target="RFC2205"/></t> ="RFC2205" format="default"/></t>
<t>Replacement TIME_VALUES object to be applied to all LSPs associate
<t><list style='empty'> d
<t>Replacement TIME_VALUES object to be applied to all LSPs associated
with each of the preceding Bypass_Group_Identifiers after receiving with each of the preceding Bypass_Group_Identifiers after receiving
the B-SFRR-Active Extended ASSOCIATION Object.</t> the B-SFRR-Active Extended ASSOCIATION object.</t></dd>
</list></t> </dl>
<dl newline="true" spacing="normal">
<t>IPv4 tunnel sender address:</t> <dt>IPv4 tunnel sender address:</dt>
<dd>The IPv4 address that the PLR node sets to identify one or more
<t><list style='empty'> backup paths as
<t>The IPv4 address that the PLR node sets to identify backup path(s) as described in <xref target="RFC4090" sectionFormat="of" section="6.1.1"/>. This a
described in Section 6.1.1 of <xref target="RFC4090"/>. This address is applicab ddress is applicable to all
le to all groups identified by any Bypass_Group_Identifiers carried in the B-SFRR-Active
groups identified by Bypass_Group_Identifier(s) carried in the B-SFRR-Active Extended Association ID.</dd>
Extended ASSOCIATION ID.</t> </dl>
</list></t> </section>
<section anchor="V6_SFRR_ACTIVE" numbered="true" toc="default">
</section> <name>IPv6 B-SFRR-Active Extended Association ID</name>
<section anchor="V6_SFRR_ACTIVE" title="IPv6 B-SFRR-Active Extended ASSOCIATION <t>The IPv6 Extended Association ID for the B-SFRR-Active Association
ID"> Type is
<t>The IPv6 Extended ASSOCIATION ID for the B-SFRR-Active association type is
carried inside the IPv6 Extended ASSOCIATION object and has the following carried inside the IPv6 Extended ASSOCIATION object and has the following
format:</t> format:</t>
<figure anchor="fig_IPv6_SFRR_ACTIVE">
<figure title="The IPv6 Extended ASSOCIATION ID for B-SFRR-Active" anchor="fig_I <name>The IPv6 Extended Association ID for B-SFRR-Active</name>
PV6_SFRR_ACTIVE"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num-BGIDs | Reserved | | Num-BGIDs | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bypass_Group_Identifier | | Bypass_Group_Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | | : |
// : // // : //
| : | | : |
skipping to change at line 588 skipping to change at line 517
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TIME_VALUES // // TIME_VALUES //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ IPv6 tunnel sender address + + IPv6 tunnel sender address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork
> </figure>
]]></artwork></figure> <dl newline="false" spacing="normal">
<dt>Num-BGIDs:</dt><dd><t>16 bits</t>
<t>Num-BGIDs: 16 bits</t> <t>Number of Bypass_Group_Identifier fields.</t></dd>
<dt>Reserved:</dt><dd><t>16 bits</t>
<t><list style='empty'> <t>Reserved for future use.</t></dd>
<t>Number of Bypass_Group_Identifier fields.</t> <dt>Bypass_Group_Identifier:</dt><dd><t>32 bits each</t>
</list></t> <t>A Bypass_Group_Identifier that was previously signaled by the PLR
<t>Reserved: 16 bits</t>
<t><list style='empty'>
<t>Reserved for future use.</t>
</list></t>
<t>Bypass_Group_Identifier: 32 bits each</t>
<t><list style='empty'>
<t>A Bypass_Group_Identifier that was previously signaled by the PLR
using the Extended ASSOCIATION object in the B-SFRR-Ready Extended using the Extended ASSOCIATION object in the B-SFRR-Ready Extended
Association ID. One or more Bypass_Group_Identifiers MAY be included.</t> Association ID. One or more Bypass_Group_Identifiers <bcp14>MAY</bcp14> be incl
</list></t> uded.</t></dd>
<dt>RSVP_HOP_Object:</dt><dd><t>Class 3, as defined by <xref target="R
<t>RSVP_HOP_Object: Class 3, as defined by <xref target="RFC2205"/></t> FC2205" format="default"/></t>
<t>Replacement RSVP_HOP object to be applied to all LSPs associated
<t><list style='empty'>
<t>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 = 2 for IPv6 RSVP HOP.</t> to C-Type = 2 for IPv6 RSVP_HOP.</t></dd>
</list></t> <dt>TIME_VALUES object:</dt><dd><t>Class 5, as defined by <xref target
="RFC2205" format="default"/></t>
<t>TIME_VALUES object: Class 5, as defined by <xref target="RFC2205"/></t> <t>Replacement TIME_VALUES object to be applied to all LSPs associate
d
<t><list style='empty'>
<t>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 B-SFRR-Active Extended ASSOCIATION Object.</t> the B-SFRR-Active Extended ASSOCIATION object.</t></dd>
</list></t> </dl>
<dl newline="true" spacing="normal">
<t>IPv6 tunnel sender address:</t> <dt>IPv6 tunnel sender address:</dt>
<dd>The IPv6 address that the PLR node sets to identify one or more
<t><list style='empty'> backup paths as
<t>The IPv6 address that the PLR node sets to identify backup path(s) as described in <xref target="RFC4090" sectionFormat="of" section="6.1.1"/>. This a
described in Section 6.1.1 of <xref target="RFC4090"/>. This address is applicab ddress is applicable to all
le to all groups identified by any Bypass_Group_Identifiers carried in the B-SFRR-Active
groups identified by Bypass_Group_Identifier(s) carried in the B-SFRR-Active Extended Association ID.</dd>
Extended ASSOCIATION ID.</t> </dl>
</list></t> </section>
</section>
</section> <section anchor="sig-prior-failure" numbered="true" toc="default">
</section> <name>Signaling Procedures prior to Failure</name>
<section anchor="sig-prior-failure" title="Signaling Procedures Prior to Failure <t>Before Summary FRR procedures can be used, a handshake <bcp14>MUST</b
"> cp14> be completed
<t>Before Summary FRR procedures can be used, a handshake MUST be completed
between the PLR and MP nodes. This handshake is performed using the Extended ASS OCIATION between the PLR and MP nodes. This handshake is performed using the Extended ASS OCIATION
object that carries the B-SFRR-Ready Extended Association ID in both the RSVP object that carries the B-SFRR-Ready Extended Association ID in both the RSVP
Path and Resv messages of the protected LSP.</t> Path and Resv messages of the protected LSP.</t>
<t>The facility backup method introduced in <xref target="RFC4090" forma
<t>The facility backup method introduced in <xref target="RFC4090"/> takes advan t="default"/> takes advantage of MPLS label
tage of MPLS label stacking (the PLR node imposes additional MPLS labels post-FRR) to allow rerouti
stacking (PLR node imposing additional MPLS label post FRR) to allow rerouting o ng of
f
protected traffic over the backup path. The backup path may have stricter MTU protected traffic over the backup path. The backup path may have stricter MTU
requirement and due to label stacking at PLR node, the protected traffic may exc requirements; due to label stacking at the PLR node, the protected traffic may e
eed xceed
the backup path MTU. The operator is assumed to engineer their network to the backup path MTU. It is assumed that the operator engineers their network to
allow rerouting of protected traffic and the additional label stacking at PLR no allow rerouting of protected traffic and the additional label stacking at the
de PLR node in order to not exceed the backup path MTU.</t>
to not exceed the backup path MTU.</t> <t>When using the procedures defined in this document, the PLR node
<bcp14>MUST</bcp14> ensure that the
<t>When using procedures defined in this document, the PLR node MUST ensure the bypass tunnel assignment can satisfy the protected LSP MTU requirements post-FRR
bypass tunnel assignment can satisfy the protected LSP MTU requirements post . This prevents any packets from being dropped due to exceeding the MTU size
FRR. This avoids any packets from being dropped due to exceeding the MTU size of the backup path after traffic is rerouted onto the bypass tunnel post-failure
of the backup path after traffic is rerouted on to the bypass tunnel post the . <xref target="RFC3209" sectionFormat="of" section="2.6"/> describes a mechanis
failure. Section 2.6 in <xref target="RFC3209"/> describes a mechanism to determ m to determine whether
ine whether a node needs to fragment or drop a packet when it exceeds the path MTU
a node needs to fragment or drop a packet when it exceeds the Path MTU discovered using RSVP signaling on the primary LSP path. A PLR can leverage
discovered using RSVP signaling on primary LSP path. A PLR can leverage the RSVP-discovered path MTU on the backup and primary LSP paths to ensure
the RSVP discovered Path MTU on the backup and primary LSP paths to ensure MTU that the MTU
is not exceeded before or after rerouting the protected traffic on to the is not exceeded before or after rerouting the protected traffic onto the
bypass tunnel.</t> bypass tunnel.</t>
<section anchor="plr-signaling-procedure" numbered="true" toc="default">
<section anchor="plr-signaling-procedure" title="PLR Signaling Procedure"> <name>PLR Signaling Procedure</name>
<t>The B-SFRR-Ready Extended ASSOCIATION object is added by each PLR n
<t>The B-SFRR-Ready Extended ASSOCIATION object is added by each PLR node in the ode in the RSVP
RSVP
Path message of the protected LSP to record the bypass tunnel assignment. This Path message of the protected LSP to record the bypass tunnel assignment. This
object is updated every time the PLR node updates the bypass tunnel assignment a object is updated every time the PLR node updates the bypass tunnel
nd assignment. This results in triggering an RSVP Path change message.
that triggers an RSVP Path change message.</t> </t>
<t>Upon receiving an RSVP Resv message with a B-SFRR-Ready Extended AS
<t>Upon receiving an RSVP Resv message with B-SFRR-Ready Extended ASSOCIATION SOCIATION
object, the PLR node checks if the expected sub-objects from the B-SFRR-Ready object, the PLR node checks to see if the expected subobjects from the B-SFRR-Re
Extended ASSOCIATION ID are present. If present, the PLR node determines if the ady
MP has Extended Association ID are present. If present, the PLR node determines if the
acknowledged the current PLR node’s assignment.</t> MP has
acknowledged the current PLR node's assignment.</t>
<t>To be a valid acknowledgement, the received B-SFRR-Ready Extended ASSOCIATION <t>To be a valid acknowledgment, the received B-SFRR-Ready Extended As
ID sociation ID
contents within the RSVP Resv message of the protected LSP MUST match the contents within the RSVP Resv message of the protected LSP <bcp14>MUST</bcp14> m
atch the
latest B-SFRR-Ready Extended ASSOCIATION object and Association ID contents 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 that the PLR node had sent within the RSVP Path message (with the exception of t he
MESSAGE_ID).</t> MESSAGE_ID).</t>
<t>Note that when forwarding an RSVP Resv message upstream, the PLR no
<t>Note, when forwarding an RSVP Resv message upstream, the PLR node SHOULD remo de <bcp14>SHOULD</bcp14> remove
ve
any/all B-SFRR-Ready Extended ASSOCIATION objects whose Bypass_Source_IPv4_Addre ss or any/all B-SFRR-Ready Extended ASSOCIATION objects whose Bypass_Source_IPv4_Addre ss or
Bypass_Source_IPv6_Address field matches any of the PLR node addresses.</t> Bypass_Source_IPv6_Address field matches any of the PLR node addresses.</t>
</section>
</section> <section anchor="mp-signaling-procedure" numbered="true" toc="default">
<section anchor="mp-signaling-procedure" title="MP Signaling Procedure"> <name>MP Signaling Procedure</name>
<t>Upon receiving an RSVP Path message with a B-SFRR-Ready Extended AS
<t>Upon receiving an RSVP Path message with a B-SFRR-Ready Extended ASSOCIATION SOCIATION
object, an MP node processes all (there may be multiple PLR nodes for a single M P node) object, an MP node processes all (there may be multiple PLR nodes for a single M P node)
B-SFRR-Ready Extended ASSOCIATION objects that have the MP node address as B-SFRR-Ready Extended ASSOCIATION objects that have the MP node address as the
Bypass Destination address in the Extended Association ID.</t> bypass destination address in the Extended Association ID.</t>
<t>The MP node first ensures the existence of the bypass tunnel and th
<t>The MP node first ensures the existence of the bypass tunnel and that the at the
Bypass_Group_Identifier is not already FRR active. That is, an LSP cannot join Bypass_Group_Identifier is not already FRR Active. That is, an LSP cannot join
a group that is already FRR rerouted.</t> a group that is already FRR rerouted.</t>
<t>The MP node builds a mirrored Summary FRR group database per PLR no
<t>The MP node builds a mirrored Summary FRR Group database per PLR node by de by
associating the Bypass_Source_IPv4_Address or Bypass_Source_IPv6_Address associating the Bypass_Source_IPv4_Address or Bypass_Source_IPv6_Address
that is carried in the IPv4 or IPv6 B-SFRR-Ready Extended ASSOCIATION IDs that is carried in the IPv4 or IPv6 B&nbhy;SFRR-Ready Extended Association IDs,
respectively.</t> respectively.</t>
<t>The MESSAGE_ID is extracted and recorded for the protected LSP Path
<t>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
state. The MP node signals a B-SFRR-Ready Extended Association object and
Extended Association ID in the RSVP Resv message of the protected LSP. With the Extended Association ID in the RSVP Resv message of the protected LSP. With the
exception of the MESSAGE_ID objects, all other fields of the received 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 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 into the B-SFRR-Ready Extended ASSOCIATION object to be added in the Resv
message. The MESSAGE_ID object is set according to <xref target="RFC2961"/> with message. The MESSAGE_ID object is set according to <xref target="RFC2961"
the Flags format="default"/> with the Flags cleared.</t>
being clear.</t> <t>Note that an MP may receive more than one RSVP Path message with th
e B-SFRR-Ready
<t>Note, an MP may receive more than one RSVP Path message with the B-SFRR-Ready Extended ASSOCIATION object from one or more different upstream PLR nodes. In th
Extended ASSOCIATION object from different upstream PLR node(s). In this case, is case,
the MP node is expected to save all the received MESSAGE_IDs received from the d ifferent the MP node is expected to save all the received MESSAGE_IDs received from the d ifferent
upstream PLR node(s). After a failure, the MP node determines and activates the upstream PLR nodes. After a failure, the MP node determines and activates the
state(s) associated with the Bypass_Group_Identifier(s) received in the RSVP state(s) associated with the Bypass_Group_Identifier(s) received in the RSVP
Path message containing B-SFRR-Active Extended ASSOCIATION object that is Path message containing the B-SFRR-Active Extended ASSOCIATION object that is
signaled over the bypass tunnel from the PLR node, as described <xref target="po signaled over the bypass tunnel from the PLR node, as described in <xref target=
st-failure"> </xref></t> "post-failure" format="default"> </xref>.</t>
<t>When forwarding an RSVP Path message downstream, the MP node <bcp14
<t>When forwarding an RSVP Path message downstream, the MP node SHOULD remove an >SHOULD</bcp14> remove any/all
y/all B-SFRR-Ready Extended ASSOCIATION objects whose Bypass_Destination_IPv4_Address
B-SFRR-Ready Extended ASSOCIATION object(s) whose Bypass_Destination_IPv4_Addres or
s or
Bypass_Destination_IPv6_Address field matches any of the MP node addresses.</t> Bypass_Destination_IPv6_Address field matches any of the MP node addresses.</t>
</section>
</section> </section>
</section> <section anchor="post-failure" numbered="true" toc="default">
<section anchor="post-failure" title="Signaling Procedures Post Failure"> <name>Signaling Procedures Post-Failure</name>
<t>Upon detection of a fault (egress link or node failure), the PLR node
<t>Upon detection of a fault (egress link or node failure) the PLR node will fir will first
st perform the object modification procedures described by <xref target="RFC4090" s
perform the object modification procedures described by Section 6.4.3 of ectionFormat="of" section="6.4.3"/> for all affected protected LSPs. For the Sum
<xref target="RFC4090"/> for all affected protected LSPs. For the Summary FRR ca mary FRR-capable LSPs
pable LSPs that are assigned to the same bypass tunnel, a common RSVP_HOP and
that are assigned to the same bypass tunnel a common RSVP_HOP and SENDER_TEMPLATE <bcp14>MUST</bcp14> be used.</t>
SENDER_TEMPLATE MUST be used.</t> <t>The PLR node <bcp14>MUST</bcp14> signal non-Summary FRR-capable LSPs
over the bypass tunnel before
<t>The PLR node MUST signal non-Summary FRR capable LSPs over the bypass tunnel signaling the Summary FRR-capable LSPs. This is needed to allow for the case
before
signaling the Summary FRR capable LSPs. This is needed to allow for the case
where the PLR node recently changed a bypass assignment and the MP has not where the PLR node recently changed a bypass assignment and the MP has not
processed the change yet.</t> processed the change yet.</t>
<t>The B-SFRR-Active Extended ASSOCIATION object is sent within the RSVP
<t>The B-SFRR-Active Extended ASSOCIATION object is sent within the RSVP Path Path
message of the bypass tunnel to reroute RSVP state of Summary FRR capable LSPs.< message of the bypass tunnel to reroute the RSVP state of Summary FRR-capable LS
/t> Ps.</t>
<section anchor="plr-sfrr" numbered="true" toc="default">
<section anchor="plr-sfrr" title="PLR Signaling Procedure"> <name>PLR Signaling Procedure</name>
<t>After a failure event, when using the Summary FRR path signaling pr
<t>After a failure event, when using the Summary FRR path signaling procedures, ocedures,
an individual RSVP Path message is not signaled for each Summary FRR LSP. an individual RSVP Path message is not signaled for each Summary FRR LSP.
Instead, to reroute Summary FRR LSPs via the bypass tunnel, the PLR node adds th e Instead, to reroute Summary FRR LSPs via the bypass tunnel, the PLR node adds th e
B-SFRR-Active Extended Association object in the RSVP Path message of the B-SFRR-Active Extended ASSOCIATION object in the RSVP Path message of the
RSVP session of the bypass tunnel.</t> RSVP session of the bypass tunnel.</t>
<t>The RSVP_HOP_Object field in the B-SFRR-Active Extended Association
<t>The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION ID is set ID is set
to a common object that will be applied to all LSPs associated to a common object that will be applied to all LSPs associated
with the Bypass_Group_Identifiers that are carried in the B-SFRR-Active with the Bypass_Group_Identifiers that are carried in the B-SFRR-Active
Extended ASSOCIATION ID.</t> Extended Association ID.</t>
<t>The PLR node adds the Bypass_Group_Identifier(s) of any group or gr
<t>The PLR node adds the Bypass_Group_Identifier(s) of group(s) that have common oups that have common
group attributes, including the tunnel sender address, to the same B-SFRR-Active group attributes, including the tunnel sender address, to the same B-SFRR-Active
Extended ASSOCIATION ID. Note that multiple ASSOCIATION objects, each carrying a Extended Association ID. Note that multiple ASSOCIATION objects, each carrying a
B-SFRR-Active Extended ASSOCIATION ID, can be carried within a single RSVP Path B-SFRR-Active Extended Association ID, can be carried within a single RSVP Path
message of the bypass tunnel and sent towards the MP as described in <xref targe message of the bypass tunnel and sent towards the MP as described in <xref targe
t="RFC6780"/>.</t> t="RFC6780" format="default"/>.</t>
<t>Any previously received MESSAGE_IDs from the MP are activated on th
<t>The previously received MESSAGE_ID(s) from the MP are activated on the PLR. A e PLR. As a result,
s a result, the PLR starts sending Srefresh messages containing the specific Message_Identif
the PLR starts sending Srefresh messages containing the specific Message_identif ier(s)
ier(s)
for the states to be refreshed.</t> for the states to be refreshed.</t>
</section>
</section> <section anchor="mp-signaling-procedure-1" numbered="true" toc="default"
<section anchor="mp-signaling-procedure-1" title="MP Signaling Procedure"> >
<name>MP Signaling Procedure</name>
<t>Upon receiving an RSVP Path message with a B-SFRR-Active Extended Association <t>Upon receiving an RSVP Path message with a B-SFRR-Active Extended A
SSOCIATION
object, the MP performs normal merge point processing for each protected LSP object, the MP performs normal merge point processing for each protected LSP
associated with each Bypass_Group_Identifier, as if it had received an associated with each Bypass_Group_Identifier, as if it had received an
individual RSVP Path message for that LSP.</t> individual RSVP Path message for that LSP.</t>
<t>For each Summary FRR-capable LSP that is being merged, the MP first
<t>For each Summary FRR capable LSP that is being merged, the MP first modifies modifies the Path
the Path
state as follows:</t> state as follows:</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>The RSVP_HOP object is copied from the RSVP_HOP_Object field in
<t>The RSVP_HOP object is copied from the RSVP_HOP_Object field in the the
B-SFRR-Active Extended ASSOCIATION ID.</t> B-SFRR-Active Extended Association ID.</li>
<t>The TIME_VALUES object is copied from the TIME_VALUES field in the <li>The TIME_VALUES object is copied from the TIME_VALUES field in t
B-SFRR-Active Extended ASSOCIATION ID. The TIME_VALUES object contains the he
refresh time of the PLR node to generate refreshes and that would have B-SFRR-Active Extended Association ID. The TIME_VALUES object contains the
exchanged in a Path message sent to the MP after the failure when no Summary refresh period of the PLR node, and it is used to generate periodic
FRR procedures are in effect.</t> refreshes. The TIME_VALUES object carried in the B-SFRR-Active Extended
<t>The tunnel sender address field in the SENDER_TEMPLATE object is copied fro Association ID matches the one that would have been
m exchanged in a full Path message sent to the MP after the failure when no Summar
the tunnel sender address field of the B-SFRR-Active Extended ASSOCIATION ID.</t y
> FRR procedures are used.</li>
<t>The ERO object is modified as per Section 6.4.4 of <xref target="RFC4090"/> <li>The tunnel sender address field in the SENDER_TEMPLATE object is
. copied from
Once the above modifications are completed, the MP node performs the the tunnel sender address field of the B-SFRR-Active Extended Association ID.</l
merge processing as per <xref target="RFC4090"/>.</t> i>
<t>The previously received MESSAGE_ID(s) from the PLR node are activated. The <li>The Explicit Route Object (ERO) is modified as per <xref target=
MP "RFC4090"
is allowed to send Srefresh messages containing the specific Message_identifier( sectionFormat="of" section="6.4.4"/>. Once the above modifications a
s) re completed, the MP node performs
for the states to be refreshed.</t> merge processing as per <xref target="RFC4090" format="default"/>.</li>
</list></t> <li>Any previously received MESSAGE_IDs from the PLR node are activa
ted. The MP
<t>A failure during merge processing of any individual rerouted LSP MUST is allowed to send Srefresh messages containing the specific Message_Identifier(
result in an RSVP Path Error message.</t> s)
for the states to be refreshed.</li>
<t>An individual RSVP Resv message for each successfully merged Summary </ol>
FRR LSP is not signaled. The MP node SHOULD immediately use Summary <t>A failure during merge processing of any individual rerouted LSP <b
Refresh procedures to refresh the protected LSP Resv state.</t> cp14>MUST</bcp14>
result in an RSVP PathErr message.
</section> </t>
</section> <t>An individual RSVP Resv message for each successfully merged Summar
<section anchor="refreshing-summary-frr-active-lsps" title="Refreshing Summary F y
RR Active LSPs"> FRR LSP is not signaled. The MP node <bcp14>SHOULD</bcp14> immediately use summa
ry
<t>Refreshing of Summary FRR active LSPs is performed using Summary refresh procedures to refresh the protected LSP Resv state.</t>
Refresh as defined by <xref target="RFC2961"/>.</t> </section>
</section>
</section> <section anchor="refreshing-summary-frr-active-lsps" numbered="true" toc="
</section> default">
<section anchor="backwards-compatibility" title="Backwards Compatibility"> <name>Refreshing Summary FRR Active LSPs</name>
<t>The refreshing of Summary FRR Active LSPs is performed using summary
<t>The (Extended) ASSOCIATION object is defined in <xref target="RFC4872"/> with refresh as defined by <xref target="RFC2961" format="default"/>.</t>
a class number </section>
</section>
<section anchor="backwards-compatibility" numbered="true" toc="default">
<name>Backwards Compatibility</name>
<t>The (Extended) ASSOCIATION object is defined in <xref target="RFC4872"
format="default"/> with a class number
in the form 11bbbbbb, where b=0 or 1. This ensures compatibility with in the form 11bbbbbb, where b=0 or 1. This ensures compatibility with
non-supporting node(s) in accordance with the procedures specified in nodes that do not provide support, in accordance with the procedures specified i
<xref target="RFC2205"/>, Section 3.10 for unknown-class objects, n
<xref target="RFC2205" sectionFormat="of" section="3.10"/> regarding unknown-cla
ss objects.
Such nodes will ignore the object and forward it without any modification.</t> Such nodes will ignore the object and forward it without any modification.</t>
</section>
</section> <section anchor="security-considerations" numbered="true" toc="default">
<section anchor="security-considerations" title="Security Considerations"> <name>Security Considerations</name>
<t>This document updates an existing RSVP object -- the Extended
<t>This document updates an existing RSVP object. Thus, in the event of the ASSOCIATION object as described in <xref target="extensions-for-summary-fr
r-signaling"/>.
Thus, in the event of the
interception of a signaling message, slightly more information could be deduced interception of a signaling message, slightly more information could be deduced
about the state of the network than was previously the case.</t> about the state of the network than was previously the case.</t>
<t>When using the procedures defined in this document, FRR signaling for r
<t>When using procedures defined in this document, FRR signaling for rerouting erouting
of protected LSP(s) states on to the bypass tunnel can be performed on a group of the states of one or more protected LSPs onto the bypass tunnel can be perfor
of protected LSP(s) with a single RSVP message. This allows an intruder to med on a group
potentially impact and manipulate a set of protected LSP that are assigned to of protected LSPs with a single RSVP message. This allows an intruder to
the same bypass tunnel group. Note that such attack is even possible without potentially impact and manipulate a set of protected LSPs that are assigned to
the mechanisms proposed in this document; albeit, at an extra cost resulting the same bypass tunnel group. Note that such an attack is possible even without
from the excessive per LSP signaling that will occur.</t> the mechanisms defined in this document, albeit at an extra cost resulting
from the excessive per-LSP signaling that will occur.</t>
<t>Existing mechanisms for maintaining the integrity and authenticity of RSVP <t>Existing mechanisms for maintaining the integrity and authenticity of R
protocol messages <xref target="RFC2747"/> can be applied. Other considerations SVP
mentioned messages <xref target="RFC2747" format="default"/> can be applied. Other conside
in <xref target="RFC4090"/> and <xref target="RFC5920"/> also apply.</t> rations mentioned
in <xref target="RFC4090" format="default"/> and <xref target="RFC5920" format="
</section> default"/> also apply.</t>
<section anchor="iana-considerations" title="IANA Considerations"> </section>
<section anchor="iana-considerations" numbered="true" toc="default">
<t>IANA maintains the “Generalized Multi-Protocol Label Switching (GMPLS) <name>IANA Considerations</name>
Signaling Parameters” registry. The “Association Type” sub-registry is included <t>IANA maintains the "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Parameters" registry. The "Association Type" subregistry
is included
in this registry.</t> in this registry.</t>
<t>This registry has been updated with the new
<t>This registry has been updated by new Association Type for Association Types for the Extended ASSOCIATION objects defined in this docume
Extended ASSOCIATION Object defined in this document nt
as follows:</t> as follows:</t>
<figure><artwork><![CDATA[ <table anchor="tab-3">
Value Name Reference <name>New Extended ASSOCIATION Object Association Types</name>
----- ---- --------- <thead>
TBD-1 B-SFRR-Ready Association Section 3.1 <tr>
TBD-2 B-SFRR-Active Association Section 3.2 <th>Value</th>
]]></artwork></figure> <th>Name</th>
<th>Reference</th>
</section> </tr>
<section anchor="acknowledgments" title="Acknowledgments"> </thead>
<tbody>
<t>The authors would like to thank Alexander Okonnikov, Loa Andersson, Lou Berge <tr>
r, <td>5</td>
Eric Osborne, Gregory Mirsky, Mach Chen for reviewing and providing valuable <td>B-SFRR-Ready Association</td>
comments to this document.</t> <td><xref target="sfrr-bypass-ready"/></td>
</tr>
</section> <tr>
<section anchor="contributors" title="Contributors"> <td>6</td>
<td>B-SFRR-Active Association</td>
<figure><artwork><![CDATA[ <td><xref target="sfrr-bypass-active"/></td>
Nicholas Tan </tr>
Arista Networks </tbody>
</table>
Email: ntan@arista.com </section>
]]></artwork></figure>
</section>
</middle> </middle>
<back> <back>
<references>
<references title='Normative References'> <name>References</name>
<references>
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> <name>Normative References</name>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<title>Key words for use in RFCs to Indicate Requirement Levels</title> xml"/>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></ <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4090.
author> xml"/>
<date year='1997' month='March' /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2961.
<abstract><t>In many standards track documents several words are used to signify xml"/>
the requirements in the specification. These words are often capitalized. This <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
document defines these words as they should be interpreted in IETF documents. xml"/>
This document specifies an Internet Best Current Practices for the Internet Comm <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3209.
unity, and requests discussion and suggestions for improvements.</t></abstract> xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4872.
<seriesInfo name='BCP' value='14'/> xml"/>
<seriesInfo name='RFC' value='2119'/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6780.
<seriesInfo name='DOI' value='10.17487/RFC2119'/> xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2205.
xml"/>
<reference anchor="RFC4090" target='https://www.rfc-editor.org/info/rfc4090'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2747.
<front> xml"/>
<title>Fast Reroute Extensions to RSVP-TE for LSP Tunnels</title> </references>
<author initials='P.' surname='Pan' fullname='P. Pan' role='editor'><organizatio <references>
n /></author> <name>Informative References</name>
<author initials='G.' surname='Swallow' fullname='G. Swallow' role='editor'><org <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5920.
anization /></author> xml"/>
<author initials='A.' surname='Atlas' fullname='A. Atlas' role='editor'><organiz </references>
ation /></author>
<date year='2005' month='May' />
<abstract><t>This document defines RSVP-TE extensions to establish backup label-
switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms e
nable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds
, in the event of a failure.</t><t>Two methods are defined here. The one-to-one
backup method creates detour LSPs for each protected LSP at each potential poin
t of local repair. The facility backup method creates a bypass tunnel to protec
t a potential failure point; by taking advantage of MPLS label stacking, this by
pass tunnel can protect a set of LSPs that have similar backup constraints. Bot
h methods can be used to protect links and nodes during network failure. The de
scribed behavior and extensions to RSVP allow nodes to implement either method o
r both and to interoperate in a mixed network. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4090'/>
<seriesInfo name='DOI' value='10.17487/RFC4090'/>
</reference>
<reference anchor="RFC2961" target='https://www.rfc-editor.org/info/rfc2961'>
<front>
<title>RSVP Refresh Overhead Reduction Extensions</title>
<author initials='L.' surname='Berger' fullname='L. Berger'><organization /></au
thor>
<author initials='D.' surname='Gan' fullname='D. Gan'><organization /></author>
<author initials='G.' surname='Swallow' fullname='G. Swallow'><organization /></
author>
<author initials='P.' surname='Pan' fullname='P. Pan'><organization /></author>
<author initials='F.' surname='Tommasi' fullname='F. Tommasi'><organization /></
author>
<author initials='S.' surname='Molendini' fullname='S. Molendini'><organization
/></author>
<date year='2001' month='April' />
<abstract><t>This document describes a number of mechanisms that can be used to
reduce processing overhead requirements of refresh messages, eliminate the state
synchronization latency incurred when an RSVP (Resource ReserVation Protocol) m
essage is lost and, when desired, refreshing state without the transmission of w
hole refresh messages. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2961'/>
<seriesInfo name='DOI' value='10.17487/RFC2961'/>
</reference>
<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor="RFC3209" target='https://www.rfc-editor.org/info/rfc3209'>
<front>
<title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
<author initials='D.' surname='Awduche' fullname='D. Awduche'><organization /></
author>
<author initials='L.' surname='Berger' fullname='L. Berger'><organization /></au
thor>
<author initials='D.' surname='Gan' fullname='D. Gan'><organization /></author>
<author initials='T.' surname='Li' fullname='T. Li'><organization /></author>
<author initials='V.' surname='Srinivasan' fullname='V. Srinivasan'><organizatio
n /></author>
<author initials='G.' surname='Swallow' fullname='G. Swallow'><organization /></
author>
<date year='2001' month='December' />
<abstract><t>This document describes the use of RSVP (Resource Reservation Proto
col), including all the necessary extensions, to establish label-switched paths
(LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is
completely identified by the label applied at the ingress node of the path, the
se paths may be treated as tunnels. A key application of LSP tunnels is traffic
engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]</t></abstrac
t>
</front>
<seriesInfo name='RFC' value='3209'/>
<seriesInfo name='DOI' value='10.17487/RFC3209'/>
</reference>
<reference anchor="RFC4872" target='https://www.rfc-editor.org/info/rfc4872'>
<front>
<title>RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol La
bel Switching (GMPLS) Recovery</title>
<author initials='J.P.' surname='Lang' fullname='J.P. Lang' role='editor'><organ
ization /></author>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter' role='editor'><org
anization /></author>
<author initials='D.' surname='Papadimitriou' fullname='D. Papadimitriou' role='
editor'><organization /></author>
<date year='2007' month='May' />
<abstract><t>This document describes protocol-specific procedures and extensions
for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Pro
tocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Swit
ched Path (LSP) recovery that denotes protection and restoration. A generic fun
ctional description of GMPLS recovery can be found in a companion document, RFC
4426. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4872'/>
<seriesInfo name='DOI' value='10.17487/RFC4872'/>
</reference>
<reference anchor="RFC6780" target='https://www.rfc-editor.org/info/rfc6780'>
<front>
<title>RSVP ASSOCIATION Object Extensions</title>
<author initials='L.' surname='Berger' fullname='L. Berger'><organization /></au
thor>
<author initials='F.' surname='Le Faucheur' fullname='F. Le Faucheur'><organizat
ion /></author>
<author initials='A.' surname='Narayanan' fullname='A. Narayanan'><organization
/></author>
<date year='2012' month='October' />
<abstract><t>The RSVP ASSOCIATION object was defined in the context of GMPLS-con
trolled Label Switched Paths (LSPs). In this context, the object is used to ass
ociate recovery LSPs with the LSP they are protecting. This object also has bro
ader applicability as a mechanism to associate RSVP state. This document define
s how the ASSOCIATION object can be more generally applied. This document also
defines Extended ASSOCIATION objects that, in particular, can be used in the con
text of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, R
FC 3209, and RFC 3473. It also generalizes the definition of the Association ID
field defined in RFC 4872. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6780'/>
<seriesInfo name='DOI' value='10.17487/RFC6780'/>
</reference>
<reference anchor="RFC2205" target='https://www.rfc-editor.org/info/rfc2205'>
<front>
<title>Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specificatio
n</title>
<author initials='R.' surname='Braden' fullname='R. Braden' role='editor'><organ
ization /></author>
<author initials='L.' surname='Zhang' fullname='L. Zhang'><organization /></auth
or>
<author initials='S.' surname='Berson' fullname='S. Berson'><organization /></au
thor>
<author initials='S.' surname='Herzog' fullname='S. Herzog'><organization /></au
thor>
<author initials='S.' surname='Jamin' fullname='S. Jamin'><organization /></auth
or>
<date year='1997' month='September' />
<abstract><t>This memo describes version 1 of RSVP, a resource reservation setup
protocol designed for an integrated services Internet. RSVP provides receiver-
initiated setup of resource reservations for multicast or unicast data flows, wi
th good scaling and robustness properties. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2205'/>
<seriesInfo name='DOI' value='10.17487/RFC2205'/>
</reference>
<reference anchor="RFC2747" target='https://www.rfc-editor.org/info/rfc2747'>
<front>
<title>RSVP Cryptographic Authentication</title>
<author initials='F.' surname='Baker' fullname='F. Baker'><organization /></auth
or>
<author initials='B.' surname='Lindell' fullname='B. Lindell'><organization /></
author>
<author initials='M.' surname='Talwar' fullname='M. Talwar'><organization /></au
thor>
<date year='2000' month='January' />
<abstract><t>This document describes the format and use of RSVP's INTEGRITY obje
ct to provide hop-by-hop integrity and authentication of RSVP messages. [STANDAR
DS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2747'/>
<seriesInfo name='DOI' value='10.17487/RFC2747'/>
</reference>
</references>
<references title='Informative References'>
<reference anchor="RFC5920" target='https://www.rfc-editor.org/info/rfc5920'>
<front>
<title>Security Framework for MPLS and GMPLS Networks</title>
<author initials='L.' surname='Fang' fullname='L. Fang' role='editor'><organizat
ion /></author>
<date year='2010' month='July' />
<abstract><t>This document provides a security framework for Multiprotocol Label
Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks
. This document addresses the security aspects that are relevant in the context
of MPLS and GMPLS. It describes the security threats, the related defensive te
chniques, and the mechanisms for detection and reporting. This document emphasi
zes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provi
der security considerations for building and maintaining MPLS and GMPLS networks
across different domains or different Service Providers. This document is not
an Internet Standards Track specification; it is published for informational pu
rposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='5920'/>
<seriesInfo name='DOI' value='10.17487/RFC5920'/>
</reference>
</references> </references>
<section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Alexander Okonnikov"
/>, <contact fullname="Loa Andersson"/>, <contact fullname="Lou Berger"/>,
<contact fullname="Eric Osborne"/>, <contact fullname="Gregory Mirsky"/>,
and <contact fullname="Mach Chen"/> for reviewing and providing valuable
comments on this document.</t>
</section>
<section anchor="contributors" numbered="false" toc="default">
<name>Contributors</name>
<contact fullname="Nicholas Tan">
<organization>Arista Networks</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<country></country>
</postal>
<email>ntan@arista.com</email>
</address>
</contact>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAOeYcV4AA+09a3Mbx5Hf51fMSR+OzBGwSMm0zavkDFG0wpwo8khKqVQq
pVoshsSai11kH6Rgx/fbr18zO7MPENQj5XOEVMUUsDvT09Pv6e4ZjUaqSqrU
HOjzi7dno8sjfVEvFlGx0j9EZaXPTZHXldFH7yuTlUmelfoqL/SrizN9WWeZ
SUsVTaeFue15//xczfI4ixYw+KyIrqpRYqqr0WKZlqOSHxpdFcWoKG+XlRk9
+U7Vy1lUmfJAP3vy3RMVw9/XebE60GU1U8myONBVUZfV3hP4dU/d5cXNNUC3
PNAnZ68u9J/h30l2rV/id+rGrOCB2YE+zipTZKYavUAQlCqrKJu9i9I8A7BW
plTL5ED/tcrjHV3mRVWYqxL+Wi3wj78pFdXVPC8OlB4pDZ8kA+hOxvoySlIY
gr7jFZ4kNyb4Oi+uoyz5KaoAawf6MCnjXF+sysosYILjLB7TU2YBrxzoRcVv
fh/jc+M4XwQzXo71RRTNvOkuo8LcNF8WOW6hmSVVXvTM/qc6S5am0K9NhWgr
/amrEgb5/kd+YgyYCmY+H+uXgLB54s19Ht2Ycu5//6C14rPworfUYMbJWL+A
4Rf1zdybczKdJ+Uclhz8tvkqo5m8F6y0va1/gtf8PY2Km7psvg2n2937Vl+a
eJ7laX69CnbzR3jje/i9cj931/l2rM/G+rkxRbTw5nwLy8xqfRbdRpn/6+ZL
vZ3SW+FCs7xYwLu3BkhZn/9wuLe7+92BUkl21fygRqORjqZlVUQxvHIJGNfA
wfXCZJUW3sR3iT1JDlRzAyKizOsipj9McUsA6rMiB5bKU72FYmFbXQLzXSXx
6Ci7TjIADxl16/JoWy+LPDazuoCRZ+YKfpvRwFdRnKRJtVLTKL6pl/gY4BKH
Bt6DSS00SRan9cxo08inah5VuoAxASSEL1rkNcCfX6kyuc6iFKcGAuSZyxL/
Sa/kcVwXAEVNwAXSbwtk2fYOvqXKelqav9eAkXS1o5MFjHILcJRxlEZTAlnf
zU2m62xmiuuchjo/13Ge3cK/TQZAgRiCnYs0QHKjYK1ZDgu4gq0DLNDqymA9
EciFO8Y0oFIvAOboGp+I51EGf0yBBAzMCE+oM5gQl6pf5QAQwL+MkkJvnb06
36Y14ygnCIfmJ7dOzrZpfkBbDiMBPmdmaeD/eBgcM6sXU4AX/iWbAFv0Kpqa
VF/cJVU8h3+eRdW81FugFcptkNERLJXw6oG2ILQou696ulpGZUm4afZWA8HV
pZnxHjfb5WOjAFzVacqUcRcVsxKQu1gC2U1TowGiuV0Qbuosh39VuqyXSxDu
BMiY6XyRzGapUeoxaogiB3JBCJDqTc/m99Fpkumff/434Adkh19+ge/LuEim
RHVqYXB7knJROkZZtzmA/ULmq5hVaL8cChS8FnkbYJVtz0bQPmzrPIMxcVrB
dEXqGoFG8Myt7HCkYRSkRN2hxIs6nnub4GEANwEkC4oOA5o5myW3yawGQl3R
Yk0EL8IiGFSPai7OcGdhkxfRShMI/FJqIqDNXAGXwFakeplGmQl4CpGRAsdn
8QqIpKwBiDxjrL46x1+/EiR71K086p7VBnGcJosEIVmYBRgWNOrh2RtfFBQi
zUqBFEACpYqUAf8w76PYFNMIhyAuxxkFX7LgEhk7Qhh6+QY4hAhTCZewiCpB
8tuFgDHDMAOd/oDIfB+BxWR2cOdk6BFixjQ0gIMC26b5CiU1yCmNS4EnQupQ
50hfBdIHigOgd5SECDBOTXuP+zLPgfiR31gA5HUJUJXBOlQwtbkunByVtTQr
RtIiyQlyrMxxVpoys8tEglEI8CKBtXlIc6iChdMEdsNpAhx2DJxL3zhiRsq2
28H/bEjbJNfzqdD4jhOnuIiQ6uQ9fExt0Sb3YWobZBuIHaCsaV2uhHeFS/y9
BuVAdKkCLtwCMQnbCSaoniUFyz5GUmdGh6hwRpAvxTU+QzoBbFpUhldFvvAY
FgY2oNdnDEQAgLPiGRKFKwYjngjSQYQSwFd2+NAcOHUE+kFI62gGhM5khfL/
6LzcVrRnKCFA8CZXCc4vW0Fir2CxR7L5LgNbw0QLgOQcRHeawtdgMy4rFAZb
hdm2apMVuZUoAfWRnMvMHYgR1AM1iRzSRyO9zIEup6ArPJ3k0ai5TYC64UU3
MsABGBnrCe41EF2dVgGttCSU3RFEMGxcCtIQ8BxaHaTiLMSNoFH4DmITdgIV
vAWtTxQzaYgIy+GpIqRZtRRrC3dzy4yvxzTU8UsQf7QbYowEVojPTTRZROpR
0RdVgv+X5yCDLvNZBJtPMr1H/4AjCIKRiY50oqcLLPEL7SlRQWz/AFpYzbMZ
g6Ycq2HWrFVgfDY2kBNVQCEwJsyrF7BLCYjIjpwFcdPSfuQvsiWE2FgswERG
N5Omk/FoQtGdJ2fgC6IaZDQuAWluT6rARBlY6zxaLkmUZn2QEK29NndtA8ez
MAgwhwcAiy1fmmoDm8S3pTXb0sqzt2A8k0VoOPFqLWqFsnV0FzWi1KL+38v2
hjZ4s8uyOOaNEyvPAuuZhVbrKW9+a4s6ovKsdZQmGdoeQ+hUatKDjb3v9nd/
+WXHxSbOzVWBLqwHFNid+uTo4mLy8ujd8Qskr0IecqY3WVcIDHg6t1boAqzA
+Uu2PFExAzWMNVG2HwnxZlpH6NM6SWfMmzkABAwbm2VVNqhEFm3AREwzsqw7
MICf9haxSEEpkmS1Ubj4Nbi5myepYZ/KyqlGvrFD0nKjFDN5oxcHOcVCuESz
A4UCmuSHKKiyihjiTcmIInPshSAKHnoMznexSMT7Jrv9xoD3laNL8OjkzcXl
ox3+r359Sn+fH/3Pm+Pzoxf498UfJ69euT+UPHHxx9M3r140fzVvHp6enBy9
fsEvw7c6+Eo9Opn85REj9dHp2eXx6evJq0c9cqwwztEC/IAKQmkVAYeL70Ar
fX54pnefWdIFRx0Ymf/x7e43z+AfaCTwZHmWruSfgNKVQnEDZhTaiqBN42iZ
VGB37aApUc5B3wKtgmlP2JvERZ6tFiWNM6EgXkLOe8nIBMUMWgOlO+xSjaqN
Ib+KwFRLYBKieFiFDBH5Q5Abh5YFw/107wkuAh/zxdOYZ2o0YDgGYousRhks
ROaBUn9AhX0QmLlkE5FBQj8fuZ89UwV/wZDhgT4h1WFjFa1xePyzgz4ni4c4
CJxp1qKDshhfAWl3MOAHbvA2cMdB6Juuf/756AJeGZ3DRq4O9HNmN08oafqF
Y7szGGJycXF6eDxB6tX59EfQEWAJzeAXJUaNU77Oy0P936hdeSxg7LEHySSm
QFMfKPxTLyzKwsKioMrZslyFOotkD9rvhQbfzrCYQ7dFBWYBSsw5GINAyaCB
xOeeNUIJ4MrjJOLVtJdxcvkGg4Lvk0W9QD89KxfgjKIiBTuiIsnVCpT7S7xw
zjxRPamULsqR4bp7+u03e8g/aJYuTJSxQrCgKjJ3iB1pU8hEHOu294jLQ4kP
xgZS30tkgZEYkqnDzg6p4n64asG/m5ms5BiRtyJSYJEA71vXokK32RocTjGu
oTicJlSQjIH9b75FqkaD5f2SJR/bQGziG4ANo2JiqvSMi++A5WsK2IKfOEZD
aCbn3r7XACYrxN/AGgA3Jp2N2yFR3qaS3kQN2hmkCwWanVFREO0qnzhcIBYm
JGnqUCyWXkjCDtGhJUZcIA+XHO3Sl3fkHwVLulwtTROYsgCrLsCsZfD1AdRI
MKjIYSMGLFY/LjYshbZ8adVEK/l51SMqtgKhsu0whrwnisXJqxiUGRprOOoi
yqJr2TV/WKRfERpbCQZA2XmdrhTD8I4Olt4d258KsXLLeVTIcOxeuJeLYKdA
UoFma4LQaKo2EIq9IS6N88wGphZ7ULU8HgxGJ7hHRAcdwilBZWr9O4a4mQMk
IAeqm4fJOgG/wezQC7LFoZSndwMZyRFy+wIvxcyah4VIS6SjQkezGYV1OMYj
wgWjQTbkj9a2xWUsnGFdR9Z8ns3UMSswygjcvQBm581pQkuh4YlEJBsvNtWy
al5TjaHbmLD+eUGPM+MrptJzd4MNpzEkLh3ygx9onc0oBrRGLTKB+cwzKMVE
BzS+jD1LACXZIRZ2zh24BEnnoSH63FG+PKO4lChXJoku2fi+l9UEEsFWmyxO
NAtgHeiIIfVBQDUXiU6VaJcExzbCHIXn2S0iEWJjUiEDMlLJL/QolekENz8L
rZWNNp9kYB+IPcKaYIM3l6ZtTA3TAbqyqqGDni1GURPfZPkd2AgSiQOqcEGA
roe5o8RhR1nEvNDZWyegLEYo+odK1EN1F8GN492HYCGABWw0bnYZ2qwS+3Fg
lnjsUNCBYxA3ZSnmLdmX7f7rEiNyE4B0b0YZ69MsdthS9IDQXP94HpLpn45p
MAaF/8UoQiOCYpAKRCvITZHERYYIqSUrAw0teAuU6VoThuTNIGmVqqQ4Rsth
kDNPHD2qbAyhH1wSPOqTwYPqplL40Brx1xOPgN1lAdJxM1Svm9GOPq73iiRA
fqemhkP1bT+k7XyAwz4gqTyMnDJGfn4MJv6I7KERIOkX3uF7jO5lvqxT8ntq
Fycv6tSLLYITjAEoirs68z/kz5ZZqn2zNHAEwDPgA+EhkgX0cGRyJgTaNl93
WlvNWsT/7oLTEigChOFEU3Gkpd+3ssZwF59jfYI7jWKVLJE0XZEh1TMZf69Z
F/XAQuRIRjGwrzWAWuHVcWdsXK4bedJrzPteI64koJWolBBL6UZ5G6W1EVDh
dfl2xJ/mT/l+6/L5i9HuNv45aL/7EIW2/L3kB7rkZZpPo/Se7QOhHOfFjKgz
7yHQlrMYSrY1bMNyomGAtvAiQpXzbpx8EAeeC0K7ELVNKqILAlpdI6tnzApu
crJx6QAgENewencSB4iIrY/zGKTC8dnts43WyNigx4ewYHmgRT1uUaoSUkMf
NiHoSqvjhwf2jJM5MGAVRPzYRAO6/F/8ML090d3Pbs93ez3fPbVD7MLPT/Uz
/bXe19/ob/V3D/mOBvmP0Uf+j0b5hwNNbGXOm0RbSIe/a8mgAvR5n398FlhC
kJjV3uEWvpuIVOr7/DNgeWFKUBBEbmsB+mfA0nG7Bz6fFRbPeN7k86lgYX78
+UA/vkqueScsd7/zxDSdlWEC8e8fbSRefNHyCCwTFSDc8caB3t3XU5CM9gH+
XHbzmdzmjO2jlosGxnBMRmejdYXJIuB4jANDAfTLT2CTcZYPBiwwbOuPgtIM
jHEwDMjyJtN+WY1b6+lhrAP9dG+jlUlW5fHZ22fWVGgPP8QrG88xawZYO1Gb
ETaeoB0Rc6ZgEx1iH98fBlWlHbih/nCqSY9T6Z2GgAr/q5z7/g3Gsppy/2Ga
cv9zacqBgb9oyoDqfk2a8oEfgeUjR/mssHRE1P5a3f+bxcsXetkMln6dM0g0
v1m8fB56+WJxdi3O/Q0tzvVq+l/V4txvrEGsVHqYybm/ocn5AZO0bM7Bmf6/
25xocmIdlK0sOKdYVSc4tyaQG5wXMvBlJ6UVyWJIeNg0HdVzsrf2eNk7juXw
k6k6mTRycts6TG6d7HXLHLhagIufKNGBM8V1lBaEDxsKb50/Eqtw/gbFnTs7
ofgcYJnHfEZ3wsF9f1UUAfZDiH5yKM/nbb1s8FUaXZeOU2M8M3LVH5wBVPXF
DD1uVfSwO3AMD77CQ+H2KjHU27MQyvLhHG2b04MHUlIBsVHA02Zdc7q4K2ax
kCj7e8/JhTuy2g6Bl3z/Mjgw6T1b8U698NAMBAAl/20AuechbXrK7U43LTGH
RxZ82hGkUnux17/qv209BmBHyyLJi5Ekf2+Hp7mds8JuIrlDEtCJn0cQepDq
Q9fcPt6ic9L1p/t/tkc15j2mGHtJUB3WwryINJXKA0qFKpU866haZt8s2D60
QygL4nzJ/rJgbqMROTM1wlxFe8Dvo6DN296x13qZoPrfe5hMcGRyn0hwJ0By
yNPD+XZOl4nnncxHmRTQz/xU/YYWQ24FqYERiaIvqyMKDzfiaEk1ApRsnFwR
MaCgYVJ40Na74iA6JfYIQQUnsouoipk6ZY42nXWpfIvzHy0xqw4xb4/18ZU/
ptSG0lw7eKALS9s41QLNialdROSfz0j2wk7I97hxyuK8H+UITA/aaduKKDZN
LSLV6UVFUhp3zORqmfo2LphKOWHvDrWL5PoaKSHyUi+oQMswVJI98yB5tSNV
A0LbrqyowYubVkBWrTNgKXiK9FVUp5JvRbXZWBUBf1JZmhQBUqStxDxX3Brl
skJdnknfhOGhc1NSGqJraq7w+BcGxpwLIUS/JkUEISPOS9uwvOzVktkyF8p2
cUPpC/s20XDUx/jWhiVTyeUos9ETZStOiqHJsPgjrHoh9DAEjlsBCLEzuB5e
ORheTw7/W3QlvNYDCiU9soOCWMF0PU/NcfoGotuW7EiqZTA+Zyot02jFv2JJ
d5A+1aRh4xIZbx1Q+MzfL8m36cgUMOWt8It4g0SKdbklLpOixA4lbL2MKH3F
bJBO4Rn5Mol/MmxDw+7AGdPrI7+yjcrouC4tDzh1a9CVkkq/PDOqm5rSoveO
DY8CmRNR2lkrqmW4uQfvz1h5WFZRECofMA/6bUlXJg+veiWlVc7NAQR9IeaU
j7mx/owZJr/xBBNH3p8iw2RvKMNEZulLMZHsb5p1gyiQVKD4WNyARjmxjV8Z
ThNxZ0JDC5ARPFkwbhJCcM/s2DTM0OEUD5J4Wq+VMkJ5Wj3ZIfes8OfHb5+9
wwffTQ4vj98e/fLwhJFhYac+ImNEB+dgqucc7OOPwT7BKdgnCcYGsdjX9WL0
/CXWWLiP93vfERjHYj89JN5n00D154fEfg7u+Z0g+eqrjxrkq68+GSS/sd0Z
Qiyq73d/PD17J6bUwIcR+1khuTw+OXr3dvLqzdHF8NZ8UkiGdockXn8VzOfY
nc6JSijgPyRvhyU8HqM44eQdevwBRZYU2QzGpMn5BvXUc2jyh8GjEjVUhOVO
BTjQDUNMhoum0Na9i0rfXXamY6PNVZMAvdZiXRP2UJ3ilFMvZ3yonkyfTP7C
teHU1Awzn1tcdKAPU7Qtnu60Dh7E4dt78jWX/p6jbxUbCkGSIQ1jeDWIGCxb
LtPE2CYN7Ay0HUuuJr0KFfAg+K5jUoE1KOBylViueTgi8/H3oDhxT4nQLETo
JXjMmQdr/Poha+wO84HLXKJXPlu3TG1bG6D3jgZJ1wBa41LCkoelAJW0O3YM
CuQCSxNMfLIX5YzLdvagkjlqvtFqKHAh7T72x7vjXVwp+yVcLMe7ZifDPxFl
MXcF4TJD8SSDqsgh/OD8LU8uQE5/zAh4pCdL636Ldb/fYt04cevBFutGmVtf
LFZPlzV/frFY5fPFYm0+XyzW7ufXY7Fu+uHd+chBPj8kJMA3MMB/kzj5aDrp
+hP7a/yJjbKyvvgTv1Z/4tfuTuxZd2L/g92Jz+9N3L/KT+FNDIg035vY/9fz
JsCXcB2XOA+Pj5XPMJMHYflBOsX+3E3wAYp4zse+A/XJeBQsaRjYb3eOLXLn
0U1zFoS9SFNDh3s9DUJcj19GV/N6UjaNlfV6uWET1GhDGUdr2kX0ZElN86pp
bqjC5oZy5Fb2toSwbdvCvpLwTjXPZ73dm6QbZYUXBwBx3EZZJQd6dHVDig3W
8GaGmG5w2HKkmSyWOSEBU8QQ9Cj13nA9A7eb/ohNx8EgX9E21W5OKxsa50MY
v+sMtUHGJmFlVSQx8ufJ5RtVmL/XScESwmvIyqA44GEzLPg7LdRZIKj79Xts
3aBaoOA8DE6+xLP5vN1/z0j/fBwZm8Zx+38qyu8sv2dm25zGQ+cw+Io7rQmo
bawRqEr9mZrdd3PoggamrmVWT1IMLKmsOYO0fdjcZNEhu5VAu6V0fQtzZwAS
7W1OSXShqMGsiKPbPKFGOisAPb5BeUfJAXyUPSvy5dK4/eTlWs7DscvkJ2Pz
iXwMsOi2uKUcC3sontmT+54ml1XTpXrshOneeL9hF2mXaKUud32TfvLcUaui
1pdUmo5ZeSqSFEyAnGT5VRFxGxGgIFwf5gjRyjlLLbG7Kj1SZD/VDK/kABZx
wofbSze9O7HpSEICkTr/EfdwUhluUYotpIGxlTu/9wa0k9gsG8EkJ9KEY5ZM
6kQXCJbkvTDIdMJJshlTn1ptRvsZzm2HaicpYMQJoe/RFHrT9gFeRhglIII2
IxugkWJDaW5D/XYwiaWYrU2cZc2hmrlt6p+hZnwuOdgBYW/MWJuNy5140UBw
KWFZk4ghScMuq1KpN0tbiXDLaUQ9iXnr+lN1tFlLQMRzE9+UmJjHmapLRlNZ
T0eSmtokXN2fmAZqjzuZmZIweHxl/25N6/jLTQ0KGysyvXRL3h7JQxtMuLxk
s1HfAnHN/GzNRhre14kqPP13yd73pPz2iUmUti6zUmGiAUijB+Vct4wIC4zq
GpXzaMY5nms777SSNm0Gu5+0CZ4hLGKH5RawPWb1DNIa2JWU/dPaT2muB+oB
ZJECNfAVWu+brhz7H2Mz5jXNEvJCdX5tKuPIRWXMG9ZCrYwcay8b29QDyK1H
Ig3yW4BTySHcnOO8yxialD1E0BaqFr4UAojYtVm3UJeSfCqXTdh7CjbO4hdf
hAytIE9a0Ab8Jqk0XtFR41pkLcs49JBdNzBOzUkKIHXWKKXIkqSsuBH+UFaZ
JeqhUIFLx5TKFWpLSF4JCmdK1yTkIu+BdsRHf8yTDHQ1Vyi5siTvfVf9EsJP
bcHJDEiKgirAfL+EANMg3iPsBEYJoF69gWvX5CoO1tHxmjoyZQFuOWR0WGV9
8U2EWKmaJnXpyi61ybKnm1boEiozk0xR1IdePVK37Z6SBFgfa2y3lMPM4JFM
I+TUGpdpc2nbFFioDyqw0K0Ci81rYwaFbVNdoR5QXRHGP6TCgmfwWgd+aIVF
0zHsB6ypkHZoVFHhJD/LJ5RCNmOaol5AjXyFyoAI3MwmsBm7aEXMkqsrU/Bl
Z5JFavmIbmoIMs39GwuYYsU4gRWWKNKkSqLR7w12vHoGZ764yVX/5BO5NSy4
f8LO7xksVFPHffakgylxBgdygqRqXxj0xV36ai5C+1XqAii+tXGmr0gR5SKl
AxcCOMw07nTQyJBKs9ChclVZWtzRHishALvJEg6xGJgJWsyEjRmPmv36hsJg
J6PGWhgsph80GVpKUiyGgUgXhUdclMvH1S9iSyDhxFY22UqLLa9Gs30XzXZo
uFAhA2lX2yCNfpetXuSzpndvb4kd+EpNOPHZ+ClGbbxwIlsYeC9Q721iJTc5
xxn7yl7wieY6olb1b0+5KiAA74TJM3cUSPrgAi95OH93eXRy9mpyeRTUYNnc
8TCkwaQNX2SjIbiGqJ5dWxXWCA4NIuFDtEPYMXZhMKsoUVRhwU/R8gaRt6le
wt4a4sqKQ2/Qc37Q1lHNNSw0OvuDK/PwLqLSmLPXPVif8O9dlddcftWucgiw
tN7NB8ZIixHWeQBTtKQsXy0mzkcTjg2CwlS00nNLHrbB9e5D6pFDYj86Qehu
VWi1JR+rY5BXIH92/MW3HiqplLaDrpYnZHsKD/ZX7ZpE97RNVbwJhu9B6Nux
cXPfgX+8ziKuL6i/rksjtoGkojDhVF+pkDDa8JRmje7zimI+8Ojhsg/l61Qt
oM3dnNQ4RbxEJZ2CqwpEJmx8uSMHepYaew9/dgIxtxngGu0tnt85ez1um1wG
RvcYBHXb63dvxx6aWKQK6zsH8iEFP1xaHVT49HeED1qBeue0PVYZIt8v3yOl
IZbUzLtusqekDzcb5BA287aVca7ezR2leNYSbYyU+7i6tuDeAOVaL7hrpqau
ypD8w08bJ1gjCILQHMwoih6FV7EAwcbd0Jd0q413k6aTZmE5ZdsIpUeG2sjj
piZXGK7GeFJTL52ptYKVcQdkzIdVP/TJVU9DOE+cvQ9az8wtl2MHbMqYJl6u
bKGiV/m0y26Qsx682jauanfktU4YbsZOsK49nq7ntLpnRv+pD5hND00lVM1a
xZUPY/i5HeQCEnatLSwhl02k5S6v0xkJPtVcZkbyIdjbMriez57BzJt7WElX
Z/lQVTFyNYxqyKAEJD5lJPYnBQU6qm0H9uJaDUpkGUywsukeP2Pwjs5PvfmE
GPGWGIr2+Cb0s/aJPOb+uF700TQn/7mxy0uJC8hxdegROVavuF2OsHrD5JGt
N/YyAJT6moF+gLhttKUvdG04B6dO5CZs8bDxDtKPFbEw6r1SduLoSi4G76AA
HSfwzzyB5I4BbdRdsa4gavZF8REG87zjlEnXYAwCTU6klnWM09NF2CKvAnqX
azl96zIMjYmrmywWZobCGIbx7gBUPXcAhvcytCJwzb0M7I7K+6QHu3Wc5Jcp
75mW8R41j/UlRLSB7EvrkfYd6rF+7q4JP5RrwvlieTIItizjbW9yE1dTyyu6
M6bMIr5YRomUIB94d3dKH/IcsGb690/Qkd4Vh80GomMfIi50R59RLgbBtUr4
hyiHYmgRcrKzYL39EVo33q17nNy048TD0/HuE6KhOsNzqGzE8FuzTtGF3xzZ
J1Oam5X4Dj0Ka4muUAf/BO+Hroj+fZlCiIdZgWNgXYfS9aK5XNC/RMueSwJj
UEzenTq7W98u53XpLjAL7nqma4q84Kp3/4blmR1dpsn1HF1dihqGl8Kgxpli
+IzyVRRIx7pq5IG7C9pmWWDEsZXvZ53sD0iFQFJv4MV9cefYqn2fBNKAyKih
3AKxrhtuwcMSdit6hxMa9o1vL5hrxS1tDKb01NS3JFfLHI/8ErrgNwHyFapY
RFkixcuRtAtrn2v3BGLUQCCGoIatbxwSuoUXfCBsNoEcBGTQ3P0mdEijuUSJ
snMrmcP9f8LawNbDs6+KCa8q0KMsK7HqqWrD6iaM38NEt3yygktp3QRFzELt
SYAKjiwRe4Dg3tpbaaxuQtq9Luzd9lEN3wFaY/wCUEexVncxpdNvwtffPPsG
hJBsuHi7Y31ayc3QHrfpBV+jSjH/MBmLL+P8L/ji6+/26Au6oB1GWxH/Hk9e
Tzq8S1+GF+w8eulu1ZvxhZqjs4EbNfUWXTq4rTynJSpg+/H+8EeA+2vAXbFi
VfWo3YLgEZ3724f4okBObFV2g90IImXcwxi/ohsfbZoEaIreNgd4Adm6jiBD
7KwCR0DKfKQHwmsk8KEPaDEM+8dkX0lzBNsiofczsh98gS7m0OExjr8m/Hji
376yp1sGaOud5pU9WovC62L964nkjlgk27woxXZPkxvpWBJlN3qSmvcRGcCn
N3mWJTf57Y5+lUd6gl/CfBn+s9bP0XwpdtRRAYbaaTnNiwyk9kvYuhw27gS8
r5vVjj5Bs+dQovt4V31i+MZYd9UU/usWEI5encLQSXNJk7dP9nphDqYA7JzV
joh5ncTzHDSivgT/Ev49KYB2Iv2apT+3nTwC2k8PNJB/9n1Ev49hKh7i/wC5
g2O6TIsAAA==
</rfc> </rfc>
 End of changes. 107 change blocks. 
1149 lines changed or deleted 726 lines changed or added

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