rfc9270xml2.original.xml   rfc9270.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY RFC2119 SYSTEM <!ENTITY nbsp "&#160;">
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY RFC3209 SYSTEM <!ENTITY nbhy "&#8209;">
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml"> <!ENTITY wj "&#8288;">
<!ENTITY RFC3473 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3473.xml">
<!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">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- used by XSLT proces <rfc xmlns:xi="http://www.w3.org/2001/XInclude" updates="4872, 4873" category="s
sors --> td" docName="draft-ietf-teas-gmpls-signaling-smp-12" number="9270" ipr="pre5378T
rust200902" obsoletes="" submissionType="IETF" consensus="true" xml:lang="en" to
<!-- OPTIONS, known as processing instructions (PIs) go here. --> cInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
<!-- For a complete list and description of PIs, <!-- xml2rfc v2v3 conversion 3.13.0 -->
please see http://xml.resource.org/authoring/README.html. --> <front>
<!-- Below are generally applicable PIs that most I-Ds might want to use. --> <title abbrev="GMPLS Extensions for SMP">
<?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 updates="4872, 4873"
category="std"
docName="draft-ietf-teas-gmpls-signaling-smp-12"
ipr="pre5378Trust200902">
<front>
<title abbrev="GMPLS Extension for SMP">
GMPLS Signaling Extensions for Shared Mesh Protection GMPLS Signaling Extensions for Shared Mesh Protection
</title> </title>
<author fullname="Jia He" initials="J." surname="He"> <seriesInfo name="RFC" value="9270"/>
<organization>Huawei Technologies</organization> <author fullname="Jia He" initials="J." surname="He">
<address> <organization>Huawei Technologies</organization>
<postal> <address>
<street>F3-1B, R&amp;D Center, Huawei Industrial Base, <postal>
Bantian, Longgang District</street> <street>F3-1B, R&amp;D Center, Huawei Industrial Base</street>
<city>Shenzhen</city> <street>Bantian, Longgang District</street>
<!-- <region/> --> <city>Shenzhen</city>
<!-- <code>518129</code> -->
<country>China</country> <country>China</country>
</postal> </postal>
<!-- <phone></phone> -->
<!-- <facsimile/> -->
<email>hejia@huawei.com</email> <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> </address>
</author> </author>
<author fullname="Italo Busi" initials="I" surname="Busi">
<author fullname="Bin Yeong Yoon" initials="B" surname="Yoon"> <organization>Huawei Technologies</organization>
<organization>ETRI</organization> <address>
<address> <email>italo.busi@huawei.com</email>
<email>byyun@etri.re.kr</email> </address>
</address> </author>
</author> <author fullname="Jeong-dong Ryoo" initials="J" surname="Ryoo">
<organization>ETRI</organization>
<author fullname="Peter Park" initials="P" surname="Park"> <address>
<organization>KT</organization> <postal>
<address> <street>218 Gajeongno</street>
<email>peter.park@kt.com</email> <city>Yuseong-gu</city>
</address> <region>Daejeon</region>
</author> <code>34129</code>
<country>South Korea</country>
<date /> </postal>
<!-- <phone>+82-42-860-5384</phone>
<date day="22" month="May" year="2019" /> <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 month="August" year="2022"/>
<area>Routing Area</area> <area>Routing Area</area>
<workgroup>TEAS Working Group</workgroup> <workgroup>TEAS Working Group</workgroup>
<keyword>GMPLS</keyword>
<keyword>GMPLS</keyword> <keyword>Shared mesh protection</keyword>
<keyword>Shared mesh protection</keyword> <abstract>
<t>
<abstract>
<t>
ITU-T Recommendation G.808.3 defines the generic aspects of ITU-T Recommendation G.808.3 defines the generic aspects of
a Shared Mesh Protection (SMP) mechanism, where the difference a Shared Mesh Protection (SMP) mechanism, where the difference
between SMP and Shared Mesh Restoration (SMR) is also identified. between SMP and Shared Mesh Restoration (SMR) is also identified.
ITU-T Recommendation G.873.3 defines the protection switching operation ITU-T Recommendation G.873.3 defines the protection switching operation
and associated protocol for SMP at the Optical Data Unit (ODU) layer. and associated protocol for SMP at the Optical Data Unit (ODU) layer.
RFC 7412 provides requirements for any mechanism that would be used to RFC 7412 provides requirements for any mechanism that would be used to
implement SMP in a Multi-Protocol Label Switching - Transport Profile implement SMP in a Multi-Protocol Label Switching - Transport Profile
(MPLS-TP) network. (MPLS-TP) network.
</t> </t>
<t> <t>
This document updates RFC 4872 and RFC 4873 to provide the extensions This document updates RFCs 4872 and 4873 to provide extensions
to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to for Generalized Multi-Protocol Label Switching (GMPLS) signaling to
support the control of the SMP. support the control of the SMP mechanism.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section numbered="true" toc="default">
<section title="Introduction"> <name>Introduction</name>
<t> <t>
RFC 4872 <xref target="RFC4872"/> defines extension of RFC 4872 <xref target="RFC4872" format="default"/> defines extensions for
Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
to support Shared Mesh Restoration (SMR) mechanisms. to support Shared Mesh Restoration (SMR) mechanisms.
SMR can be seen as a particular case of pre-planned SMR can be seen as a particular case of preplanned
Label Switched Path (LSP) rerouting that Label Switched Path (LSP) rerouting that
reduces the recovery resource requirements by allowing multiple reduces the recovery resource requirements by allowing multiple
protecting LSPs to share common link and node resources. protecting LSPs to share common link and node resources.
The recovery resources for the protecting LSPs are pre-reserved during The recovery resources for the protecting LSPs are pre-reserved during
the provisioning phase, and explicit restoration signaling is the provisioning phase, and explicit restoration signaling is
required to activate (i.e., commit resource allocation at the data required to activate (i.e., commit resource allocation at the data
plane) a specific protecting LSP that was instantiated during the plane) a specific protecting LSP that was instantiated during the
provisioning phase. provisioning phase.
RFC 4873 <xref target="RFC4873"/> details the encoding of RFC 4873 <xref target="RFC4873" format="default"/> details the encoding of
the last 32-bit Reserved field of the PROTECTION object defined in the last 32-bit Reserved field of the PROTECTION object defined in
<xref target="RFC4872"/> <xref target="RFC4872" format="default"/>.
</t> </t>
<t> <t>
ITU-T Recommendation G.808.3 <xref target="G808.3"/> defines ITU-T Recommendation G.808.3 <xref target="G808.3" format="default"/> defines
the generic aspects of a shared mesh protection (SMP) mechanism, the generic aspects of a Shared Mesh Protection (SMP) mechanism,
which are not specific to a particular network technology in terms of which are not specific to a particular network technology in terms of
architecture types, preemption principle, and path monitoring methods, architecture types, preemption principle, path monitoring methods,
etc. etc.
ITU-T Recommendation G.873.3 <xref target="G873.3"/> defines ITU-T Recommendation G.873.3 <xref target="G873.3" format="default"/> defines
the protection switching operation and associated protocol the protection switching operation and associated protocol
for SMP at the Optical Data Unit (ODU) layer. for SMP at the Optical Data Unit (ODU) layer.
RFC 7412 <xref target="RFC7412"/> provides requirements for any RFC 7412 <xref target="RFC7412" format="default"/> provides requirements for any
mechanism that would be used to implement SMP in a mechanism that would be used to implement SMP in a
Multi-Protocol Label Switching - Transport Profile (MPLS-TP) network. Multi-Protocol Label Switching - Transport Profile (MPLS-TP) network.
</t> </t>
<t> <t>
SMP differs from SMR in the activation/protection switching SMP differs from SMR in the activation/protection switching
operation. The former activates a protecting LSP via the automatic operation. The former activates a protecting LSP via the Automatic
protection switching (APS) protocol in the data plane when the Protection Switching (APS) protocol in the data plane when the
working LSP fails, while the latter does it via control plane working LSP fails, while the latter does it via control plane
signaling. It is therefore necessary to distinguish SMP from SMR signaling. It is therefore necessary to distinguish SMP from SMR
during provisioning so that each node involved behaves during provisioning so that each node involved behaves
appropriately in the recovery phase when activation of a appropriately in the recovery phase when activation of a
protecting LSP is done. protecting LSP is done.
SMP has advantages with regard to the recovery speed compared with SMR. SMP has advantages with regard to the recovery speed compared with SMR.
</t> </t>
<t> <t>
This document updates <xref target="RFC4872"/> and This document updates <xref target="RFC4872" format="default"/> and
<xref target="RFC4873"/> to provide <xref target="RFC4873" format="default"/> to provide
the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) extensions for Generalized Multi-Protocol Label Switching (GMPLS)
signaling to support the control of the SMP mechanism. signaling to support the control of the SMP mechanism.
Specifically, it; Specifically, it
<list style="symbols"> </t>
<t> <ul spacing="normal">
defines a new LSP protection type, "Shared Mesh Protection," for the LSP <li>
Flags field <xref target="RFC4872"/> of the PROTECTION object defines a new LSP Protection Type, "Shared Mesh Protection", for the LSP
(see <xref target="secUpPt"/>), Flags field <xref target="RFC4872" format="default"/> of the PROTECTION obj
</t> ect
<t> (see <xref target="secUpPt" format="default"/>),
</li>
<li>
updates the definitions of the Notification (N) and Operational (O) fields updates the definitions of the Notification (N) and Operational (O) fields
<xref target="RFC4872"/> of the PROTECTION object to take the new SMP <xref target="RFC4872" format="default"/> of the PROTECTION object to take
type into account (see <xref target="secUpNO"/>), and the new SMP
</t> type into account (see <xref target="secUpNO" format="default"/>), and
<t> </li>
<li>
updates the definition of the 16-bit Reserved field updates the definition of the 16-bit Reserved field
<xref target="RFC4873"/> of the PROTECTION object to allocate 8 bits <xref target="RFC4873" format="default"/> of the PROTECTION object to alloc
to signal the SMP preemption priority (see <xref target="secUpPP"/>). ate 8 bits
</t> to signal the SMP preemption priority (see <xref target="secUpPP" format="d
</list> efault"/>).
</t> </li>
<t> </ul>
<t>
Only the generic aspects for signaling SMP are addressed by this Only the generic aspects for signaling SMP are addressed by this
document. The technology-specific aspects are expected to be document. The technology-specific aspects are expected to be
addressed by other documents. addressed by other documents.
</t> </t>
<t> <t>
RFC 8776 <xref target="RFC8776"/> defines a collection of common YANG data RFC 8776 <xref target="RFC8776" format="default"/> defines a collection of co
mmon YANG data
types for Traffic Engineering (TE) configuration and state capabilities. types for Traffic Engineering (TE) configuration and state capabilities.
It defines several identities for LSP protection types. It defines several identities for LSP Protection Types.
As this document introduces a new LSP Protection Type, As this document introduces a new LSP Protection Type,
<xref target="RFC8776"/> is expected to be updated to support <xref target="RFC8776" format="default"/> is expected to be updated to suppor
the SMP specified in this document. t
<xref target="I-D.ietf-teas-yang-te"/> defines a YANG data model the SMP mechanism specified in this document.
<xref target="YANG-TE" format="default"/> defines a YANG data model
for the provisioning and management of TE tunnels, LSPs, and interfaces. for the provisioning and management of TE tunnels, LSPs, and interfaces.
It includes some protection and restoration data nodes relevant to this It includes some protection and restoration data nodes relevant to this
document. Management aspects of the SMP are outside the scope of this document. Management aspects of the SMP mechanism are outside the scope of th is
document, and they are expected to be addressed by other documents. document, and they are expected to be addressed by other documents.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Conventions Used in This Document"> <name>Conventions Used in This Document</name>
<t> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>SHOULD NOT</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
</t> are to be interpreted as described in BCP&nbsp;14
<t> <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
<t>
In addition, the reader is assumed to be familiar with the In addition, the reader is assumed to be familiar with the
terminology used in <xref target="RFC4872"/>, terminology used in <xref target="RFC4872" format="default"/>,
RFC 4426 <xref target="RFC4426"/>, and RFC 6372 <xref target="RFC6372"/>. RFC 4426 <xref target="RFC4426" format="default"/>, and RFC 6372 <xref target
</t> ="RFC6372" format="default"/>.
</section> </t>
</section>
<section anchor="secDef" title="SMP Definition"> <section anchor="secDef" numbered="true" toc="default">
<t> <name>SMP Definition</name>
<xref target="G808.3"/> defines the generic aspects of an SMP mechanism. <t>
<xref target="G873.3"/> defines the protection switching operation and <xref target="G808.3" format="default"/> defines the generic aspects of an SM
P mechanism.
<xref target="G873.3" format="default"/> defines the protection switching ope
ration and
associated protocol for SMP at the ODU layer. associated protocol for SMP at the ODU layer.
<xref target="RFC7412"/> provides requirements for any <xref target="RFC7412" format="default"/> provides requirements for any
mechanism that would be used to implement SMP in a MPLS-TP network. mechanism that would be used to implement SMP in an MPLS-TP network.
</t> </t>
<t> <t>
The SMP mechanism is based on pre-computed protecting LSPs The SMP mechanism is based on precomputed protecting LSPs
that are pre-configured into the network elements. that are preconfigured into the network elements.
Pre-configuration here means pre-reserving resources for the Preconfiguration here means pre-reserving resources for the
protecting LSPs without activating a particular protecting LSP protecting LSPs without activating a particular protecting LSP
(e.g., in circuit networks, the cross-connects in the intermediate (e.g., in circuit networks, the cross-connects in the intermediate
nodes of the protecting LSP are not pre-established). nodes of the protecting LSP are not preestablished).
Pre-configuring but not activating protecting LSPs allows Preconfiguring but not activating protecting LSPs allows
link and node resources to be shared by link and node resources to be shared by
the protecting LSPs of multiple working LSPs (that are the protecting LSPs of multiple working LSPs (which are
themselves disjoint and thus unlikely to fail simultaneously). themselves disjoint and thus unlikely to fail simultaneously).
Protecting LSPs are activated in response to Protecting LSPs are activated in response to
failures of working LSPs or operator's commands by means of the failures of working LSPs or operator commands by means of the
APS protocol that operates in the data plane. APS protocol, which operates in the data plane.
The APS protocol messages are exchanged along the protecting LSP. The APS protocol messages are exchanged along the protecting LSP.
SMP is always revertive. SMP is always revertive.
</t> </t>
<t> <t>
SMP has a lot of similarity to SMR except that the activation in SMP is very similar to SMR, except that activation in the
case of SMR is achieved by control plane signaling during the case of SMR is achieved by control plane signaling during the
recovery operation, while SMP is done by the APS protocol in the data recovery operation, while the same is done for SMP by the APS protocol in the data
plane. plane.
</t> </t>
</section> </section>
<section anchor="secSmpOper" numbered="true" toc="default">
<section anchor="secSmpOper" <name>Operation of SMP with GMPLS Signaling Extensions</name>
title="Operation of SMP with GMPLS Signaling Extension"> <t>
<t> Consider the network topology shown in <xref target="figEx"/>:
Consider the following network topology: </t>
</t> <figure anchor="figEx">
<figure anchor="figEx" title="An example of SMP topology"> <name>An Example of an SMP Topology</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
A---B---C---D A---B---C---D
\ / \ /
E---F---G E---F---G
/ \ / \
H---I---J---K H---I---J---K
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by 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. the protecting LSPs [A,E,F,G,D] and [H,E,F,G,K], respectively.
Per RFC 3209 <xref target="RFC3209"/>, in order Per RFC 3209 <xref target="RFC3209" format="default"/>, in order
to achieve resource sharing during the signaling of these to achieve resource sharing during the signaling of these
protecting LSPs, they MUST have the same Tunnel Endpoint Address protecting LSPs, they have the same Tunnel Endpoint Address
(as part of their SESSION object). (as part of their SESSION object).
However, these addresses are not the same in this example. However, these addresses are not the same in this example.
Similar to SMR, this document defines a new LSP Protection Type of Similar to SMR, this document defines a new LSP Protection Type of
the secondary LSP as "Shared Mesh Protection" the secondary LSP as "Shared Mesh Protection"
(see <xref target="secUpPt"/>) (see <xref target="secUpPt" format="default"/>)
to allow resource sharing along nodes E, F, and G. to allow resource sharing along nodes E, F, and G.
Examples of shared resources include the capacity of a link and Examples of shared resources include the capacity of a link and
the cross-connects in a node. the cross-connects in a node.
In this case, the protecting LSPs In this case, the protecting LSPs
are not merged (which is useful since the paths diverge at G), but are not merged (which is useful, since the paths diverge at G), but
the resources along E, F, G can be shared. the resources along E, F, and G can be shared.
</t> </t>
<t> <t>
When a failure, such as Signal Fail (SF) and Signal Degrade (SD), When a failure, such as Signal Fail (SF) or Signal Degrade (SD),
occurs on one of the working LSPs (say working LSP [A,B,C,D]), occurs on one of the working LSPs (say, working LSP [A,B,C,D]),
the end node (say node A) that detects the failure initiates the end node (say, node A) that detects the failure initiates
the protection switching operation. the protection switching operation.
End node A will send a protection switching request APS message End node A will send a protection switching request APS message
(for example, SF) to its adjacent (downstream) intermediate node (say node E) (for example, SF) to its adjacent (downstream) intermediate node (say, node E )
to activate the corresponding protecting LSP to activate the corresponding protecting LSP
and will wait for a confirmation message from node E. and will wait for a confirmation message from node E.
</t> </t>
<t> <t>
If the protection resource is available, node E will send the confirmation If the protection resource is available, node E will send the confirmation
APS message to the end node A and forward the switching request APS message APS message to the end node (node A) and forward the switching request APS me
to its adjacent (downstream) node (say node F). ssage
to its adjacent (downstream) node (say, node F).
When the confirmation APS message is received by node A, the When the confirmation APS message is received by node A, the
cross-connection on node A is established. cross-connection on node A is established.
At this time traffic is bridged to and selected from the protecting LSP At this time, traffic is bridged to and selected from the protecting LSP
at node A. at node A.
After forwarding the switching request APS message, node E will wait for 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 a confirmation APS message from node F, which triggers node E to set up
the cross-connection for the protecting LSP being activated. the cross-connection for the protecting LSP being activated.
</t> </t>
<t> <t>
If the protection resource is not available (due to failure or being If the protection resource is not available (due to failure or being
used by higher priority connections), the switching will not be successful; used by higher-priority connections), the switching will not be successful;
the intermediate node (node E) MUST send a message to notify the end node the intermediate node (node E) <bcp14>MUST</bcp14> send a message to notify t
(node A) (see <xref target="secGmplsNotify"/>). he end node
If the resource is in use by a lower priority protecting LSP, the (node A) (see <xref target="secGmplsNotify" format="default"/>).
lower priority service will be removed and then the intermediate node If the resource is in use by a lower-priority protecting LSP, the
will follow the procedure as described for the case when the protection lower-priority service will be removed, and the intermediate node
resource is available for the higher priority protecting LSP. will then follow the procedure as described for the case when the protection
</t> resource is available for the higher-priority protecting LSP.
<t> </t>
<t>
If node E fails to allocate the protection resource, If node E fails to allocate the protection resource,
it MUST send a message to notify node A it <bcp14>MUST</bcp14> send a message to notify node A
(see <xref target="secGmplsNotify"/>). (see <xref target="secGmplsNotify" format="default"/>).
Then, node A will stop bridging and selecting traffic to/from Then, node A will stop bridging and selecting traffic to/from
the protecting LSP and proceed with the procedure of removing the protecting LSP and proceed with the procedure of removing
the protection allocation according to the APS protocol. the protection allocation according to the APS protocol.
</t> </t>
</section> </section>
<section anchor="secGmpls" numbered="true" toc="default">
<section anchor="secGmpls" <name>GMPLS Signaling Extensions for SMP</name>
title="GMPLS Signaling Extension for SMP"> <t>
<t>
The following subsections detail how LSPs using SMP can be The following subsections detail how LSPs using SMP can be
signaled in an interoperable fashion using GMPLS RSVP-TE signaled in an interoperable fashion using GMPLS RSVP-TE
extensions (see RFC 3473 <xref target="RFC3473"/>). extensions (see RFC 3473 <xref target="RFC3473" format="default"/>).
This signaling enables: This signaling enables:
<list style="empty"> </t>
<t>(1) the ability to identify a "secondary protecting LSP" <ol type="(%d)" spacing="normal">
(LSP [A,E,F,G,D] or LSP [H,E,F,G,K] from <xref target="figEx"/>, <li>the ability to identify a "secondary protecting LSP"
hereby called the "secondary LSP") used to recover (LSP [A,E,F,G,D] or LSP [H,E,F,G,K] from <xref target="figEx" format="defau
lt"/>,
here called the "secondary LSP") used to recover
another "primary working LSP" another "primary working LSP"
(LSP [A,B,C,D] or LSP [H,I,J,K] from <xref target="figEx"/>, (LSP [A,B,C,D] or LSP [H,I,J,K] from <xref target="figEx" format="default"/
hereby called the "protected LSP"), >,
</t> here called the "protected LSP"),
<t>(2) the ability to associate the secondary LSP with the protected LSP, </li>
</t> <li>the ability to associate the secondary LSP with the protected LSP,
<t>(3) the capability to include information about the resources </li>
<li>the capability to include information about the resources
used by the protected LSP while instantiating the secondary LSP, used by the protected LSP while instantiating the secondary LSP,
</t> </li>
<t>(4) the capability to instantiate during the provisioning phase <li>the capability to instantiate
several secondary LSPs efficiently, and several secondary LSPs efficiently during the provisioning phase, and
</t> </li>
<t>(5) the capability to support activation of a secondary LSP after <li>the capability to support activation of a secondary LSP via the APS
failure occurrence via APS protocol in the data plane. protocol in the data plane if a failure occurs.
</t> </li>
</list> </ol>
</t> <section anchor="secGmplsId" numbered="true" toc="default">
<name>Identifiers</name>
<section anchor="secGmplsId" title="Identifiers"> <t>
<t> To simplify association operations, both LSPs (i.e., the protected LSP
To simplify association operations, both LSPs (i.e., the protected and the secondary LSP) belong to the same session.
and the secondary LSPs) belong to the same session. Thus, the SESSION object <bcp14>MUST</bcp14> be the same for both LSPs.
Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, however, <bcp14>MUST</bcp14> be different to distinguish between
The LSP ID, however, MUST be different to distinguish between the protected the protected
LSP and the secondary LSP. LSP and the secondary LSP.
</t> </t>
<t> <t>
A new LSP Protection Type "Shared Mesh Protection" is defined A new LSP Protection Type, "Shared Mesh Protection", is defined
(see <xref target="secUpPt"/>) (see <xref target="secUpPt" format="default"/>)
for the LSP Flags of PROTECTION object (see <xref target="RFC4872"/>) for the LSP Flags field of the PROTECTION object (see <xref target="RFC4872"
format="default"/>)
to set up the two LSPs. to set up the two LSPs.
This LSP Protection Type value is applicable only to This LSP Protection Type value is only applicable to
bidirectional LSPs as required in <xref target="G808.3"/>. bidirectional LSPs as required in <xref target="G808.3" format="default"/>.
</t> </t>
</section> </section>
<section anchor="secGmplsPrim" numbered="true" toc="default">
<section anchor="secGmplsPrim" title="Signaling Primary LSPs"> <name>Signaling Primary LSPs</name>
<t> <t>
The PROTECTION object (see <xref target="RFC4872"/>) is included The PROTECTION object (see <xref target="RFC4872" format="default"/>) is incl
uded
in the Path message during signaling of the primary working LSPs, in the Path message during signaling of the primary working LSPs,
with the LSP Protection Type value set to "Shared Mesh Protection". with the LSP Protection Type value set to "Shared Mesh Protection".
</t> </t>
<t> <t>
Primary working LSPs are signaled by setting in the PROTECTION 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, and in the object the S bit to 0, the P bit to 0, and the N bit to 1; and setting in the
ASSOCIATION object, the Association ID to the associated secondary ASSOCIATION object the Association ID to the associated secondary
protecting LSP_ID. protecting LSP_ID.
</t> </t>
<t> <aside><t>
Note: N bit is set to indicate that the protection switching Note: The N bit is set to indicate that the protection switching
signaling is done via data plane. signaling is done via the data plane.
</t> </t></aside>
</section> </section>
<section anchor="secGmplsSecd" numbered="true" toc="default">
<section anchor="secGmplsSecd" title="Signaling Secondary LSPs"> <name>Signaling Secondary LSPs</name>
<t> <t>
The PROTECTION object (see <xref target="RFC4872"/>) is included in the Path The PROTECTION object (see <xref target="RFC4872" format="default"/>) is incl
uded in the Path
message during signaling of the secondary protecting LSPs, with message during signaling of the secondary protecting LSPs, with
the LSP Protection Type value set to "Shared Mesh Protection". the LSP Protection Type value set to "Shared Mesh Protection".
</t> </t>
<t> <t>
Secondary protecting LSPs are signaled by setting in the Secondary protecting LSPs are signaled by setting in the
PROTECTION object the S bit, the P bit, and the N bit to 1, and PROTECTION object the S bit, the P bit, and the N bit to 1; and setting
in the ASSOCIATION object, the Association ID to the associated in the ASSOCIATION object the Association ID to the associated
primary working LSP_ID, which MUST be known before signaling of primary working LSP_ID, which <bcp14>MUST</bcp14> be known before signaling o
f
the secondary LSP. the secondary LSP.
Moreover, the Path message used to instantiate Moreover, the Path message used to instantiate
the secondary LSP MUST include at least one PRIMARY_PATH_ROUTE the secondary LSP <bcp14>MUST</bcp14> include at least one PRIMARY_PATH_ROUTE
object (see <xref target="RFC4872"/>) that further allows for object (see <xref target="RFC4872" format="default"/>) that further allows fo
r
recovery resource sharing at each intermediate node recovery resource sharing at each intermediate node
along the secondary path. along the secondary path.
</t> </t>
<t> <t>
With this setting, the resources for the secondary LSP MUST be With this setting, the resources for the secondary LSP <bcp14>MUST</bcp14> be
pre-reserved, but not committed at the data plane level, meaning pre-reserved but not committed at the data plane level, meaning
that the internals of the switch need not be established until that the internals of the switch need not be established until
explicit action is taken to activate this LSP. Activation of a explicit action is taken to activate this LSP. Activation of a
secondary LSP and protection switching to the activated protecting secondary LSP and protection switching to the activated protecting
LSP is done using APS protocol in the data plane. LSP is done using the APS protocol in the data plane.
</t> </t>
<t> <t>
After protection switching completes the protecting LSP MUST be After protection switching completes, the protecting LSP <bcp14>MUST</bcp14>
signaled with the S bit set to 0 and O bit set to 1 in the be
PROTECTION object. At this point, the link and node resources MUST signaled by setting the S bit to 0 and the O bit to 1 in the
be allocated for this LSP that becomes a primary LSP (ready to PROTECTION object. At this point, the link and node resources <bcp14>MUST</bc
p14>
be allocated for this LSP, which becomes a primary LSP (ready to
carry traffic). carry traffic).
The formerly working LSP MAY be signaled with the A bit set in the The formerly working LSP <bcp14>MAY</bcp14> be signaled with the A bit set in
ADMIN_STATUS object (see <xref target="RFC3473"/>). the
</t> ADMIN_STATUS object (see <xref target="RFC3473" format="default"/>).
<t> </t>
Support for extra traffic in SMP is for further study. <t>
Support for extra traffic in SMP is left for further study.
Therefore, mechanisms to set up LSPs for extra traffic Therefore, mechanisms to set up LSPs for extra traffic
are outside the scope of this document. are outside the scope of this document.
</t> </t>
</section> </section>
<section anchor="secGmplsPrio" numbered="true" toc="default">
<section anchor="secGmplsPrio" title="SMP Preemption Priority"> <name>SMP Preemption Priority</name>
<t> <t>
The SMP preemption priority of a protecting LSP that the APS protocol The SMP preemption priority of a protecting LSP is used by the APS protocol
uses to resolve the competition for shared resources among multiple to resolve competition for shared resources among multiple
protecting LSPs, is indicated in Preemption Priority field of the protecting LSPs and is indicated in the Preemption Priority field of the
PROTECTION object in the Path message of the protecting LSP. PROTECTION object in the Path message of the protecting LSP.
</t> </t>
<t> <t>
The Setup and Holding priorities in the SESSION_ATTRIBUTE The Setup and Holding priorities in the SESSION_ATTRIBUTE
object can be used by GMPLS to control LSP preemption, but, they are object can be used by GMPLS to control LSP preemption, but they are
not used by the APS to resolve the competition among multiple not used by the APS to resolve competition among multiple
protecting LSPs. This avoids the need to define a complex policy for protecting LSPs. This avoids the need to define a complex policy for
defining Setup and Holding priorities when used for both GMPLS defining Setup and Holding priorities when used for both GMPLS
control plane LSP preemption and SMP shared resource competition control plane LSP preemption and SMP shared resource competition
resolution. resolution.
</t> </t>
<t> <t>
When an intermediate node on the protecting LSP receives the Path When an intermediate node on the protecting LSP receives the Path
message, the priority value in the Preemption Priority field MUST be message, the priority value in the Preemption Priority field <bcp14>MUST</bcp 14> be
stored for that protecting LSP. When resource competition among stored for that protecting LSP. When resource competition among
multiple protecting LSPs occurs, the APS protocol will use their multiple protecting LSPs occurs, the APS protocol will use their
priority values to resolve the competition. priority values to resolve this competition.
A lower value has a higher priority. A lower value has a higher priority.
</t> </t>
<t> <t>
In SMP, a preempted LSP MUST NOT be terminated even after its resources In SMP, a preempted LSP <bcp14>MUST NOT</bcp14> be terminated even after its
resources
have been deallocated. Once the working have been deallocated. Once the working
LSP and the protecting LSP are configured or pre-configured, the end LSP and the protecting LSP are configured or preconfigured, the end
node MUST keep refreshing both working and protecting LSPs node <bcp14>MUST</bcp14> keep refreshing both working and protecting LSPs,
regardless of failure or preempted situation. regardless of failure or preemption status.
</t> </t>
</section> </section>
<section anchor="secGmplsNotify" numbered="true" toc="default">
<name>Availability of Shared Resources: The Notify Message</name>
<section anchor="secGmplsNotify" <t>
title="Notifying Availability of Shared Resources"> When a lower-priority protecting LSP is preempted, the intermediate
<t> node that performed the preemption <bcp14>MUST</bcp14> send a Notify message
When a lower priority protecting LSP is preempted, the intermediate with
node that performed preemption MUST send a Notify message with error code "Notify Error" (25) (see <xref target="RFC4872"/>) and
error code "Notify Error" (25) (see [RFC4872]) and error sub-code "Shared resources unavailable" (17)
error sub-code "Shared resources unavailable" (TBA1)
to the end nodes of that protecting LSP. to the end nodes of that protecting LSP.
Upon receipt of this Notify message, the end node MUST stop sending and Upon receipt of this Notify message, the end node <bcp14>MUST</bcp14> stop se nding and
selecting traffic to/from its protecting LSP and try switching selecting traffic to/from its protecting LSP and try switching
the traffic to another protecting LSP, if available. the traffic to another protecting LSP, if available.
</t> </t>
<t> <t>
When a protecting LSP occupies the shared resources When a protecting LSP occupies the shared resources
and they become unavailable, the same Notify message MUST be and they become unavailable, the same Notify message <bcp14>MUST</bcp14> be
generated by the intermediate node to all the end nodes of the generated by the intermediate node to all the end nodes of the
protecting LSPs that have lower SMP preemption priorities than the protecting LSPs that have lower SMP preemption priorities than the
one that has occupied the shared resources. one that has occupied the shared resources.
In case the shared resources become unavailable If the shared resources become unavailable
due to a failure in the shared resources, due to a failure in the shared resources,
the same Notify message MUST be generated by the intermediate node the same Notify message <bcp14>MUST</bcp14> be generated by the intermediate node
to all the end nodes of the protecting LSPs that have been configured to all the end nodes of the protecting LSPs that have been configured
to use the shared resources. to use the shared resources.
These end nodes, in case of a failure of the working LSP, In the case of a failure of the working LSP, these end nodes
MUST avoid trying to switch traffic to these protecting LSPs <bcp14>MUST</bcp14> avoid trying to switch traffic to these protecting LSPs
that have been configured to use the shared resources that have been configured to use the shared resources
and try switching the traffic to other protecting LSPs, if available. and try switching the traffic to other protecting LSPs, if available.
</t> </t>
<t> <t>
When the shared resources become available, a Notify message with When the shared resources become available, a Notify message with
error code "Notify Error" (25) and error code "Notify Error" (25) and
error sub-code "Shared resources available" (TBA2) error sub-code "Shared resources available" (18)
MUST be generated by the intermediate node. The recipients of this <bcp14>MUST</bcp14> be generated by the intermediate node. The recipients of
Notify message are the end nodes of the lower priority protecting this
Notify message are the end nodes of the lower-priority protecting
LSPs that have been preempted and/or all the end nodes of the LSPs that have been preempted and/or all the end nodes of the
protecting LSPs that have lower SMP preemption priorities than the protecting LSPs that have lower SMP preemption priorities than the
one that does not need the shared resources anymore. one that does not need the shared resources anymore.
Upon receipt of this Notify message, the end node is allowed to Upon receipt of this Notify message, the end node is allowed to
reinitiate the protection switching operation as described in reinitiate the protection switching operation as described in
<xref target="secSmpOper"/>, if it still needs the protection <xref target="secSmpOper" format="default"/>, if it still needs the protectio n
resource. resource.
</t> </t>
</section> </section>
<section anchor="secGmplsAps" numbered="true" toc="default">
<section anchor="secGmplsAps" title="SMP APS Configuration"> <name>SMP APS Configuration</name>
<t> <t>
SMP relies on APS protocol messages being exchanged between the nodes SMP relies on APS protocol messages being exchanged between the nodes
along the path to activate an SMP protecting LSP. along the path to activate a protecting LSP.
</t> </t>
<t> <t>
In order to allow the exchange of APS protocol messages, In order to allow the exchange of APS protocol messages,
an APS channel has to be configured between adjacent nodes an APS channel has to be configured between adjacent nodes
along the path of the SMP protecting LSP. along the path of the protecting LSP.
This is done by other means than GMPLS signaling, This is done by means other than GMPLS signaling,
before any SMP protecting LSP has been set up. before any protecting LSP has been set up.
Therefore, there are likely additional requirements for APS configuration Therefore, there are likely additional requirements for APS configuration
which are outside the scope of this document. that are outside the scope of this document.
</t> </t>
<t> <t>
Depending on the APS protocol message format, Depending on the APS protocol message format,
the APS protocol may use different identifiers than GMPLS signaling the APS protocol may use different identifiers than GMPLS signaling
to identify the SMP protecting LSP. to identify the protecting LSP.
</t> </t>
<t> <t>
Since APS protocol is for further study in <xref target="G808.3"/>, Since the APS protocol is left for further study per <xref target="G808.3" fo
it can be assumed that APS message format and identifiers are rmat="default"/>,
technology-specific and/or vendor-specific. it can be assumed that the APS message format and identifiers are
technology specific and/or vendor specific.
Therefore, additional requirements for APS configuration Therefore, additional requirements for APS configuration
are outside the scope of this document. are outside the scope of this document.
</t> </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>
</section>
<section anchor="secUp" title="Updates to PROTECTION Object"> <section anchor="secUp" numbered="true" toc="default">
<t> <name>Updates to PROTECTION Object</name>
<t>
GMPLS extension requirements for SMP introduce several updates to GMPLS extension requirements for SMP introduce several updates to
the Protection Object (see <xref target="RFC4872"/>). the PROTECTION object (see <xref target="RFC4872" format="default"/>), as
</t> detailed below.
<section anchor="secUpPt" title="New Protection Type"> </t>
<t> <section anchor="secUpPt" numbered="true" toc="default">
A new LSP protection type "Shared Mesh Protection" is added in the <name>New Protection Type</name>
PROTECTION object. This LSP Protection Type value is applicable to <t>
only bidirectional LSPs. A new LSP Protection Type, "Shared Mesh Protection", is added in the
</t> PROTECTION object. This LSP Protection Type value is only applicable to
<t> bidirectional LSPs.
</t>
<t>
LSP (Protection Type) Flags: LSP (Protection Type) Flags:
<list style="empty"> </t>
<t>0x20: Shared Mesh Protection </t> <t indent="3">
</list> 0x20: Shared Mesh Protection
</t> </t>
<t> <t>
The rules defined in Section 14.2 of <xref target="RFC4872"/> ensure The rules defined in <xref target="RFC4872" sectionFormat="of" section="14.2"
that all the nodes along an SMP LSP are SMP aware. />
Therefore, there are no backward compatibility issues. ensure that all the nodes along an SMP LSP are SMP aware.
</t> Therefore, there are no backward-compatibility issues.
</section> </t>
</section>
<section anchor="secUpNO" title="Updates on Notification and Operational Bits"> <section anchor="secUpNO" numbered="true" toc="default">
<t> <name>Updates to Definitions of Notification and Operational Bits</name>
The definitions of the N and O bits in Section 14.1 of <t>
<xref target="RFC4872"/> The definitions of the N and O bits in <xref target="RFC4872" sectionFormat="
are replaced as follows: of" section="14.1"/> are replaced as follows:
</t> </t>
<t> <t>
Notification (N): 1 bit Notification (N): 1 bit
<list style="empty"> </t>
<t> <t indent="3">
When set to 1, this bit indicates that the control plane message When set to 1, this bit indicates that the control plane message
exchange is only used for notification during protection exchange is only used for notification during protection
switching. When set to 0 (default), it indicates that the control switching. When set to 0 (default), it indicates that the control
plane message exchanges are used for protection-switching plane message exchanges are used for purposes of protection switching.
purposes. The N bit is only applicable when the LSP Protection The N bit is only applicable when the LSP Protection
Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), Type Flag is set to 0x04 (1:N Protection with Extra-Traffic),
0x08 (1+1 Unidirectional Protection), 0x08 (1+1 Unidirectional Protection),
0x10 (1+1 Bidirectional Protection), 0x10 (1+1 Bidirectional Protection),
or 0x20 (Shared Mesh Protection). or 0x20 (Shared Mesh Protection).
The N bit MUST be set to 0 in any other case. The N bit <bcp14>MUST</bcp14> be set to 0 in any other case.
If 0x20 (SMP), the N bit MUST be set to 1. If 0x20 (SMP), the N bit <bcp14>MUST</bcp14> be set to 1.
</t> </t>
</list> <t>
</t>
<t>
Operational (O): 1 bit Operational (O): 1 bit
<list style="empty"> </t>
<t> <t indent="3">
When set to 1, this bit indicates that the protecting LSP is When set to 1, this bit indicates that the protecting LSP is
carrying traffic after protection switching. The O bit carrying traffic after protection switching. The O bit
is only applicable when the P bit is set to 1, and the LSP is only applicable when (1) the P bit is set to 1 and (2) the LSP
Protection Type Flag is set to 0x04 (1:N Protection with Protection Type Flag is set to 0x04 (1:N Protection with
Extra-Traffic), 0x08 (1+1 Unidirectional Protection), 0x10 Extra-Traffic), 0x08 (1+1 Unidirectional Protection), 0x10
(1+1 Bidirectional Protection), or 0x20 (Shared Mesh Protection). (1+1 Bidirectional Protection), or 0x20 (Shared Mesh Protection).
The O bit MUST be set to 0 in any other case. The O bit <bcp14>MUST</bcp14> be set to 0 in any other case.
</t> </t>
</list> </section>
</t> <section anchor="secUpPP" numbered="true" toc="default">
</section> <name>Preemption Priority</name>
<t>
<section anchor="secUpPP" title="Preemption Priority"> <xref target="RFC4872" format="default"/> reserved a 32-bit field in the PROT
<t> ECTION object
<xref target="RFC4872"/> reserved a 32-bit field in the PROTECTION object header. Subsequently, <xref target="RFC4873" format="default"/> allocated sev
header. Subsequently, <xref target="RFC4873"/> allocated several fields eral bits
from that field, and left the remainder of the bits reserved. from that field and left the remainder of the bits reserved.
This specification further allocates the preemption priority field This specification further allocates the Preemption Priority field
from those formerly-reserved bits. from the remaining formerly reserved bits.
The 32-bit field in the PROTECTION object defined in The 32-bit field in the PROTECTION object as defined in <xref target="RFC4872
<xref target="RFC4873"/> "/> and modified by
are updated as follows: <xref target="RFC4873" format="default"/>
</t> is updated by this document as follows:
<figure> </t>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|R| Reserved | Seg.Flags | Reserved | Preempt Prio | |I|R| Reserved | Seg.Flags | Reserved | Preempt Prio |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <t>
Preemption Priority (Preempt Prio): 8 bits
<t> </t>
Preemption Priority (Preempt Prio): 8 bit <t indent="3">
<list style="empty">
<t>
This field indicates the SMP preemption priority of a protecting LSP, This field indicates the SMP preemption priority of a protecting LSP,
when the LSP Protection Type field indicates "Shared Mesh Protection". when the LSP Protection Type field indicates "Shared Mesh Protection".
The SMP preemption priority value is configured The SMP preemption priority value is configured
at the end nodes of the protecting LSP by a network operator. at the end nodes of the protecting LSP by a network operator.
A lower value has a higher priority. A lower value has a higher priority.
The decision of how many priority levels to be operated in an The decision regarding how many priority levels should be implemented in a
SMP network is a network operator's choice. n
</t> SMP network is left to network operators.
</list> </t>
</t> <t>
<t> See <xref target="RFC4873" format="default"/> for the definitions of the othe
See <xref target="RFC4873"/> for the definition of other fields. r fields.
</t> </t>
</section> </section>
</section>
</section> <section anchor="secIANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="secIANA" title="IANA Considerations"> <t>
<t> IANA maintains a group of registries called "Resource Reservation Protocol
<!-- (RSVP) Parameters", which includes the "Error Codes and
There are no IANA actions required by this document. Globally-Defined Error Value Sub-Codes" registry. IANA has added the followi
IANA actions required by this document will be described later. ng values to the "Sub-Codes - 25 Notify Error" subregistry, which lists error va
<!-- lue sub-codes that may be
This document requests IANA to define two new sub-code values used with error code 25. IANA has allocated the following
under "Notify Error" code in Resource Reservation Protocol (RSVP) parameters. error value sub-codes (<xref target="tab-1"/>) for use with this error code a
IANA maintains a registry called "Resource Reservation Protocol s described in
(RSVP) Parameters" with a subregistry called "Error Codes and
Globally-Defined Error Value Sub-Codes". Within this subregistry
there is a definition of the "Notify Error" error code (25).
The definition lists a number of error value sub-codes that may be
used with this error code. IANA is requested to allocate further
error value sub-codes for use with this error code as described in
this document. this document.
</t> </t>
<figure>
<artwork><![CDATA[
Value Description Reference
----- ---------------------------- ---------------
TBA1 Shared resources unavailable (this document)
TBA2 Shared resources available (this document)
]]></artwork>
</figure>
</section>
<section anchor="secSec" title="Security Considerations"> <table anchor="tab-1">
<t> <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</td>
<td>RFC 9270</td>
</tr>
<tr>
<td>18</td>
<td>Shared resources available</td>
<td>RFC 9270</td>
</tr>
</tbody>
</table>
</section>
<section anchor="secSec" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
Since this document makes use of the exchange of RSVP messages Since this document makes use of the exchange of RSVP messages
including a Notify message, the security threats discussed in that include a Notify message, the security threats discussed in
<xref target="RFC4872"/> also apply to this document. <xref target="RFC4872" format="default"/> also apply to this document.
</t> </t>
<t> <t>
Additionally, it may be possible to cause disruption to Additionally, it may be possible to cause disruption to
traffic on one protecting LSP by targeting a link used by the primary traffic on one protecting LSP by targeting a link used by the primary
LSP of another, higher priority LSP somewhere completely different in LSP of another, higher-priority LSP somewhere completely different in
the network. the network.
For example, in <xref target="figEx"/>, For example, in <xref target="figEx" format="default"/>,
assume that the preemption priority of LSP [A,E,F,G,D] is higher than 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 that of LSP [H,E,F,G,K] and the protecting LSP [H,E,F,G,K] is being
used to transport traffic. used to transport traffic.
If link B-C is attacked, traffic on LSP [H,E,F,G,K] can be disrupted. If link B-C is attacked, traffic on LSP [H,E,F,G,K] can be disrupted.
For this reason, it is For this reason, it is
important not only to use security mechanisms as discussed in important not only to use security mechanisms as discussed in
<xref target="RFC4872"/> but also to acknowledge that <xref target="RFC4872" format="default"/> but also to acknowledge that
detailed knowledge of a network's topology, including routes and priorities detailed knowledge of a network's topology, including routes and priorities
of LSPs, can help an attacker better target or improve the efficacy of of LSPs, can help an attacker better target or improve the efficacy of
an attack. an attack.
</t> </t>
</section> </section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3209.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3473.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4426.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4872.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4873.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<reference 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"/>
</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.R
FC.6372.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7412.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8776.xml"/>
<section anchor="Acknowledgements" title="Acknowledgements"> <!-- draft-ietf-teas-yang-te (I-D Exists)
<t>The authors would like to thank Adrian Farrel, Had to do "long way" to fix Vishnu's initials and Oscar's last name -->
Vishnu Pavan Beeram, Tom Petch, Ines Robles, John Scudder, Dale Worley, <reference anchor="YANG-TE">
Dan Romascanu, Eric Vyncke, Roman Danyliw, Paul Wouters, Lars Eggert, <front>
Francesca Palombini, and Robert Wilton <title>A YANG Data Model for Traffic Engineering Tunnels, Label Switched P
for their valuable comments and suggestions on this document. aths and Interfaces</title>
</t> <author initials="T." surname="Saad" fullname="Tarek Saad">
</section> <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="Internet-Draft" value="draft-ietf-teas-yang-te-29" />
</reference>
<section anchor="secCon" title="Contributor"> <reference anchor="G873.3" target="https://www.itu.int/rec/T-REC-G.873.3
<texttable align="left" style="none"> -201709-I/en">
<preamble> <front>
<title>Optical transport network - Shared mesh protection
</title>
<author>
<organization>International Telecommunication Union</organization>
</author>
<date month="September" year="2017"/>
</front>
<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 f
ullname="Dale Worley"/>,
<contact fullname="Dan Romascanu"/>, <contact fullname="Éric Vyncke"/>, <cont
act fullname="Roman Danyliw"/>, <contact fullname="Paul Wouters"/>, <contact ful
lname="Lars Eggert"/>,
<contact fullname="Francesca Palombini"/>, and <contact fullname="Robert Wilt
on"/>
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 The following person contributed significantly to the content of
this document and should be considered as a co-author. this document and should be considered a coauthor.
</preamble> </t>
<ttcol align="left"></ttcol> <contact fullname="Yuji Tochio">
<c>Yuji Tochio </c> <organization>Fujitsu</organization>
<c>Fujitsu </c> <address>
<c>Email: tochio@fujitsu.com </c> <email>tochio@fujitsu.com</email>
</texttable> </address>
</section> </contact>
</section>
</middle> </back>
<back>
<references title="Normative References">
&RFC2119;
&RFC3209;
&RFC3473;
&RFC4426;
&RFC4872;
&RFC4873;
&RFC8174;
<reference anchor="G808.3">
<front>
<title>Generic protection switching - Shared mesh protection
</title>
<author>
<organization>International Telecommunication Union</organization>
</author>
<date month="October" year="2012" />
</front>
<seriesInfo name="ITU-T" value="Recommendation G.808.3" />
</reference>
</references>
<references title="Informative References">
&RFC6372;
&RFC7412;
&RFC8776;
&I-D.ietf-teas-yang-te;
<reference anchor="G873.3">
<front>
<title>Optical transport network - Shared mesh protection
</title>
<author>
<organization>International Telecommunication Union</organization>
</author>
<date month="September" year="2017" />
</front>
<seriesInfo name="ITU-T" value="Recommendation G.873.3" />
</reference>
</references>
</back>
</rfc> </rfc>
 End of changes. 107 change blocks. 
594 lines changed or deleted 609 lines changed or added

This html diff was produced by rfcdiff 1.48.