<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 --> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?> "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
     docName="draft-ietf-mpls-summary-frr-rsvpte-09" number="8796"
     category="std" updates="4090"> updates="4090" obsoletes="" submissionType="IETF"
     consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.41.0 -->
  <front>

    <title abbrev="RSVP-TE Summary FRR">RSVP-TE Summary Fast Reroute
    Extensions for LSP Label Switched Path (LSP) Tunnels</title>

  <seriesInfo name="RFC" value="8796"/>
    <author initials="M." surname="Taillon" fullname="Mike Taillon">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>mtaillon@cisco.com</email>
      </address>
    </author>
    <author initials="T." surname="Saad" fullname="Tarek Saad" role="editor">
      <organization>Juniper Networks</organization>
      <address>
        <email>tsaad@juniper.net</email>
      </address>
    </author>
    <author initials="R." surname="Gandhi" fullname="Rakesh Gandhi">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>rgandhi@cisco.com</email>
      </address>
    </author>
    <author initials="A." surname="Deshmukh" fullname="Abhishek Deshmukh">
      <organization>Juniper Networks</organization>
      <address>
        <email>adeshmukh@juniper.net</email>
      </address>
    </author>
    <author initials="M." surname="Jork" fullname="Markus Jork">
      <organization>128 Technology</organization>
      <address>
        <email>mjork@128technology.com</email>
      </address>
    </author>
    <author initials="V.P." initials="V." surname="Beeram" fullname="Vishnu Pavan Beeram">
      <organization>Juniper Networks</organization>
      <address>
        <email>vbeeram@juniper.net</email>
      </address>
    </author>

    <date year="2020" month="March" day="17"/>

    <workgroup>MPLS Working Group</workgroup>
    <keyword>Internet-Draft</keyword> month="July" year="2020"/>

    <abstract>
      <t>This document updates RFC 4090 for the Resource Reservation Protocol (RSVP)
Traffic-Engineering
Traffic Engineering (TE) procedures defined for facility
backup protection. The updates include extensions that reduce the amount of
signaling and processing that occurs during Fast Reroute (FRR), and
subsequently, improves (FRR); as a result,
scalability when undergoing FRR convergence after a link or node failure. failure is
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
number of protected Label Switched Paths (LSPs) traversing between them when
facility bypass FRR protection is used. The signaling extensions are fully
backwards compatible with nodes that do not support them.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Fast Reroute (FRR) procedures defined in <xref target="RFC4090"/> target="RFC4090" format="default"/> describe the
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
event of a TE link or node failure. Such signaling procedures are performed
individually for each affected protected LSP. This may eventually lead to
control plane
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
is exacerbated when the failure affects a large number of protected LSPs that
traverse the same PLR and MP nodes.</t>
      <t>For example, in a large-scale deployment of RSVP-TE LSPs deployment, LSPs, a single Label Switched
 Switching Router (LSR) acting as a PLR node may host tens of thousands of protected
RSVP-TE LSPs egressing the same protected link, 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
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
bypass tunnel(s) in one direction, direction and (when acting as an MP node) becomes busy
merging RSVP states from signaling received over bypass tunnels for LSP(s) one or
more LSPs in
the reverse direction. Subsequently, the head-end Label Edge Routers (LERs)
that are notified of the local repair at any downstream LSR LSRs will attempt to
(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
control plane becomes overwhelmed by (1)&nbsp;by the amount of FRR RSVP-TE processing
overhead following the link or node failure, failure and due (2)&nbsp;due to other control plane
protocol(s) (e.g. the control-plane
protocols (e.g., IGP) that undergo convergence on the same node at the
same time too.</t> time.</t>
      <t>Today, each protected RSVP-TE LSP is signaled individually over the bypass
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
assignment to the MP, such that upon failure, the signaling over the bypass
tunnel happens on one or more bypass tunnel group(s). New extensions are defined in this groups. This document to update defines new
extensions that</t>

<ol>
<li>update the procedures defined in <xref target="RFC4090"/> target="RFC4090" format="default"/> for facility backup
protection
protection, to enable the MP node to become aware of the PLR node’s node's bypass
tunnel assignment group(s) and to allow group or groups.</li>
<li>allow FRR procedures between the PLR and
the MP nodes to be signaled and processed on per bypass one or more per-bypass tunnel group(s).</t>
groups.</li>
</ol>
      <t>As defined in <xref target="RFC2961"/>, Summary Refresh target="RFC2961" format="default"/>, summary refresh procedures use MESSAGE_ID to
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
MESSAGE_ID(s) to be exchanged on per bypass one or more per-bypass tunnel assignment group, groups and
continue to
use Summary Refresh summary refresh procedures while reducing the amount of messaging that occurs
after rerouting signaling over the bypass tunnel post FRR.</t> post-FRR.</t>
    </section>
    <section anchor="conventions-used-in-this-document" title="Conventions numbered="true" toc="default">
      <name>Conventions Used in This Document"> Document</name>
      <section anchor="terminology" title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>
       <t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,
“MAY”, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and “OPTIONAL” "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
      </section>
      <section anchor="acronyms-and-abbreviations" title="Acronyms numbered="true" toc="default">
        <name>Acronyms and Abbreviations">

<t>The reader Abbreviations</name>
        <t>It is assumed to be that the reader is familiar with the terms and abbreviations used in
<xref target="RFC3209"/> target="RFC3209" format="default"/> and <xref target="RFC4090"/>.</t> target="RFC4090" format="default"/>.</t>
        <t>The following abbreviations are also used in this document:</t>

<t><list style='empty'>
  <t>LSR: Label

        <dl newline="false" spacing="normal">
          <dt>LSR:</dt><dd>Label Switching Router</t>
</list></t>

<t><list style='empty'>
  <t>LER: Label Router</dd>
          <dt>LER:</dt><dd>Label Edge Router</t>
</list></t>

<t><list style='empty'>
  <t>MPLS: Multiprotocol Label Switching</t>
</list></t>

<t><list style='empty'>
  <t>LSP: Router</dd>
          <dt>MPLS:</dt><dd>Multiprotocol Label Switching</dd>
          <dt>LSP:</dt><dd>Label Switched Path</t>
</list></t>

<t><list style='empty'>
  <t>MP: Merge Path</dd>
          <dt>MP:</dt><dd>Merge Point node as defined in <xref target="RFC4090"/></t>
</list></t>

<t><list style='empty'>
  <t>PLR: Point target="RFC4090" format="default"/></dd>
          <dt>PLR:</dt><dd>Point of Local Repair node as defined in <xref target="RFC4090"/></t>
</list></t>

<t><list style='empty'>
  <t>FRR: Fast target="RFC4090" format="default"/></dd>
          <dt>FRR:</dt><dd>Fast Reroute as defined in <xref target="RFC4090"/></t>
</list></t>

<t><list style='empty'>
  <t>B-SFRR-Ready: Bypass target="RFC4090" format="default"/></dd>
          <dt>B-SFRR-Ready:</dt><dd>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'>
  <t>B-SFRR-Active: Bypass tunnel</dd>
          <dt>B-SFRR-Active:</dt><dd>Bypass Summary FRR Active Extended ASSOCIATION
object.  Used to notify the MP node that one or more groups of
protected LSP(s) LSPs have been rerouted over the associated bypass tunnel.</t>
</list></t>

<t><list style='empty'>
  <t>MTU: Maximum transmission unit.</t>
</list></t> tunnel</dd>
          <dt>MTU:</dt><dd>Maximum Transmission Unit</dd>
        </dl>
      </section>
    </section>
    <section anchor="extensions-for-summary-frr-signaling" title="Extensions numbered="true"
   toc="default">
      <name>Extensions for Summary FRR Signaling"> Signaling</name>
      <t>The RSVP ASSOCIATION object is defined in <xref target="RFC4872"/> target="RFC4872" format="default"/> as a means to associate
LSPs with each other. For example, in the context of one or more GMPLS-controlled LSP(s), LSPs,
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="RFC6780"/> target="RFC6780" format="default"/>
to expand on the possible usage of the ASSOCIATION object and generalize the
definition of the Extended Association ID field.</t>
      <t>This document defines the use of the Extended ASSOCIATION object to carry the
Summary FRR information and associate the protected LSP(s) LSP or LSPs with the bypass
tunnel that protects them. Two new Association Types for the Extended
ASSOCIATION object, and new Extended Association IDs IDs, are proposed defined in this
document to describe the Bypass Summary FRR Ready (B-SFRR-Ready) and the Bypass
Summary FRR Active (B-SFRR-Active) associations.</t> (B&nbhy;SFRR-Active) associations.
</t>
      <t>The PLR node creates and manages the Summary FRR LSP groups (identified by
Bypass_Group_Identifiers) and shares the group identifier(s) identifiers with the MP via
signaling.</t>
      <t>A PLR node SHOULD <bcp14>SHOULD</bcp14> assign the same Bypass_Group_Identifier to all
protected LSPs provided that the protected LSPs:</t>

<t><list style="symbols">
  <t>share
      <ul spacing="normal">
        <li>share the same outgoing protected interface,</t>
  <t>are interface,</li>
        <li>are protected by the same bypass tunnel, and</t>
  <t>are and</li>
        <li>are assigned the same tunnel sender address that is used for
backup path identification after FRR as described in <xref target="RFC4090"/>.</t>
</list></t> target="RFC4090" format="default"/>.</li>
      </ul>
      <t>This minimizes the number of bypass tunnel SFRR groups, Summary FRR groups and optimizes the
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 ASSOCIATION
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,
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
the received B-SFRR-Ready Extended Association ID to refresh and merge the
protected LSP Path state after FRR occurs.</t>
      <t>An MP node that supports Summary FRR procedures adds the B-SFRR-Ready Extended
ASSOCIATION object and respective Extended Association ID in the RSVP Resv
message of the protected LSP to acknowledge the PLR’s PLR's bypass tunnel assignment, assignment
and provide the MESSAGE_ID object that the MP node will use to refresh the
protected LSP Resv state after FRR occurs.</t>
      <t>The MP maintains the PLR node group assignments learned from signaling, signaling and
acknowledges the group assignments to the PLR node via signaling. Once the PLR
node receives the group assignment acknowledgment from the MP, the FRR
signaling can proceed based on Summary FRR procedures as described in this
document.</t>
      <t>The B-SFRR-Active Extended ASSOCIATION object with Extended Association ID is
sent by the PLR node after activating the Summary FRR procedures. The
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
one or more groups of protected LSPs protected by the bypass tunnel are now
being rerouted over the bypass tunnel.</t>
      <section anchor="ext-assoc-obj" title="B-SFRR-Ready anchor="sfrr-bypass-ready" numbered="true" toc="default">
        <name>B-SFRR-Ready Extended ASSOCIATION Object"> Object</name>
        <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
Summary FRR procedures are enabled.</t>
        <t>The Association Type, Association ID, and Association Source MUST <bcp14>MUST</bcp14> be set as
defined in <xref target="RFC4872"/> target="RFC4872" format="default"/> for the ASSOCIATION Object.
        object. More specifically:</t>

<t>Association Source:</t>

<figure><artwork><![CDATA[
  The
    <dl newline="true" spacing="normal">
        <dt>Association Source:</dt>
         <dd>The Association Source is set to an address of the PLR node.
]]></artwork></figure>

<t>Association Type:</t>

<figure><artwork><![CDATA[
  A node.</dd>
        <dt>Association Type:</dt>
         <dd>A new Association Type is defined for B-SFRR-Ready as follows:

  Value      Type
  -------    ------
  (TBD-1)    Bypass
        follows:</dd>
    </dl>
<table anchor="tab-1">
  <name>The B-SFRR-Ready Association Type</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Type</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>5</td>
      <td>Bypass Summary FRR Ready Association (B-SFRR-Ready)
]]></artwork></figure> (B-SFRR-Ready)</td>
    </tr>
  </tbody>
</table>
        <t>The Extended ASSOCIATION object’s object's Global Association Source MUST <bcp14>MUST</bcp14> be set
according to the rules defined in <xref target="RFC6780"/>.</t> target="RFC6780" format="default"/>.</t>
        <t>The B-SFRR-Ready Extended ASSOCIATION Association ID is populated by the PLR node when
performing Bypass Summary FRR Ready association for a protected LSP.  The rules
governing its population are described in the subsequent sections.</t>
        <section anchor="ipv4-b-sfrr-ready-extended-association-id" title="IPv4 numbered="true" toc="default">
          <name>IPv4 B-SFRR-Ready Extended ASSOCIATION ID"> Association ID</name>
          <t>The IPv4 Extended ASSOCIATION Association ID for the B-SFRR-Ready association
type Association
Type is carried inside the IPv4 Extended ASSOCIATION object and has
the following format:</t>
          <figure title="The anchor="fig_IPv4_Extended_Association_ID">
            <name>The IPv4 Extended ASSOCIATION Association ID for B-SFRR-Ready" anchor="fig_IPv4_Extended_Association_ID"><artwork><![CDATA[ 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><artwork><![CDATA[
  Bypass_Tunnel_ID: 16 bits

        The
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure>

    <dl newline="false" spacing="normal">

    <dt>Bypass_Tunnel_ID:</dt><dd><t>16 bits</t>
     <t>The bypass tunnel identifier.

  Reserved: 16 bits

        Reserved identifier.</t></dd>

    <dt>Reserved:</dt><dd><t>16 bits</t>
     <t>Reserved for future use. MUST <bcp14>MUST</bcp14> be set to zero when
     sending and ignored on receipt.

  Bypass_Source_IPv4_Address: 32 bits

        The receipt.</t></dd>

    <dt>Bypass_Source_IPv4_Address:</dt><dd><t>32 bits</t>
     <t>The bypass tunnel source IPV4 address.

  Bypass_Destination_IPv4_Address: 32 bits

        The IPv4 address.</t></dd>

    <dt>Bypass_Destination_IPv4_Address:</dt><dd><t>32 bits</t>
      <t>The bypass tunnel destination IPV4 address.

  Bypass_Group_Identifier: 32 bits

        The IPv4 address.</t></dd>

    <dt>Bypass_Group_Identifier:</dt><dd><t>32 bits</t>
    <t>The bypass tunnel group identifier that is assigned to the
        LSP.

  MESSAGE_ID

        A
       LSP.</t></dd>

    <dt>MESSAGE_ID:</dt><dd>A MESSAGE_ID object as defined by [RFC2961].
]]></artwork></figure>
<xref target="RFC2961"/>.</dd>
</dl>
        </section>
        <section anchor="ipv6-b-sfrr-ready-extended-association-id" title="IPv6 numbered="true" toc="default">
          <name>IPv6 B-SFRR-Ready Extended ASSOCIATION ID"> Association ID</name>
          <t>The IPv6 Extended ASSOCIATION Association ID for the B-SFRR-Ready association
type Association
Type is carried inside the IPv6 Extended ASSOCIATION object and has
the following format:</t>
          <figure title="The anchor="fig_IPv6_Extended_Association_ID">
            <name>The IPv6 Extended ASSOCIATION Association ID for B-SFRR-Ready" anchor="fig_IPv6_Extended_Association_ID"><artwork><![CDATA[ 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><artwork><![CDATA[
  Bypass_Tunnel_ID: 16 bits

        The
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure>

    <dl newline="false" spacing="normal">
     <dt>Bypass_Tunnel_ID:</dt><dd><t>16 bits</t>
        <t>The bypass tunnel identifier.

  Reserved: 16 bits

        Reserved identifier.</t></dd>

     <dt>Reserved:</dt><dd><t>16 bits</t>
        <t>Reserved for future use. MUST <bcp14>MUST</bcp14> be set to zero when sending
        and ignored on receipt.

  Bypass_Source_IPv6_Address: 128 bits

        The receipt.</t></dd>

     <dt>Bypass_Source_IPv6_Address:</dt><dd><t>128 bits</t>
        <t>The bypass tunnel source IPV6 address.

  Bypass_Destination_IPv6_Address: 128 bits

        The IPv6 address.</t></dd>

     <dt>Bypass_Destination_IPv6_Address:</dt><dd><t>128 bits</t>
        <t>The bypass tunnel destination IPV6 address.

  Bypass_Group_Identifier: 32 bits

        The IPv6 address.</t></dd>

     <dt>Bypass_Group_Identifier:</dt><dd><t>32 bits</t>
        <t>The bypass tunnel group identifier that is assigned to the
        LSP.

  MESSAGE_ID

        A
        LSP.</t></dd>

    <dt>MESSAGE_ID:</dt>
     <dd>A MESSAGE_ID object as defined by [RFC2961].
]]></artwork></figure> <xref target="RFC2961"/>.</dd>
</dl>
        </section>
        <section anchor="processing-rules-for-b-sfrr-ready-extended-association-object" title="Processing numbered="true" toc="default">
          <name>Processing Rules for B-SFRR-Ready Extended ASSOCIATION Object"> Object</name>
          <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 LSPs that share the same bypass tunnel, traverse the same egress link link,
and are not already rerouted. The PLR node MUST <bcp14>MUST</bcp14> generate a MESSAGE_ID object
with Epoch and Message_Identifier set according to <xref target="RFC2961"/>. target="RFC2961" format="default"/>. The MESSAGE_ID
object flags MUST Flags <bcp14>MUST</bcp14> be cleared when transmitted by the PLR node and ignored
when received at the MP node.</t>
          <t>A PLR node MUST <bcp14>MUST</bcp14> generate a new Message_Identifier each time the contents of the
B-SFRR-Ready Extended ASSOCIATION Association ID changes (e.g. change (e.g., when the PLR node
changes the bypass tunnel assignment).</t>
          <t>A PLR node notifies the MP node of the bypass tunnel assignment via adding a
B-SFRR-Ready Extended ASSOCIATION object and Extended Association ID in the RSVP Path
message for the protected LSP LSP, using the procedures described in <xref target="sig-prior-failure"> target="sig-prior-failure" format="default"> </xref>.</t>
          <t>An MP node acknowledges the assignment to the PLR node by signaling the B-SFRR-Ready
Extended ASSOCIATION object and Extended Association ID within the RSVP Resv message of
the protected LSP. With the exception of the MESSAGE_ID objects, object, all other
fields
of from the received in the B-SFRR-Ready Extended ASSOCIATION Association ID in the RSVP Path
message are copied into the B-SFRR-Ready Extended ASSOCIATION Association ID to be added in
the Resv message.
 The MESSAGE_ID object is set according to <xref target="RFC2961"/>. target="RFC2961" format="default"/>.
The MESSAGE_ID object flags MUST Flags <bcp14>MUST</bcp14> be cleared when transmitted by the MP node and ignored
when received at the PLR node. A new Message_Identifier MUST <bcp14>MUST</bcp14> be used to acknowledge an
updated PLR node’s node's assignment.</t>
          <t>A PLR node considers the protected LSP as Summary FRR capable only if all the
fields in the B-SFRR-Ready Extended ASSOCIATION Association ID that are sent in the RSVP
Path message match the fields received in the RSVP Resv message (with the exception
of the MESSAGE_ID). If the fields do not match, match or if the B-SFRR-Ready Extended
ASSOCIATION object is absent in a subsequent refresh, the PLR node MUST <bcp14>MUST</bcp14>
consider the protected LSP as not Summary FRR capable.</t>
          <t>A race condition may arise for a previously Summary FRR capable FRR-capable protected LSP
when the MP node triggers a refresh that does not contain the B-SFRR-Ready
Extended ASSOCIATION object, while at the same time, time the PLR triggers Summary
FRR procedures due to a fault occurring concurrently. In this case, it is
possible that the PLR triggers Summary FRR procedurees procedures on the protected LSP
before it can receive and process the refresh from the MP node. As a result,
the MP will receive a an Srefresh with a Message_Identifier that is not associated
with any state. As per <xref target="RFC2961"/>, target="RFC2961" format="default"/>, this results
in the MP generating an Srefresh NACK for this Message_Identifier and sending it back to the PLR. The
PLR processes the Srefresh NACK and NACK, replays the full Path state associated with
the Message_Identifier, and subsequently recovering recovers from this condition.</t>
        </section>
      </section>
      <section anchor="sfrr-bypass-active" title="B-SFRR-Active numbered="true" toc="default">
        <name>B-SFRR-Active Extended ASSOCIATION Object"> Object</name>
        <t>The Extended ASSOCIATION object for the B-SFRR-Active association type Association Type is populated
by a PLR node to indicate to the MP node (bypass (the bypass tunnel destination) that one
or more groups of Summary FRR FRR&nbhy;capable protected LSPs that are being protected by the
bypass tunnel are being rerouted over the bypass tunnel.</t>
        <t>The B-SFRR-Active Extended ASSOCIATION object is carried in the RSVP Path
message of the bypass tunnel and signaled downstream towards the MP (bypass (the bypass tunnel
destination).</t>
        <t>The Association Type, Association ID, and Association Source MUST <bcp14>MUST</bcp14> be set as
defined in <xref target="RFC4872"/> target="RFC4872" format="default"/> for the ASSOCIATION Object. object. More specifically:</t>

<t>Association Source:</t>

<figure><artwork><![CDATA[
  The

      <dl newline="true" spacing="normal">
        <dt>Association Source:</dt>
         <dd>The Association Source is set to an address of the PLR node.
]]></artwork></figure>

<t>Association Type:</t>

<figure><artwork><![CDATA[
  A node.</dd>
        <dt>Association Type:</dt>
         <dd>A new Association Type is defined for B-SFRR-Active as follows:

  Value      Type
  -------    ------
  (TBD-2)    Bypass follows:</dd>
      </dl>
<table anchor="tab-2">
  <name>The B-SFRR-Active Association Type</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Type</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>6</td>
      <td>Bypass Summary FRR Active Association (B-SFRR-Active)
]]></artwork></figure>

<t>Extended ASSOCIATION (B-SFRR-Active)</td>
    </tr>
  </tbody>
</table>

        <dl newline="true" spacing="normal">
          <dt>Extended Association ID for B-SFRR-Active:</t>

<figure><artwork><![CDATA[
  The B-SFRR-Active:</dt>
           <dd>The B-SFRR-Active Extended ASSOCIATION Association ID is
  populated by the PLR node for the Bypass Summary FRR Active
  association. The rules to populate the Extended ASSOCIATION Association ID
  in this case are described below.
]]></artwork></figure> below.</dd>
        </dl>
        <section anchor="V4_SFRR_ACTIVE" title="IPv4 numbered="true" toc="default">
          <name>IPv4 B-SFRR-Active Extended ASSOCIATION ID"> Association ID</name>
          <t>The IPv4 Extended ASSOCIATION Association ID for the B-SFRR-Active association type Association Type is
carried inside the IPv4 Extended ASSOCIATION object and has the following
format:</t>
          <figure title="The anchor="fig_IPv4_SFRR_ACTIVE">
            <name>The IPv4 Extended ASSOCIATION Association ID for B-SFRR-Active" anchor="fig_IPV4_SFRR_ACTIVE"><artwork><![CDATA[ B-SFRR-Active</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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Num-BGIDs          |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Bypass_Group_Identifier                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               :                               |
   //                              :                              //
   |                               :                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Bypass_Group_Identifier                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                      RSVP_HOP_Object                        //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                      TIME_VALUES                            //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       IPv4 tunnel sender address              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork></figure>

<t>Num-BGIDs: 16
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure>

        <dl newline="false" spacing="normal">
          <dt>Num-BGIDs:</dt><dd><t>16 bits</t>

<t><list style='empty'>
           <t>Number of Bypass_Group_Identifier fields.</t>
</list></t>

<t>Reserved: 16 fields.</t></dd>
          <dt>Reserved:</dt><dd><t>16 bits</t>

<t><list style='empty'>
           <t>Reserved for future use.</t>
</list></t>

<t>Bypass_Group_Identifier: 32 use.</t></dd>
          <dt>Bypass_Group_Identifier:</dt><dd><t>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
Association ID. One or more Bypass_Group_Identifiers MAY <bcp14>MAY</bcp14> be included.</t>
</list></t>

<t>RSVP_HOP_Object: Class included.</t></dd>
          <dt>RSVP_HOP_Object:</dt><dd><t>Class 3, as defined by <xref target="RFC2205"/></t>

<t><list style='empty'>
          target="RFC2205" format="default"/></t>
    <t>Replacement RSVP HOP RSVP_HOP object to be applied to all LSPs associated
with each of the following Bypass_Group_Identifiers. This corresponds
to C-Type = 1 for IPv4 RSVP HOP.</t>
</list></t>

<t>TIME_VALUES object: Class RSVP_HOP.</t>
</dd>
          <dt>TIME_VALUES object:</dt><dd><t>Class 5, as defined by <xref target="RFC2205"/></t>

<t><list style='empty'> target="RFC2205" format="default"/></t>
           <t>Replacement TIME_VALUES object to be applied to all LSPs associated
with each of the preceding Bypass_Group_Identifiers after receiving
the B-SFRR-Active Extended ASSOCIATION Object.</t>
</list></t>

<t>IPv4 object.</t></dd>
        </dl>
        <dl newline="true" spacing="normal">
          <dt>IPv4 tunnel sender address:</t>

<t><list style='empty'>
  <t>The address:</dt>
           <dd>The IPv4 address that the PLR node sets to identify one or more
           backup path(s) paths as
described in Section 6.1.1 of <xref target="RFC4090"/>. target="RFC4090" sectionFormat="of" section="6.1.1"/>. This address is applicable to all
groups identified by Bypass_Group_Identifier(s) any Bypass_Group_Identifiers carried in the B-SFRR-Active
Extended ASSOCIATION ID.</t>
</list></t> Association ID.</dd>
        </dl>
        </section>
        <section anchor="V6_SFRR_ACTIVE" title="IPv6 numbered="true" toc="default">
          <name>IPv6 B-SFRR-Active Extended ASSOCIATION ID"> Association ID</name>
          <t>The IPv6 Extended ASSOCIATION Association ID for the B-SFRR-Active association type Association Type is
carried inside the IPv6 Extended ASSOCIATION object and has the following
format:</t>
          <figure title="The anchor="fig_IPv6_SFRR_ACTIVE">
            <name>The IPv6 Extended ASSOCIATION Association ID for B-SFRR-Active" anchor="fig_IPV6_SFRR_ACTIVE"><artwork><![CDATA[ B-SFRR-Active</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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Num-BGIDs          |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Bypass_Group_Identifier                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               :                               |
   //                              :                              //
   |                               :                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Bypass_Group_Identifier                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                      RSVP_HOP_Object                        //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                      TIME_VALUES                            //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                       IPv6 tunnel sender address              +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork></figure>

<t>Num-BGIDs: 16
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure>
        <dl newline="false" spacing="normal">
          <dt>Num-BGIDs:</dt><dd><t>16 bits</t>

<t><list style='empty'>
           <t>Number of Bypass_Group_Identifier fields.</t>
</list></t>

<t>Reserved: 16 fields.</t></dd>
          <dt>Reserved:</dt><dd><t>16 bits</t>

<t><list style='empty'>
           <t>Reserved for future use.</t>
</list></t>

<t>Bypass_Group_Identifier: 32 use.</t></dd>
          <dt>Bypass_Group_Identifier:</dt><dd><t>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
Association ID.  One or more Bypass_Group_Identifiers MAY <bcp14>MAY</bcp14> be included.</t>
</list></t>

<t>RSVP_HOP_Object: Class included.</t></dd>
          <dt>RSVP_HOP_Object:</dt><dd><t>Class 3, as defined by <xref target="RFC2205"/></t>

<t><list style='empty'> target="RFC2205" format="default"/></t>
           <t>Replacement RSVP HOP RSVP_HOP object to be applied to all LSPs associated
with each of the following Bypass_Group_Identifiers. This corresponds
to C-Type = 2 for IPv6 RSVP HOP.</t>
</list></t>

<t>TIME_VALUES object: Class RSVP_HOP.</t></dd>
          <dt>TIME_VALUES object:</dt><dd><t>Class 5, as defined by <xref target="RFC2205"/></t>

<t><list style='empty'> target="RFC2205" format="default"/></t>
           <t>Replacement TIME_VALUES object to be applied to all LSPs associated
with each of the following Bypass_Group_Identifiers after receiving
the B-SFRR-Active Extended ASSOCIATION Object.</t>
</list></t>

<t>IPv6 object.</t></dd>
        </dl>
        <dl newline="true" spacing="normal">
          <dt>IPv6 tunnel sender address:</t>

<t><list style='empty'>
  <t>The address:</dt>
           <dd>The IPv6 address that the PLR node sets to identify one or more
           backup path(s) paths as
described in Section 6.1.1 of <xref target="RFC4090"/>. target="RFC4090" sectionFormat="of" section="6.1.1"/>. This address is applicable to all
groups identified by Bypass_Group_Identifier(s) any Bypass_Group_Identifiers carried in the B-SFRR-Active
Extended ASSOCIATION ID.</t>
</list></t> Association ID.</dd>
        </dl>
        </section>
      </section>
      <section anchor="sig-prior-failure" title="Signaling numbered="true" toc="default">
        <name>Signaling Procedures Prior prior to Failure"> Failure</name>
        <t>Before Summary FRR procedures can be used, a handshake MUST <bcp14>MUST</bcp14> be completed
between the PLR and MP nodes. This handshake is performed using the Extended ASSOCIATION
object that carries the B-SFRR-Ready Extended Association ID in both the RSVP
Path and Resv messages of the protected LSP.</t>
        <t>The facility backup method introduced in <xref target="RFC4090"/> target="RFC4090" format="default"/> takes advantage of MPLS label
stacking (PLR (the PLR node imposing imposes additional MPLS label post FRR) labels post-FRR) to allow rerouting of
protected traffic over the backup path. The backup path may have stricter MTU
requirement and
requirements; due to label stacking at the PLR node, the protected traffic may exceed
the backup path MTU. The operator It is assumed to engineer that the operator engineers their network to
allow rerouting of protected traffic and the additional label stacking at the
PLR node in order to not exceed the backup path MTU.</t>
        <t>When using the procedures defined in this document, the PLR node MUST
        <bcp14>MUST</bcp14> ensure that the
bypass tunnel assignment can satisfy the protected LSP MTU requirements post
FRR. post-FRR.  This avoids prevents any packets from being dropped due to exceeding the MTU size
of the backup path after traffic is rerouted on to onto the bypass tunnel post the
failure. Section 2.6 in post-failure. <xref target="RFC3209"/> target="RFC3209" sectionFormat="of" section="2.6"/> describes a mechanism to determine whether
a node needs to fragment or drop a packet when it exceeds the Path path MTU
discovered using RSVP signaling on the primary LSP path. A PLR can leverage
the RSVP discovered Path RSVP-discovered path MTU on the backup and primary LSP paths to ensure
that the MTU
is not exceeded before or after rerouting the protected traffic on to onto the
bypass tunnel.</t>
        <section anchor="plr-signaling-procedure" title="PLR numbered="true" toc="default">
          <name>PLR Signaling Procedure"> Procedure</name>
          <t>The B-SFRR-Ready Extended ASSOCIATION object is added by each PLR node in the RSVP
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 and
that triggers
assignment. This results in triggering an RSVP Path change message.</t> message.
</t>
          <t>Upon receiving an RSVP Resv message with a B-SFRR-Ready Extended ASSOCIATION
object, the PLR node checks to see if the expected sub-objects subobjects from the B-SFRR-Ready
Extended ASSOCIATION Association ID are present. If present, the PLR node determines if the MP has
acknowledged the current PLR node’s node's assignment.</t>
          <t>To be a valid acknowledgement, acknowledgment, the received B-SFRR-Ready Extended ASSOCIATION Association ID
contents within the RSVP Resv message of the protected LSP MUST <bcp14>MUST</bcp14> match the
latest B-SFRR-Ready Extended ASSOCIATION object and Association ID contents
that the PLR node had sent within the RSVP Path message (with the exception of the
MESSAGE_ID).</t>

<t>Note,
          <t>Note that when forwarding an RSVP Resv message upstream, the PLR node SHOULD <bcp14>SHOULD</bcp14> remove
any/all B-SFRR-Ready Extended ASSOCIATION objects whose Bypass_Source_IPv4_Address or
Bypass_Source_IPv6_Address field matches any of the PLR node addresses.</t>
        </section>
        <section anchor="mp-signaling-procedure" title="MP numbered="true" toc="default">
          <name>MP Signaling Procedure"> Procedure</name>
          <t>Upon receiving an RSVP Path message with a B-SFRR-Ready Extended ASSOCIATION
object, an MP node processes all (there may be multiple PLR nodes for a single MP node)
B-SFRR-Ready Extended ASSOCIATION objects that have the MP node address as
Bypass Destination the
bypass destination address in the Extended Association ID.</t>
          <t>The MP node first ensures the existence of the bypass tunnel and that the
Bypass_Group_Identifier is not already FRR active. Active. That is, an LSP cannot join
a group that is already FRR rerouted.</t>
          <t>The MP node builds a mirrored Summary FRR Group group database per PLR node by
associating the Bypass_Source_IPv4_Address or Bypass_Source_IPv6_Address
that is carried in the IPv4 or IPv6 B-SFRR-Ready B&nbhy;SFRR-Ready Extended ASSOCIATION IDs Association IDs,
respectively.</t>
          <t>The MESSAGE_ID is extracted and recorded for the protected LSP Path
state. The MP node signals a B-SFRR-Ready Extended Association ASSOCIATION object and
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
B-SFRR-Ready Extended ASSOCIATION object in the RSVP Path message are copied
into the B-SFRR-Ready Extended ASSOCIATION object to be added in the Resv
message. The MESSAGE_ID object is set according to <xref target="RFC2961"/> target="RFC2961"
format="default"/> with the Flags
being clear.</t>

<t>Note, cleared.</t>
          <t>Note that 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 node(s). nodes. In this case,
the MP node is expected to save all the received MESSAGE_IDs received from the different
upstream PLR node(s). nodes. After a failure, the MP node determines and activates the
state(s) associated with the Bypass_Group_Identifier(s) received in the RSVP
Path message containing the B-SFRR-Active Extended ASSOCIATION object that is
signaled over the bypass tunnel from the PLR node, as described in <xref target="post-failure"> </xref></t> target="post-failure" format="default"> </xref>.</t>
          <t>When forwarding an RSVP Path message downstream, the MP node SHOULD <bcp14>SHOULD</bcp14> remove any/all
B-SFRR-Ready Extended ASSOCIATION object(s) objects whose Bypass_Destination_IPv4_Address or
Bypass_Destination_IPv6_Address field matches any of the MP node addresses.</t>
        </section>
      </section>
      <section anchor="post-failure" title="Signaling numbered="true" toc="default">
        <name>Signaling Procedures Post Failure"> Post-Failure</name>
        <t>Upon detection of a fault (egress link or node failure) failure), the PLR node will first
perform the object modification procedures described by Section 6.4.3 of <xref target="RFC4090"/> target="RFC4090" sectionFormat="of" section="6.4.3"/> for all affected protected LSPs. For the Summary FRR capable FRR-capable LSPs
that are assigned to the same bypass tunnel tunnel, a common RSVP_HOP and
SENDER_TEMPLATE MUST <bcp14>MUST</bcp14> be used.</t>
        <t>The PLR node MUST <bcp14>MUST</bcp14> signal non-Summary FRR capable FRR-capable LSPs over the bypass tunnel before
signaling the Summary FRR capable 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
processed the change yet.</t>
        <t>The B-SFRR-Active Extended ASSOCIATION object is sent within the RSVP Path
message of the bypass tunnel to reroute the RSVP state of Summary FRR capable FRR-capable LSPs.</t>
        <section anchor="plr-sfrr" title="PLR numbered="true" toc="default">
          <name>PLR Signaling Procedure"> Procedure</name>
          <t>After a failure event, when using the Summary FRR path signaling procedures,
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 the
B-SFRR-Active Extended Association ASSOCIATION object in the RSVP Path message of the
RSVP session of the bypass tunnel.</t>
          <t>The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION Association ID is set
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
Extended ASSOCIATION Association ID.</t>
          <t>The PLR node adds the Bypass_Group_Identifier(s) of group(s) any group or groups that have common
group attributes, including the tunnel sender address, to the same B-SFRR-Active
Extended ASSOCIATION Association ID. Note that multiple ASSOCIATION objects, each carrying a
B-SFRR-Active Extended ASSOCIATION Association ID, can be carried within a single RSVP Path
message of the bypass tunnel and sent towards the MP as described in <xref target="RFC6780"/>.</t>

<t>The target="RFC6780" format="default"/>.</t>
          <t>Any previously received MESSAGE_ID(s) MESSAGE_IDs from the MP are activated on the PLR. As a result,
the PLR starts sending Srefresh messages containing the specific Message_identifier(s) Message_Identifier(s)
for the states to be refreshed.</t>
        </section>
        <section anchor="mp-signaling-procedure-1" title="MP numbered="true" toc="default">
          <name>MP Signaling Procedure"> Procedure</name>
          <t>Upon receiving an RSVP Path message with a B-SFRR-Active Extended Association ASSOCIATION
object, the MP performs normal merge point processing for each protected LSP
associated with each Bypass_Group_Identifier, as if it had received an
individual RSVP Path message for that LSP.</t>
          <t>For each Summary FRR capable FRR-capable LSP that is being merged, the MP first modifies the Path
state as follows:</t>

<t><list style="numbers">
  <t>The
          <ol spacing="normal" type="1">
            <li>The RSVP_HOP object is copied from the RSVP_HOP_Object field in the
B-SFRR-Active Extended ASSOCIATION ID.</t>
  <t>The Association ID.</li>
            <li>The TIME_VALUES object is copied from the TIME_VALUES field in the
B-SFRR-Active Extended ASSOCIATION Association ID.  The TIME_VALUES object contains the
refresh time period of the PLR node node, and it is used to generate refreshes and periodic
refreshes. The TIME_VALUES object carried in the B-SFRR-Active Extended
Association ID matches the one that would have been
exchanged in a full Path message sent to the MP after the failure when no Summary
FRR procedures are in effect.</t>
  <t>The used.</li>
            <li>The tunnel sender address field in the SENDER_TEMPLATE object is copied from
the tunnel sender address field of the B-SFRR-Active Extended ASSOCIATION ID.</t>
  <t>The ERO object Association ID.</li>
            <li>The Explicit Route Object (ERO) is modified as per Section 6.4.4 of <xref target="RFC4090"/>. target="RFC4090"
            sectionFormat="of" section="6.4.4"/>. Once the above modifications are completed, the MP node performs the
merge processing as per <xref target="RFC4090"/>.</t>
  <t>The target="RFC4090" format="default"/>.</li>
            <li>Any previously received MESSAGE_ID(s) MESSAGE_IDs from the PLR node are activated. The MP
is allowed to send Srefresh messages containing the specific Message_identifier(s) Message_Identifier(s)
for the states to be refreshed.</t>
</list></t> refreshed.</li>
          </ol>
          <t>A failure during merge processing of any individual rerouted LSP MUST <bcp14>MUST</bcp14>
result in an RSVP Path Error message.</t> PathErr message.
</t>
          <t>An individual RSVP Resv message for each successfully merged Summary
FRR LSP is not signaled. The MP node SHOULD <bcp14>SHOULD</bcp14> immediately use Summary
Refresh summary
refresh procedures to refresh the protected LSP Resv state.</t>
        </section>
      </section>
      <section anchor="refreshing-summary-frr-active-lsps" title="Refreshing numbered="true" toc="default">
        <name>Refreshing Summary FRR Active LSPs">

<t>Refreshing LSPs</name>
        <t>The refreshing of Summary FRR active Active LSPs is performed using Summary
Refresh summary
refresh as defined by <xref target="RFC2961"/>.</t> target="RFC2961" format="default"/>.</t>
      </section>
    </section>
    <section anchor="backwards-compatibility" title="Backwards Compatibility"> numbered="true" toc="default">
      <name>Backwards Compatibility</name>
      <t>The (Extended) ASSOCIATION object is defined in <xref target="RFC4872"/> target="RFC4872" format="default"/> with a class number
in the form 11bbbbbb, where b=0 or 1. This ensures compatibility with
non-supporting node(s)
nodes that do not provide support, in accordance with the procedures specified in
<xref target="RFC2205"/>, Section 3.10 for target="RFC2205" sectionFormat="of" section="3.10"/> regarding unknown-class objects, objects.
Such nodes will ignore the object and forward it without any modification.</t>
    </section>
    <section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document updates an existing RSVP object. object -- the Extended
      ASSOCIATION object as described in <xref target="extensions-for-summary-frr-signaling"/>.
  Thus, in the event of the
interception of a signaling message, slightly more information could be deduced
about the state of the network than was previously the case.</t>
      <t>When using the procedures defined in this document, FRR signaling for rerouting
of protected LSP(s) the states on to of one or more protected LSPs onto the bypass tunnel can be performed on a group
of protected LSP(s) LSPs with a single RSVP message. This allows an intruder to
potentially impact and manipulate a set of protected LSP LSPs that are assigned to
the same bypass tunnel group.  Note that such an attack is even possible even without
the mechanisms proposed defined in this document; albeit, document, albeit at an extra cost resulting
from the excessive per LSP per-LSP signaling that will occur.</t>
      <t>Existing mechanisms for maintaining the integrity and authenticity of RSVP
protocol
messages <xref target="RFC2747"/> target="RFC2747" format="default"/> can be applied. Other considerations mentioned
in <xref target="RFC4090"/> target="RFC4090" format="default"/> and <xref target="RFC5920"/> target="RFC5920" format="default"/> also apply.</t>
    </section>
    <section anchor="iana-considerations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA maintains the “Generalized "Generalized Multi-Protocol Label Switching
      (GMPLS) Signaling Parameters” Parameters" registry. The “Association Type” sub-registry "Association Type" subregistry is included
in this registry.</t>
      <t>This registry has been updated by with the new
   Association Type Types for the Extended ASSOCIATION Object objects defined in this document
as follows:</t>

<figure><artwork><![CDATA[
   Value  Name                         Reference
   -----  ----                         ---------
   TBD-1  B-SFRR-Ready Association     Section 3.1
   TBD-2  B-SFRR-Active

<table anchor="tab-3">
  <name>New Extended ASSOCIATION Object Association    Section 3.2
]]></artwork></figure> Types</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>5</td>
      <td>B-SFRR-Ready Association</td>
      <td><xref target="sfrr-bypass-ready"/></td>
    </tr>
    <tr>
      <td>6</td>
      <td>B-SFRR-Active Association</td>
      <td><xref target="sfrr-bypass-active"/></td>
    </tr>
  </tbody>
</table>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4090.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2961.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4872.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6780.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2205.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2747.xml"/>
      </references>
      <references>
        <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5920.xml"/>
      </references>
    </references>
    <section anchor="acknowledgments" title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank Alexander Okonnikov, Loa Andersson, Lou Berger,
Eric Osborne, Gregory Mirsky, Mach Chen <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 to on this document.</t>
    </section>
    <section anchor="contributors" title="Contributors">

<figure><artwork><![CDATA[
   Nicholas Tan
   Arista Networks

   Email: ntan@arista.com
]]></artwork></figure> 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>

  </middle>

  <back>

    <references title='Normative References'>

<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

<reference  anchor="RFC4090" target='https://www.rfc-editor.org/info/rfc4090'>
<front>
<title>Fast Reroute Extensions to RSVP-TE for LSP Tunnels</title>
<author initials='P.' surname='Pan' fullname='P. Pan' role='editor'><organization /></author>
<author initials='G.' surname='Swallow' fullname='G. Swallow' role='editor'><organization /></author>
<author initials='A.' surname='Atlas' fullname='A. Atlas' role='editor'><organization /></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 enable 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 point of local repair.  The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints.  Both methods can be used to protect links and nodes during network failure.  The described behavior and extensions to RSVP allow nodes to implement either method or 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 /></author>
<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) message is lost and, when desired, refreshing state without the transmission of whole 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 /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</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 /></author>
<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'><organization /></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 Protocol), 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, these 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></abstract>
</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 Label Switching (GMPLS) Recovery</title>
<author initials='J.P.' surname='Lang' fullname='J.P. Lang' role='editor'><organization /></author>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter' role='editor'><organization /></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 Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration.  A generic functional 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 /></author>
<author initials='F.' surname='Le Faucheur' fullname='F. Le Faucheur'><organization /></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-controlled Label Switched Paths (LSPs).  In this context, the object is used to associate recovery LSPs with the LSP they are protecting.  This object also has broader applicability as a mechanism to associate RSVP state.  This document defines how the ASSOCIATION object can be more generally applied.  This document also defines Extended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP).  This document updates RFC 2205, RFC 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 Specification</title>
<author initials='R.' surname='Braden' fullname='R. Braden' role='editor'><organization /></author>
<author initials='L.' surname='Zhang' fullname='L. Zhang'><organization /></author>
<author initials='S.' surname='Berson' fullname='S. Berson'><organization /></author>
<author initials='S.' surname='Herzog' fullname='S. Herzog'><organization /></author>
<author initials='S.' surname='Jamin' fullname='S. Jamin'><organization /></author>
<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, with 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 /></author>
<author initials='B.' surname='Lindell' fullname='B. Lindell'><organization /></author>
<author initials='M.' surname='Talwar' fullname='M. Talwar'><organization /></author>
<date year='2000' month='January' />
<abstract><t>This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. [STANDARDS-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'><organization /></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 techniques, and the mechanisms for detection and reporting.  This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider 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 purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='5920'/>
<seriesInfo name='DOI' value='10.17487/RFC5920'/>
</reference>

    </references>
  </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>