<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
  <!ENTITY RFC3209 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml"> zwsp   "&#8203;">
  <!ENTITY RFC3473 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3473.xml"> nbhy   "&#8209;">
  <!ENTITY RFC4426 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4426.xml">
<!ENTITY RFC4872 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4872.xml">
<!ENTITY RFC4873 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4873.xml">
<!ENTITY RFC6372 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6372.xml">
<!ENTITY RFC7412 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7412.xml">
<!ENTITY RFC8174 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8776 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8776.xml">
<!ENTITY I-D.ietf-teas-yang-te SYSTEM
  "http://xml.resource.org/public/rfc/bibxml-ids/reference.I-D.ietf-teas-yang-te.xml"> wj     "&#8288;">
]>

<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- used by XSLT processors -->

<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC): -->
<?rfc toc="yes"?> <!-- generate a ToC -->
<?rfc tocdepth="3"?> <!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references: -->
<?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?> <!-- sort the reference entries alphabetically -->
<!-- control vertical white space:
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?> <!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?> <!-- keep one blank line between list items -->
<!-- end of popular PIs -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" updates="4872, 4873" category="std" docName="draft-ietf-teas-gmpls-signaling-smp-12"
     ipr="pre5378Trust200902"> number="9270" ipr="pre5378Trust200902" obsoletes="" submissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.13.0 -->
  <front>
    <title abbrev="GMPLS Extension Extensions for SMP">
        GMPLS Signaling Extensions for Shared Mesh Protection
    </title>

    <seriesInfo name="RFC" value="9270"/>
    <author fullname="Jia He" initials="J." surname="He">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>F3-1B, R&amp;D Center, Huawei Industrial Base,
             Bantian, Base</street>
          <street>Bantian, Longgang District</street>
          <city>Shenzhen</city>
     <!-- <region/> -->
     <!-- <code>518129</code> -->
     <country>China</country>
        </postal>
   <!-- <phone></phone>  -->
   <!-- <facsimile/> -->
   <email>hejia@huawei.com</email>
   <!-- <uri/> -->
  </address>
    </author>
    <author fullname="Italo Busi" initials="I" surname="Busi">
      <organization>Huawei Technologies</organization>
      <address>
        <email>italo.busi@huawei.com</email>
      </address>
    </author>
    <author fullname="Jeong-dong Ryoo" initials="J" surname="Ryoo">
      <organization>ETRI</organization>
      <address>
        <postal>
          <street>218 Gajeongno</street>
          <city>Yuseong-gu</city>
          <region>Daejeon</region>
          <code>34129</code>
          <country>South Korea</country>
        </postal>
        <phone>+82-42-860-5384</phone>
        <email>ryoo@etri.re.kr</email>
      </address>
    </author>
    <author fullname="Bin Yeong Yoon" initials="B" surname="Yoon">
      <organization>ETRI</organization>
      <address>
        <email>byyun@etri.re.kr</email>
      </address>
    </author>
    <author fullname="Peter Park" initials="P" surname="Park">
      <organization>KT</organization>
      <address>
        <email>peter.park@kt.com</email>
      </address>
    </author>
  <date />
<!--
 <date day="22" month="May" year="2019" />
--> month="August" year="2022"/>

 <area>Routing Area</area>
    <workgroup>TEAS Working Group</workgroup>
    <keyword>GMPLS</keyword>
    <keyword>Shared mesh protection</keyword>
    <abstract>
      <t>
   ITU-T Recommendation G.808.3 defines the generic aspects of
   a Shared Mesh Protection (SMP) mechanism, where the difference
   between SMP and Shared Mesh Restoration (SMR) is also identified.
   ITU-T Recommendation G.873.3 defines the protection switching operation
   and associated protocol for SMP at the Optical Data Unit (ODU) layer.
   RFC 7412 provides requirements for any mechanism that would be used to
   implement SMP in a Multi-Protocol Label Switching - Transport Profile
   (MPLS-TP) network.
      </t>
      <t>
   This document updates RFC RFCs 4872 and RFC 4873 to provide the extensions
   to the
   for Generalized Multi-Protocol Label Switching (GMPLS) signaling to
   support the control of the SMP. SMP mechanism.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   RFC 4872 <xref target="RFC4872"/> target="RFC4872" format="default"/> defines extension of extensions for
   Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
   to support Shared Mesh Restoration (SMR) mechanisms.
   SMR can be seen as a particular case of pre-planned preplanned
   Label Switched Path (LSP) rerouting that
   reduces the recovery resource requirements by allowing multiple
   protecting LSPs to share common link and node resources.
   The recovery resources for the protecting LSPs are pre-reserved during
   the provisioning phase, and explicit restoration signaling is
   required to activate (i.e., commit resource allocation at the data
   plane) a specific protecting LSP that was instantiated during the
   provisioning phase.
   RFC 4873 <xref target="RFC4873"/> target="RFC4873" format="default"/> details the encoding of
   the last 32-bit Reserved field of the PROTECTION object defined in
   <xref target="RFC4872"/> target="RFC4872" format="default"/>.
      </t>
      <t>
   ITU-T Recommendation G.808.3 <xref target="G808.3"/> target="G808.3" format="default"/> defines
   the generic aspects of a shared mesh protection Shared Mesh Protection (SMP) mechanism,
   which are not specific to a particular network technology in terms of
   architecture types, preemption principle, and path monitoring methods,
   etc.
   ITU-T Recommendation G.873.3 <xref target="G873.3"/> target="G873.3" format="default"/> defines
   the protection switching operation and associated protocol
   for SMP at the Optical Data Unit (ODU) layer.
   RFC 7412 <xref target="RFC7412"/> target="RFC7412" format="default"/> provides requirements for any
   mechanism that would be used to implement SMP in a
   Multi-Protocol Label Switching - Transport Profile (MPLS-TP) network.
      </t>
      <t>
   SMP differs from SMR in the activation/protection switching
   operation. The former activates a protecting LSP via the automatic
   protection switching Automatic
   Protection Switching (APS) protocol in the data plane when the
   working LSP fails, while the latter does it via control plane
   signaling. It is therefore necessary to distinguish SMP from SMR
   during provisioning so that each node involved behaves
   appropriately in the recovery phase when activation of a
   protecting LSP is done.
   SMP has advantages with regard to the recovery speed compared with SMR.
      </t>
      <t>
   This document updates <xref target="RFC4872"/> target="RFC4872" format="default"/> and
   <xref target="RFC4873"/> target="RFC4873" format="default"/> to provide
   the
   extensions to the for Generalized Multi-Protocol Label Switching (GMPLS)
   signaling to support the control of the SMP mechanism.
   Specifically, it;
   <list style="symbols">
     <t> it
      </t>
      <ul spacing="normal">
        <li>
     defines a new LSP protection type, Protection Type, "Shared Mesh Protection," Protection", for the LSP
     Flags field <xref target="RFC4872"/> target="RFC4872" format="default"/> of the PROTECTION object
     (see <xref target="secUpPt"/>),
     </t>
     <t> target="secUpPt" format="default"/>),
     </li>
        <li>
     updates the definitions of the Notification (N) and Operational (O) fields
     <xref target="RFC4872"/> target="RFC4872" format="default"/> of the PROTECTION object to take the new SMP
     type into account (see <xref target="secUpNO"/>), target="secUpNO" format="default"/>), and
     </t>
     <t>
     </li>
        <li>
     updates the definition of the 16-bit Reserved field
     <xref target="RFC4873"/> target="RFC4873" format="default"/> of the PROTECTION object to allocate 8 bits
     to signal the SMP preemption priority (see <xref target="secUpPP"/>).
     </t>
   </list>
   </t> target="secUpPP" format="default"/>).
     </li>
      </ul>
      <t>
   Only the generic aspects for signaling SMP are addressed by this
   document. The technology-specific aspects are expected to be
   addressed by other documents.
      </t>
      <t>
   RFC 8776 <xref target="RFC8776"/> target="RFC8776" format="default"/> defines a collection of common YANG data
   types for Traffic Engineering (TE) configuration and state capabilities.
   It defines several identities for LSP protection types. Protection Types.
   As this document introduces a new LSP Protection Type,
   <xref target="RFC8776"/> target="RFC8776" format="default"/> is expected to be updated to support
   the SMP mechanism specified in this document.
   <xref target="I-D.ietf-teas-yang-te"/> target="YANG-TE" format="default"/> defines a YANG data model
   for the provisioning and management of TE tunnels, LSPs, and interfaces.
   It includes some protection and restoration data nodes relevant to this
   document. Management aspects of the SMP mechanism are outside the scope of this
   document, and they are expected to be addressed by other documents.
      </t>
    </section>
    <section title="Conventions numbered="true" toc="default">
      <name>Conventions Used in This Document">
   <t>
   The Document</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> here.</t>
      <t>
   In addition, the reader is assumed to be familiar with the
   terminology used in <xref target="RFC4872"/>, target="RFC4872" format="default"/>,
   RFC 4426 <xref target="RFC4426"/>, target="RFC4426" format="default"/>, and RFC 6372 <xref target="RFC6372"/>. target="RFC6372" format="default"/>.
      </t>
    </section>
    <section anchor="secDef" title="SMP Definition"> numbered="true" toc="default">
      <name>SMP Definition</name>
      <t>
   <xref target="G808.3"/> target="G808.3" format="default"/> defines the generic aspects of an SMP mechanism.
   <xref target="G873.3"/> target="G873.3" format="default"/> defines the protection switching operation and
   associated protocol for SMP at the ODU layer.
   <xref target="RFC7412"/> target="RFC7412" format="default"/> provides requirements for any
   mechanism that would be used to implement SMP in a an MPLS-TP network.
      </t>
      <t>
   The SMP mechanism is based on pre-computed precomputed protecting LSPs
   that are pre-configured preconfigured into the network elements.
   Pre-configuration
   Preconfiguration here means pre-reserving resources for the
   protecting LSPs without activating a particular protecting LSP
   (e.g., in circuit networks, the cross-connects in the intermediate
   nodes of the protecting LSP are not pre-established).
   Pre-configuring preestablished).
   Preconfiguring but not activating protecting LSPs allows
   link and node resources to be shared by
   the protecting LSPs of multiple working LSPs (that (which are
   themselves disjoint and thus unlikely to fail simultaneously).
   Protecting LSPs are activated in response to
   failures of working LSPs or operator's operator commands by means of the
   APS protocol that protocol, which operates in the data plane.
   The APS protocol messages are exchanged along the protecting LSP.
   SMP is always revertive.
      </t>
      <t>
   SMP has a lot of similarity is very similar to SMR SMR, except that the activation in the
   case of SMR is achieved by control plane signaling during the
   recovery operation, while SMP the same is done for SMP by the APS protocol in the data
   plane.
      </t>
    </section>
    <section anchor="secSmpOper"
          title="Operation numbered="true" toc="default">
      <name>Operation of SMP with GMPLS Signaling Extension"> Extensions</name>
      <t>
   Consider the following network topology: topology shown in <xref target="figEx"/>:
      </t>
      <figure anchor="figEx" title="An example anchor="figEx">
        <name>An Example of an SMP topology">
     <artwork><![CDATA[ Topology</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                          A---B---C---D
                           \         /
                            E---F---G
                           /         \
                          H---I---J---K
      ]]></artwork>
      </figure>
      <t>
   The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by
   the protecting LSPs [A,E,F,G,D] and [H,E,F,G,K], respectively.
   Per RFC 3209 <xref target="RFC3209"/>, target="RFC3209" format="default"/>, in order
   to achieve resource sharing during the signaling of these
   protecting LSPs, they MUST have the same Tunnel Endpoint Address
   (as part of their SESSION object).
   However, these addresses are not the same in this example.
   Similar to SMR, this document defines a new LSP Protection Type of
   the secondary LSP as "Shared Mesh Protection"
   (see <xref target="secUpPt"/>) target="secUpPt" format="default"/>)
   to allow resource sharing along nodes E, F, and G.
   Examples of shared resources include the capacity of a link and
   the cross-connects in a node.
   In this case, the protecting LSPs
   are not merged (which is useful useful, since the paths diverge at G), but
   the resources along E, F, and G can be shared.
      </t>
      <t>
   When a failure, such as Signal Fail (SF) and or Signal Degrade (SD),
   occurs on one of the working LSPs (say (say, working LSP [A,B,C,D]),
   the end node (say (say, node A) that detects the failure initiates
   the protection switching operation.
   End node A will send a protection switching request APS message
   (for example, SF) to its adjacent (downstream) intermediate node (say (say, node E)
   to activate the corresponding protecting LSP
   and will wait for a confirmation message from node E.
      </t>
      <t>
   If the protection resource is available, node E will send the confirmation
   APS message to the end node A (node A) and forward the switching request APS message
   to its adjacent (downstream) node (say (say, node F).
   When the confirmation APS message is received by node A, the
   cross-connection on node A is established.
   At this time time, traffic is bridged to and selected from the protecting LSP
   at node A.
   After forwarding the switching request APS message, node E will wait for
   a confirmation APS message from node F, which triggers node E to set up
   the cross-connection for the protecting LSP being activated.
      </t>
      <t>
   If the protection resource is not available (due to failure or being
   used by higher priority higher-priority connections), the switching will not be successful;
   the intermediate node (node E) MUST <bcp14>MUST</bcp14> send a message to notify the end node
   (node A) (see <xref target="secGmplsNotify"/>). target="secGmplsNotify" format="default"/>).
   If the resource is in use by a lower priority lower-priority protecting LSP, the
   lower priority
   lower-priority service will be removed removed, and then the intermediate node
   will then follow the procedure as described for the case when the protection
   resource is available for the higher priority higher-priority protecting LSP.
      </t>
      <t>
   If node E fails to allocate the protection resource,
   it MUST <bcp14>MUST</bcp14> send a message to notify node A
   (see <xref target="secGmplsNotify"/>). target="secGmplsNotify" format="default"/>).
   Then, node A will stop bridging and selecting traffic to/from
   the protecting LSP and proceed with the procedure of removing
   the protection allocation according to the APS protocol.
      </t>
    </section>
    <section anchor="secGmpls"
         title="GMPLS numbered="true" toc="default">
      <name>GMPLS Signaling Extension Extensions for SMP"> SMP</name>
      <t>
   The following subsections detail how LSPs using SMP can be
   signaled in an interoperable fashion using GMPLS RSVP-TE
   extensions (see RFC 3473 <xref target="RFC3473"/>). target="RFC3473" format="default"/>).
   This signaling enables:
   <list style="empty">
     <t>(1) the
      </t>
      <ol type="(%d)" spacing="normal">
        <li>the ability to identify a "secondary protecting LSP"
     (LSP [A,E,F,G,D] or LSP [H,E,F,G,K] from <xref target="figEx"/>,
     hereby target="figEx" format="default"/>,
     here called the "secondary LSP") used to recover
     another "primary working LSP"
     (LSP [A,B,C,D] or LSP [H,I,J,K] from <xref target="figEx"/>,
     hereby target="figEx" format="default"/>,
     here called the "protected LSP"),
     </t>
     <t>(2) the
     </li>
        <li>the ability to associate the secondary LSP with the protected LSP,
     </t>
     <t>(3) the
     </li>
        <li>the capability to include information about the resources
     used by the protected LSP while instantiating the secondary LSP,
     </t>
     <t>(4) the
     </li>
        <li>the capability to instantiate during the provisioning phase
     several secondary LSPs efficiently, and
     </t>
     <t>(5) efficiently during the provisioning phase, and
     </li>
        <li>the capability to support activation of a secondary LSP after
     failure occurrence via the APS protocol in the data plane.
     </t>
   </list>
   </t> plane if a failure occurs.
     </li>
      </ol>
      <section anchor="secGmplsId" title="Identifiers"> numbered="true" toc="default">
        <name>Identifiers</name>
        <t>
   To simplify association operations, both LSPs (i.e., the protected LSP
   and the secondary LSPs) LSP) belong to the same session.
   Thus, the SESSION object MUST <bcp14>MUST</bcp14> be the same for both LSPs.
   The LSP ID, however, MUST <bcp14>MUST</bcp14> be different to distinguish between the protected
   LSP and the secondary LSP.
        </t>
        <t>
   A new LSP Protection Type Type, "Shared Mesh Protection" Protection", is defined
   (see <xref target="secUpPt"/>) target="secUpPt" format="default"/>)
   for the LSP Flags field of the PROTECTION object (see <xref target="RFC4872"/>) target="RFC4872" format="default"/>)
   to set up the two LSPs.
   This LSP Protection Type value is applicable only applicable to
   bidirectional LSPs as required in <xref target="G808.3"/>. target="G808.3" format="default"/>.
        </t>
      </section>
      <section anchor="secGmplsPrim" title="Signaling numbered="true" toc="default">
        <name>Signaling Primary LSPs"> LSPs</name>
        <t>
   The PROTECTION object (see <xref target="RFC4872"/>) target="RFC4872" format="default"/>) is included
   in the Path message during signaling of the primary working LSPs,
   with the LSP Protection Type value set to "Shared Mesh Protection".
        </t>
        <t>
   Primary working LSPs are signaled by setting in the PROTECTION
   object the S bit to 0, the P bit to 0, and the N bit to 1, 1; and setting in the
   ASSOCIATION object, object the Association ID to the associated secondary
   protecting LSP_ID.
        </t>
   <t>
        <aside><t>
   Note: The N bit is set to indicate that the protection switching
   signaling is done via the data plane.
   </t>
        </t></aside>
      </section>
      <section anchor="secGmplsSecd" title="Signaling numbered="true" toc="default">
        <name>Signaling Secondary LSPs"> LSPs</name>
        <t>
   The PROTECTION object (see <xref target="RFC4872"/>) target="RFC4872" format="default"/>) is included in the Path
   message during signaling of the secondary protecting LSPs, with
   the LSP Protection Type value set to "Shared Mesh Protection".
        </t>
        <t>
   Secondary protecting LSPs are signaled by setting in the
   PROTECTION object the S bit, the P bit, and the N bit to 1, 1; and setting
   in the ASSOCIATION object, object the Association ID to the associated
   primary working LSP_ID, which MUST <bcp14>MUST</bcp14> be known before signaling of
   the secondary LSP.
   Moreover, the Path message used to instantiate
   the secondary LSP MUST <bcp14>MUST</bcp14> include at least one PRIMARY_PATH_ROUTE
   object (see <xref target="RFC4872"/>) target="RFC4872" format="default"/>) that further allows for
   recovery resource sharing at each intermediate node
   along the secondary path.
        </t>
        <t>
   With this setting, the resources for the secondary LSP MUST <bcp14>MUST</bcp14> be
   pre-reserved,
   pre-reserved but not committed at the data plane level, meaning
   that the internals of the switch need not be established until
   explicit action is taken to activate this LSP.  Activation of a
   secondary LSP and protection switching to the activated protecting
   LSP is done using the APS protocol in the data plane.
        </t>
        <t>
   After protection switching completes completes, the protecting LSP MUST <bcp14>MUST</bcp14> be
   signaled with by setting the S bit set to 0 and the O bit set to 1 in the
   PROTECTION object. At this point, the link and node resources MUST <bcp14>MUST</bcp14>
   be allocated for this LSP that LSP, which becomes a primary LSP (ready to
   carry traffic).
   The formerly working LSP MAY <bcp14>MAY</bcp14> be signaled with the A bit set in the
   ADMIN_STATUS object (see <xref target="RFC3473"/>). target="RFC3473" format="default"/>).
        </t>
        <t>
   Support for extra traffic in SMP is left for further study.
   Therefore, mechanisms to set up LSPs for extra traffic
   are outside the scope of this document.
        </t>
      </section>
      <section anchor="secGmplsPrio" title="SMP numbered="true" toc="default">
        <name>SMP Preemption Priority"> Priority</name>
        <t>
   The SMP preemption priority of a protecting LSP that is used by the APS protocol
   uses
   to resolve the competition for shared resources among multiple
   protecting LSPs, LSPs and is indicated in the Preemption Priority field of the
   PROTECTION object in the Path message of the protecting LSP.
        </t>
        <t>
   The Setup and Holding priorities in the SESSION_ATTRIBUTE
   object can be used by GMPLS to control LSP preemption, but, but they are
   not used by the APS to resolve the competition among multiple
   protecting LSPs.  This avoids the need to define a complex policy for
   defining Setup and Holding priorities when used for both GMPLS
   control plane LSP preemption and SMP shared resource competition
   resolution.
        </t>
        <t>
   When an intermediate node on the protecting LSP receives the Path
   message, the priority value in the Preemption Priority field MUST <bcp14>MUST</bcp14> be
   stored for that protecting LSP.  When resource competition among
   multiple protecting LSPs occurs, the APS protocol will use their
   priority values to resolve the this competition.
   A lower value has a higher priority.
        </t>
        <t>
   In SMP, a preempted LSP MUST NOT <bcp14>MUST NOT</bcp14> be terminated even after its resources
   have been deallocated. Once the working
   LSP and the protecting LSP are configured or pre-configured, preconfigured, the end
   node MUST <bcp14>MUST</bcp14> keep refreshing both working and protecting LSPs LSPs,
   regardless of failure or preempted situation. preemption status.
        </t>
      </section>
      <section anchor="secGmplsNotify"
          title="Notifying Availability numbered="true" toc="default">
        <name>Availability of Shared Resources"> Resources: The Notify Message</name>

        <t>
   When a lower priority lower-priority protecting LSP is preempted, the intermediate
   node that performed the preemption MUST <bcp14>MUST</bcp14> send a Notify message with
   error code "Notify Error" (25) (see [RFC4872]) <xref target="RFC4872"/>) and
   error sub-code "Shared resources unavailable" (TBA1) (17)
   to the end nodes of that protecting LSP.
   Upon receipt of this Notify message, the end node MUST <bcp14>MUST</bcp14> stop sending and
   selecting traffic to/from its protecting LSP and try switching
   the traffic to another protecting LSP, if available.
        </t>
        <t>
   When a protecting LSP occupies the shared resources
   and they become unavailable, the same Notify message MUST <bcp14>MUST</bcp14> be
   generated by the intermediate node to all the end nodes of the
   protecting LSPs that have lower SMP preemption priorities than the
   one that has occupied the shared resources.
   In case
   If the shared resources become unavailable
   due to a failure in the shared resources,
   the same Notify message MUST <bcp14>MUST</bcp14> be generated by the intermediate node
   to all the end nodes of the protecting LSPs that have been configured
   to use the shared resources.
   These end nodes, in
   In the case of a failure of the working LSP,
   MUST these end nodes
   <bcp14>MUST</bcp14> avoid trying to switch traffic to these protecting LSPs
   that have been configured to use the shared resources
   and try switching the traffic to other protecting LSPs, if available.
        </t>
        <t>
   When the shared resources become available, a Notify message with
   error code "Notify Error" (25) and
   error sub-code "Shared resources available" (TBA2)
   MUST (18)
   <bcp14>MUST</bcp14> be generated by the intermediate node.  The recipients of this
   Notify message are the end nodes of the lower priority lower-priority protecting
   LSPs that have been preempted and/or all the end nodes of the
   protecting LSPs that have lower SMP preemption priorities than the
   one that does not need the shared resources anymore.
   Upon receipt of this Notify message, the end node is allowed to
   reinitiate the protection switching operation as described in
   <xref target="secSmpOper"/>, target="secSmpOper" format="default"/>, if it still needs the protection
   resource.
        </t>
      </section>
      <section anchor="secGmplsAps" title="SMP numbered="true" toc="default">
        <name>SMP APS Configuration"> Configuration</name>
        <t>
   SMP relies on APS protocol messages being exchanged between the nodes
   along the path to activate an SMP a protecting LSP.
        </t>
        <t>
   In order to allow the exchange of APS protocol messages,
   an APS channel has to be configured between adjacent nodes
   along the path of the SMP protecting LSP.
   This is done by other means other than GMPLS signaling,
   before any SMP protecting LSP has been set up.
   Therefore, there are likely additional requirements for APS configuration
   which
   that are outside the scope of this document.
        </t>
        <t>
   Depending on the APS protocol message format,
   the APS protocol may use different identifiers than GMPLS signaling
   to identify the SMP protecting LSP.
        </t>
        <t>
   Since the APS protocol is left for further study in per <xref target="G808.3"/>, target="G808.3" format="default"/>,
   it can be assumed that the APS message format and identifiers are
   technology-specific
   technology specific and/or vendor-specific. vendor specific.
   Therefore, additional requirements for APS configuration
   are outside the scope of this document.
        </t>
<!--
   <t>
   [EDITOR'S NOTE: Three options for APS configuration:
   a) out-of-scope,
   b) define a new object whose content is vendor-specific,
   c) define a new object with a TLV structure.
   The above paragraph (option a) can be confirmed or modified
   depending on a reply LS from the ITU-T SG15.
   </t>
-->
 </section>
    </section>
    <section anchor="secUp" title="Updates numbered="true" toc="default">
      <name>Updates to PROTECTION Object"> Object</name>
      <t>
   GMPLS extension requirements for SMP introduce several updates to
   the Protection Object PROTECTION object (see <xref target="RFC4872"/>). target="RFC4872" format="default"/>), as
   detailed below.
      </t>
      <section anchor="secUpPt" title="New numbered="true" toc="default">
        <name>New Protection Type"> Type</name>
        <t>
   A new LSP protection type Protection Type, "Shared Mesh Protection" Protection", is added in the
   PROTECTION object. This LSP Protection Type value is only applicable to
   only
   bidirectional LSPs.
        </t>
        <t>
   LSP (Protection Type) Flags:
   <list style="empty">
     <t>0x20:
        </t>
        <t indent="3">
        0x20: Shared Mesh Protection
        </t>
   </list>
   </t>
        <t>
   The rules defined in Section 14.2 of <xref target="RFC4872"/> target="RFC4872" sectionFormat="of" section="14.2"/>
 ensure that all the nodes along an SMP LSP are SMP aware.
   Therefore, there are no backward compatibility backward-compatibility issues.
        </t>
      </section>
      <section anchor="secUpNO" title="Updates on numbered="true" toc="default">
        <name>Updates to Definitions of Notification and Operational Bits"> Bits</name>
        <t>
   The definitions of the N and O bits in Section 14.1 of <xref target="RFC4872"/> target="RFC4872" sectionFormat="of" section="14.1"/> are replaced as follows:
        </t>
        <t>
   Notification (N): 1 bit
   <list style="empty">
      <t>
        </t>
      <t indent="3">
      When set to 1, this bit indicates that the control plane message
      exchange is only used for notification during protection
      switching.  When set to 0 (default), it indicates that the control
      plane message exchanges are used for protection-switching
      purposes. purposes of protection switching.
      The N bit is only applicable when the LSP Protection
      Type Flag is set to 0x04 (1:N Protection with Extra-Traffic),
      0x08 (1+1 Unidirectional Protection),
      0x10 (1+1 Bidirectional Protection),
      or 0x20 (Shared Mesh Protection).
      The N bit MUST <bcp14>MUST</bcp14> be set to 0 in any other case.
      If 0x20 (SMP), the N bit MUST <bcp14>MUST</bcp14> be set to 1.
      </t>
   </list>
   </t>
        <t>
   Operational (O): 1 bit
   <list style="empty">
      <t>
        </t>
      <t indent="3">
      When set to 1, this bit indicates that the protecting LSP is
      carrying traffic after protection switching. The O bit
      is only applicable when (1) the P bit is set to 1, 1 and (2) the LSP
      Protection Type Flag is set to 0x04 (1:N Protection with
      Extra-Traffic), 0x08 (1+1 Unidirectional Protection), 0x10
      (1+1 Bidirectional Protection), or 0x20 (Shared Mesh Protection).
      The O bit MUST <bcp14>MUST</bcp14> be set to 0 in any other case.
      </t>
   </list>
   </t>
      </section>
      <section anchor="secUpPP" title="Preemption Priority"> numbered="true" toc="default">
        <name>Preemption Priority</name>
        <t>
   <xref target="RFC4872"/> target="RFC4872" format="default"/> reserved a 32-bit field in the PROTECTION object
   header. Subsequently, <xref target="RFC4873"/> target="RFC4873" format="default"/> allocated several fields bits
   from that field, field and left the remainder of the bits reserved.
   This specification further allocates the preemption priority Preemption Priority field
   from those formerly-reserved the remaining formerly reserved bits.
   The 32-bit field in the PROTECTION object as defined in <xref target="RFC4873"/>
   are target="RFC4872"/> and modified by
   <xref target="RFC4873" format="default"/>
   is updated by this document as follows:
        </t>
   <figure>
      <artwork><![CDATA[
        <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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|R|   Reserved    | Seg.Flags |   Reserved    | Preempt Prio  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ]]></artwork>
   </figure>
        <t>
   Preemption Priority (Preempt Prio): 8 bit
   <list style="empty">
      <t> bits
        </t>
      <t indent="3">
      This field indicates the SMP preemption priority of a protecting LSP,
      when the LSP Protection Type field indicates "Shared Mesh Protection".
      The SMP preemption priority value is configured
      at the end nodes of the protecting LSP by a network operator.
      A lower value has a higher priority.
      The decision of regarding how many priority levels to should be operated implemented in an
      SMP network is a left to network operator's choice.
     </t>
   </list> operators.
      </t>
        <t>
   See <xref target="RFC4873"/> target="RFC4873" format="default"/> for the definition definitions of the other fields.
        </t>
      </section>
    </section>
    <section anchor="secIANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
<!--
   There are no IANA actions required by this document.
   IANA actions required by this document will be described later.
-->
<!--
   This document requests IANA to define two new sub-code values
   under "Notify Error" code in Resource Reservation Protocol (RSVP) parameters.
-->
   IANA maintains a registry group of registries called "Resource Reservation Protocol
   (RSVP) Parameters" with a subregistry called Parameters", which includes the "Error Codes and
   Globally-Defined Error Value Sub-Codes".  Within this subregistry
   there is a definition of Sub-Codes" registry.  IANA has added the "Notify following values to the "Sub-Codes - 25 Notify Error" error code (25).
   The definition subregistry, which lists a number of error value sub-codes that may be
   used with this error code. code 25.  IANA is requested to allocate further has allocated the following
   error value sub-codes (<xref target="tab-1"/>) for use with this error code as described in
   this document.

      </t>

   <figure>
      <artwork><![CDATA[
   Value        Description              Reference
   ----- ---------------------------- ---------------
   TBA1  Shared

<table anchor="tab-1">
  <name>New Error Sub-Codes</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>17</td>
      <td>Shared resources unavailable (this document)
   TBA2  Shared unavailable</td>
      <td>RFC 9270</td>
    </tr>
    <tr>
      <td>18</td>
      <td>Shared resources available   (this document)
      ]]></artwork>
   </figure> available</td>
      <td>RFC 9270</td>
    </tr>
  </tbody>
</table>
    </section>
    <section anchor="secSec" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   Since this document makes use of the exchange of RSVP messages
   including
   that include a Notify message, the security threats discussed in
   <xref target="RFC4872"/> target="RFC4872" format="default"/> also apply to this document.
      </t>
      <t>
   Additionally, it may be possible to cause disruption to
   traffic on one protecting LSP by targeting a link used by the primary
   LSP of another, higher priority higher-priority LSP somewhere completely different in
   the network.
   For example, in <xref target="figEx"/>, target="figEx" format="default"/>,
   assume that the preemption priority of LSP [A,E,F,G,D] is higher than
   that of LSP [H,E,F,G,K] and the protecting LSP [H,E,F,G,K] is being
   used to transport traffic.
   If link B-C is attacked, traffic on LSP [H,E,F,G,K] can be disrupted.
   For this reason, it is
   important not only to use security mechanisms as discussed in
   <xref target="RFC4872"/> target="RFC4872" format="default"/> but also to acknowledge that
   detailed knowledge of a network's topology, including routes and priorities
   of LSPs, can help an attacker better target or improve the efficacy of
   an attack.
      </t>
    </section>

 <section anchor="Acknowledgements" title="Acknowledgements">
   <t>The authors would like to thank Adrian Farrel,
   Vishnu Pavan Beeram, Tom Petch, Ines Robles, John Scudder, Dale Worley,
   Dan Romascanu, Eric Vyncke, Roman Danyliw, Paul Wouters, Lars Eggert,
   Francesca Palombini, and Robert Wilton
   for their valuable comments and suggestions on this document.
   </t>
 </section>

 <section anchor="secCon" title="Contributor">
   <texttable align="left" style="none">
     <preamble>
     The following person contributed significantly to the content of
     this document and should be considered as a co-author.
     </preamble>
     <ttcol align="left"></ttcol>
     <c>Yuji Tochio </c>
     <c>Fujitsu </c>
     <c>Email: tochio@fujitsu.com </c>
   </texttable>
 </section>
  </middle>
  <back>
 <references title="Normative References">
   &RFC2119;
   &RFC3209;
   &RFC3473;
   &RFC4426;
   &RFC4872;
   &RFC4873;
   &RFC8174;
    <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.3209.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3473.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4426.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.4873.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <reference anchor="G808.3"> anchor="G808.3" target="https://www.itu.int/rec/T-REC-G.808.3">
          <front>
            <title>Generic protection switching - Shared mesh protection
            </title>
            <author>
              <organization>International Telecommunication Union</organization>
            </author>
            <date month="October" year="2012" year="2012"/>
          </front>
          <refcontent>ITU-T Recommendation G.808.3</refcontent>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6372.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7412.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8776.xml"/>

<!-- draft-ietf-teas-yang-te (I-D Exists)
  Had to do "long way" to fix Vishnu's initials and Oscar's last name -->
<reference anchor="YANG-TE">
   <front>
      <title>A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces</title>
      <author initials="T." surname="Saad" fullname="Tarek Saad">
         <organization>Juniper Networks</organization>
      </author>
      <author initials="R." surname="Gandhi" fullname="Rakesh Gandhi">
         <organization>Cisco Systems Inc</organization>
      </author>
      <author initials="X." surname="Liu" fullname="Xufeng Liu">
         <organization>Volta Networks</organization>
      </author>
      <author initials="V.P." surname="Beeram" fullname="Vishnu Pavan Beeram">
         <organization>Juniper Networks</organization>
      </author>
      <author initials="I." surname="Bryskin" fullname="Igor Bryskin">
         <organization>Individual</organization>
      </author>
      <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez de Dios">
         <organization>Telefonica</organization>
      </author>
      <date month="February" day="7" year="2022" />
   </front>
   <seriesInfo name="ITU-T" value="Recommendation G.808.3" name="Internet-Draft" value="draft-ietf-teas-yang-te-29" />
</reference>

 </references>
 <references title="Informative References">
   &RFC6372;
   &RFC7412;
   &RFC8776;
   &I-D.ietf-teas-yang-te;

        <reference anchor="G873.3"> anchor="G873.3" target="https://www.itu.int/rec/T-REC-G.873.3-201709-I/en">
          <front>
            <title>Optical transport network - Shared mesh protection
            </title>
            <author>
              <organization>International Telecommunication Union</organization>
            </author>
            <date month="September" year="2017" /> year="2017"/>
          </front>
    <seriesInfo name="ITU-T" value="Recommendation G.873.3" />
          <refcontent>ITU-T Recommendation G.873.3</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank <contact fullname="Adrian Farrel"/>,
   <contact fullname="Vishnu Pavan Beeram"/>, <contact fullname="Tom Petch"/>, <contact fullname="Ines Robles"/>, <contact fullname="John Scudder"/>, <contact fullname="Dale Worley"/>,
   <contact fullname="Dan Romascanu"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Paul Wouters"/>, <contact fullname="Lars Eggert"/>,
   <contact fullname="Francesca Palombini"/>, and <contact fullname="Robert Wilton"/>
   for their valuable comments and suggestions on this document.
      </t>
    </section>
    <section anchor="secCon" numbered="false" toc="default">
      <name>Contributors</name>
      <t keepWithNext="true">
     The following person contributed significantly to the content of
     this document and should be considered a coauthor.
      </t>
      <contact fullname="Yuji Tochio">
        <organization>Fujitsu</organization>
        <address>
          <email>tochio@fujitsu.com</email>
        </address>
      </contact>
    </section>
  </back>
</rfc>