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 " "> | |||
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> | <!ENTITY zwsp "​"> | |||
<!ENTITY RFC3209 SYSTEM | <!ENTITY nbhy "‑"> | |||
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml"> | <!ENTITY wj "⁠"> | |||
<!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&D Center, Huawei Industrial Base, | <postal> | |||
Bantian, Longgang District</street> | <street>F3-1B, R&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 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. |