draft-ietf-teas-gmpls-signaling-smp-10.txt   draft-ietf-teas-gmpls-signaling-smp-11.txt 
TEAS Working Group J. He TEAS Working Group J. He
Internet-Draft I. Busi Internet-Draft I. Busi
Updates: 4872, 4873 (if approved) Huawei Technologies Updates: 4872, 4873 (if approved) Huawei Technologies
Intended status: Standards Track J. Ryoo Intended status: Standards Track J. Ryoo
Expires: July 20, 2022 B. Yoon Expires: August 28, 2022 B. Yoon
ETRI ETRI
P. Park P. Park
KT KT
January 16, 2022 February 24, 2022
GMPLS Signaling Extensions for Shared Mesh Protection GMPLS Signaling Extensions for Shared Mesh Protection
draft-ietf-teas-gmpls-signaling-smp-10 draft-ietf-teas-gmpls-signaling-smp-11
Abstract Abstract
ITU-T Recommendation G.808.3 defines the generic aspects of a Shared ITU-T Recommendation G.808.3 defines the generic aspects of a Shared
Mesh Protection (SMP) mechanism, where the difference between SMP and Mesh Protection (SMP) mechanism, where the difference between SMP and
Shared Mesh Restoration (SMR) is also identified. ITU-T Shared Mesh Restoration (SMR) is also identified. ITU-T
Recommendation G.873.3 defines the protection switching operation and Recommendation G.873.3 defines the protection switching operation and
associated protocol for SMP at the Optical Data Unit (ODU) layer. associated protocol for SMP at the Optical Data Unit (ODU) layer.
RFC 7412 provides requirements for any mechanism that would be used RFC 7412 provides requirements for any mechanism that would be used
to implement SMP in a Multi-Protocol Label Switching - Transport to implement SMP in a Multi-Protocol Label Switching - Transport
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 20, 2022. This Internet-Draft will expire on August 28, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. SMP Definition . . . . . . . . . . . . . . . . . . . . . . . 4 3. SMP Definition . . . . . . . . . . . . . . . . . . . . . . . 4
4. Operation of SMP with GMPLS Signaling Extension . . . . . . . 5 4. Operation of SMP with GMPLS Signaling Extension . . . . . . . 5
5. GMPLS Signaling Extension for SMP . . . . . . . . . . . . . . 6 5. GMPLS Signaling Extension for SMP . . . . . . . . . . . . . . 6
5.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Signaling Primary LSPs . . . . . . . . . . . . . . . . . 7 5.2. Signaling Primary LSPs . . . . . . . . . . . . . . . . . 7
5.3. Signaling Secondary LSPs . . . . . . . . . . . . . . . . 7 5.3. Signaling Secondary LSPs . . . . . . . . . . . . . . . . 7
5.4. SMP Preemption Priority . . . . . . . . . . . . . . . . . 8 5.4. SMP Preemption Priority . . . . . . . . . . . . . . . . . 8
5.5. Notifying Availability of Shared Resources . . . . . . . 8 5.5. Notifying Availability of Shared Resources . . . . . . . 8
5.6. SMP APS Configuration . . . . . . . . . . . . . . . . . . 9 5.6. SMP APS Configuration . . . . . . . . . . . . . . . . . . 9
6. Updates to PROTECTION Object . . . . . . . . . . . . . . . . 9 6. Updates to PROTECTION Object . . . . . . . . . . . . . . . . 10
6.1. New Protection Type . . . . . . . . . . . . . . . . . . . 9 6.1. New Protection Type . . . . . . . . . . . . . . . . . . . 10
6.2. Updates on Notification and Operational Bits . . . . . . 10 6.2. Updates on Notification and Operational Bits . . . . . . 10
6.3. Preemption Priority . . . . . . . . . . . . . . . . . . . 10 6.3. Preemption Priority . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
10. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
RFC 4872 [RFC4872] defines extension of Resource Reservation Protocol RFC 4872 [RFC4872] defines extension of Resource Reservation Protocol
- Traffic Engineering (RSVP-TE) to support Shared Mesh Restoration - Traffic Engineering (RSVP-TE) to support Shared Mesh Restoration
(SMR) mechanisms. SMR can be seen as a particular case of pre- (SMR) mechanisms. SMR can be seen as a particular case of pre-
planned Label Switched Path (LSP) rerouting that reduces the recovery planned Label Switched Path (LSP) rerouting that reduces the recovery
resource requirements by allowing multiple protecting LSPs to share resource requirements by allowing multiple protecting LSPs to share
common link and node resources. The recovery resources for the common link and node resources. The recovery resources for the
protecting LSPs are pre-reserved during the provisioning phase, and protecting LSPs are pre-reserved during the provisioning phase, and
explicit restoration signaling is required to activate (i.e., commit explicit restoration signaling is required to activate (i.e., commit
resource allocation at the data plane) a specific protecting LSP resource allocation at the data plane) a specific protecting LSP that
instantiated during the provisioning phase. RFC 4873 [RFC4873] was instantiated during the provisioning phase. RFC 4873 [RFC4873]
details the encoding of the last 32-bit Reserved field of the details the encoding of the last 32-bit Reserved field of the
PROTECTION object defined in [RFC4872] PROTECTION object defined in [RFC4872]
ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of
a shared mesh protection (SMP) mechanism, which are not specific to a a shared mesh protection (SMP) mechanism, which are not specific to a
particular network technology in terms of architecture types, particular network technology in terms of architecture types,
preemption principle, and path monitoring methods, etc. ITU-T preemption principle, and path monitoring methods, etc. ITU-T
Recommendation G.873.3 [G873.3] defines the protection switching Recommendation G.873.3 [G873.3] defines the protection switching
operation and associated protocol for SMP at the Optical Data Unit operation and associated protocol for SMP at the Optical Data Unit
(ODU) layer. RFC 7412 [RFC7412] provides requirements for any (ODU) layer. RFC 7412 [RFC7412] provides requirements for any
skipping to change at page 4, line 10 skipping to change at page 4, line 10
o defines a new LSP protection type, "Shared Mesh Protection," for o defines a new LSP protection type, "Shared Mesh Protection," for
the LSP Flags field [RFC4872] of the PROTECTION object (see the LSP Flags field [RFC4872] of the PROTECTION object (see
Section 6.1), Section 6.1),
o updates the definitions of the Notification (N) and Operational o updates the definitions of the Notification (N) and Operational
(O) fields [RFC4872] of the PROTECTION object to take the new SMP (O) fields [RFC4872] of the PROTECTION object to take the new SMP
type into account (see Section 6.2), and type into account (see Section 6.2), and
o updates the definition of the 16-bit Reserved field [RFC4873] of o updates the definition of the 16-bit Reserved field [RFC4873] of
the PROTECTION object to take the new SMP type into account (see the PROTECTION object to allocate 8 bits to signal the SMP
Section 6.3). preemption priority (see Section 6.3).
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.
RFC 8776 [RFC8776] defines a collection of common YANG data types for
Traffic Engineering (TE) configuration and state capabilities. It
defines several identities for LSP protection types. As this
document introduces a new LSP Protection Type, [RFC8776] is expected
to be updated to support the SMP specified in this document.
[I-D.ietf-teas-yang-te] defines a YANG data model for the
provisioning and management of TE tunnels, LSPs, and interfaces. It
includes some protection and restoration data nodes relevant to this
document. Management aspects of the SMP are outside the scope of
this document, and they are expected to be addressed by other
documents.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
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 [RFC4872], RFC 4426 [RFC4426], and RFC 6372 terminology used in [RFC4872], RFC 4426 [RFC4426], and RFC 6372
skipping to change at page 4, line 41 skipping to change at page 5, line 4
[G808.3] defines the generic aspects of an SMP mechanism. [G873.3] [G808.3] defines the generic aspects of an SMP mechanism. [G873.3]
defines the protection switching operation and associated protocol defines the protection switching operation and associated protocol
for SMP at the ODU layer. [RFC7412] provides requirements for any for SMP at the ODU layer. [RFC7412] 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 a MPLS-TP network.
The SMP mechanism is based on pre-computed protecting LSPs that are The SMP mechanism is based on pre-computed protecting LSPs that are
pre-configured into the network elements. Pre-configuration here pre-configured into the network elements. Pre-configuration here
means pre-reserving resources for the protecting LSPs without means pre-reserving resources for the protecting LSPs without
activating a particular protecting LSP (e.g., in circuit networks, activating a particular protecting LSP (e.g., in circuit networks,
the cross-connects in the intermediate nodes of the protecting LSP the cross-connects in the intermediate nodes of the protecting LSP
are not pre-established). Pre-configuring but not activating a are not pre-established). Pre-configuring but not activating
protecting LSP allows the common link and node resources in the protecting LSPs allows link and node resources to be shared by the
protecting LSP to be shared by multiple working LSPs that are protecting LSPs of multiple working LSPs (that are themselves
physically (i.e., link, node, Shared Risk Link Group (SRLG), etc.) disjoint and thus unlikely to fail simultaneously). Protecting LSPs
disjoint. Protecting LSPs are activated in response to failures of are activated in response to failures of working LSPs or operator's
working LSPs or operator's commands by means of the APS protocol that commands by means of the APS protocol that operates in the data
operates in the data plane. The APS protocol messages are exchanged plane. The APS protocol messages are exchanged along the protecting
along the protecting LSP. SMP is always revertive. LSP. SMP is always revertive.
SMP has a lot of similarity to SMR except that the activation in case SMP has a lot of similarity to SMR except that the activation in case
of SMR is achieved by control plane signaling during the recovery of SMR is achieved by control plane signaling during the recovery
operation, while SMP is done by the APS protocol in the data plane. operation, while SMP is done by the APS protocol in the data plane.
SMP has advantages with regard to the recovery speed compared with SMP has advantages with regard to the recovery speed compared with
SMR. SMR.
4. Operation of SMP with GMPLS Signaling Extension 4. Operation of SMP with GMPLS Signaling Extension
Consider the following network topology: Consider the following network topology:
A---B---C---D A---B---C---D
\ / \ /
E---F---G E---F---G
skipping to change at page 5, line 35 skipping to change at page 5, line 46
addresses are not the same in this example. Similar to SMR, this addresses are not the same in this example. Similar to SMR, this
document defines a new LSP Protection Type of the secondary LSP as document defines a new LSP Protection Type of the secondary LSP as
"Shared Mesh Protection" (see Section 6.1) to allow resource sharing "Shared Mesh Protection" (see Section 6.1) to allow resource sharing
along nodes E, F, and G. Examples of shared resources include the along nodes E, F, and G. Examples of shared resources include the
capacity of a link and the cross-connects in a node. In this case, capacity of a link and the cross-connects in a node. In this case,
the protecting LSPs are not merged (which is useful since the paths the protecting LSPs are not merged (which is useful since the paths
diverge at G), but the resources along E, F, G can be shared. diverge at G), but the resources along E, F, G can be shared.
When a failure, such as Signal Fail (SF) and Signal Degrade (SD), When a failure, such as Signal Fail (SF) and Signal Degrade (SD),
occurs on one of the working LSPs (say working LSP [A,B,C,D]), the 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. End-node A will send a protection protection switching operation. End node A will send a protection
switching request APS message (for example, SF) to its adjacent switching request APS message (for example, SF) to its adjacent
(downstream) intermediate node (say node E) to activate the (downstream) intermediate node (say node E) to activate the
corresponding protecting LSP and will wait for a confirmation message corresponding protecting LSP and will wait for a confirmation message
from node E. from node E.
If the protection resource is available, node E will send the If the protection resource is available, node E will send the
confirmation APS message to the end-node A and forward the switching confirmation APS message to the end node A and forward the switching
request APS message to its adjacent (downstream) node (say node F). request APS message to its adjacent (downstream) node (say node F).
When the confirmation APS message is received by node A, the cross- When the confirmation APS message is received by node A, the cross-
connection on node A is established. At this time the traffic is connection on node A is established. At this time traffic is bridged
bridged to and selected from the protecting LSP at node A. After to and selected from the protecting LSP at node A. After forwarding
forwarding the switching request APS message, node E will wait for a the switching request APS message, node E will wait for a
confirmation APS message from node F, which triggers node E to set up 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.
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 used by higher priority connections), the switching will not be
successful; the intermediate node (node E) MUST send a message to successful; the intermediate node (node E) MUST send a message to
notify the end node (see Section 5.5). If the resource is in use by notify the end node (node A) (see Section 5.5). If the resource is
a lower priority protecting LSP, the lower priority service will be in use by a lower priority protecting LSP, the lower priority service
removed and then the intermediate node will follow the procedure as will be removed and then the intermediate node will follow the
described for the case when the protection resource is available for procedure as described for the case when the protection resource is
the higher priority protecting LSP. available for the higher priority protecting LSP.
If node E fails to allocate the protection resource, it MUST send a
message to notify node A (see Section 5.5). Then, node A will stop
bridging and selecting traffic to/from the protecting LSP and proceed
with the procedure of removing the protection allocation according to
the APS protocol.
5. GMPLS Signaling Extension for SMP 5. GMPLS Signaling Extension for SMP
The following subsections detail how LSPs using SMP can be signaled The following subsections detail how LSPs using SMP can be signaled
in an interoperable fashion using GMPLS RSVP-TE extensions (see RFC in an interoperable fashion using GMPLS RSVP-TE extensions (see RFC
3473 [RFC3473]). This includes: 3473 [RFC3473]). This signaling enables:
(1) the ability to identify a "secondary protecting LSP" (LSP (1) the ability to identify a "secondary protecting LSP" (LSP
[A,E,F,G,D] or LSP [H,E,F,G,K] from Figure 1, hereby called the [A,E,F,G,D] or LSP [H,E,F,G,K] from Figure 1, hereby called the
"secondary LSP") used to recover another "primary working LSP" "secondary LSP") used to recover another "primary working LSP"
(LSP [A,B,C,D] or LSP [H,I,J,K] from Figure 1, hereby called the (LSP [A,B,C,D] or LSP [H,I,J,K] from Figure 1, hereby called the
"protected LSP"), "protected LSP"),
(2) the ability to associate the secondary LSP with the protected (2) the ability to associate the secondary LSP with the protected
LSP, LSP,
skipping to change at page 6, line 43 skipping to change at page 7, line 10
several secondary LSPs in an efficient manner, and several secondary LSPs in an efficient manner, and
(5) the capability to support activation of a secondary LSP after (5) the capability to support activation of a secondary LSP after
failure occurrence via APS protocol in the data plane. failure occurrence via APS protocol in the data plane.
5.1. Identifiers 5.1. Identifiers
To simplify association operations, both LSPs (i.e., the protected To simplify association operations, both LSPs (i.e., the protected
and the secondary LSPs) belong to the same session. Thus, the and the secondary LSPs) belong to the same session. Thus, the
SESSION object MUST be the same for both LSPs. The LSP ID, however, SESSION object MUST be the same for both LSPs. The LSP ID, however,
MUST be different to distinguish between the protected LSP carrying MUST be different to distinguish between the protected LSP and the
normal traffic and the secondary LSP. secondary LSP.
A new LSP Protection Type "Shared Mesh Protection" is defined (see A new LSP Protection Type "Shared Mesh Protection" is defined (see
Section 6.1) for the LSP Flags of PROTECTION object (see [RFC4872]) Section 6.1) for the LSP Flags of PROTECTION object (see [RFC4872])
to set up the two LSPs. This LSP Protection Type value is applicable to set up the two LSPs. This LSP Protection Type value is applicable
only to bidirectional LSPs as required in [G808.3]. only to bidirectional LSPs as required in [G808.3].
5.2. Signaling Primary LSPs 5.2. Signaling Primary LSPs
The PROTECTION object (see [RFC4872]) is included in the Path message The PROTECTION object (see [RFC4872]) is included in the Path message
during signaling of the primary working LSPs, with the LSP Protection during signaling of the primary working LSPs, with the LSP Protection
skipping to change at page 7, line 44 skipping to change at page 8, line 8
With this setting, the resources for the secondary LSP MUST be pre- With this setting, the resources for the secondary LSP MUST be pre-
reserved, but not committed at the data plane level, meaning that the reserved, but not committed at the data plane level, meaning that the
internals of the switch need not be established until explicit action internals of the switch need not be established until explicit action
is taken to activate this LSP. Activation of a secondary LSP and is taken to activate this LSP. Activation of a secondary LSP and
protection switching to the activated protecting LSP is done using protection switching to the activated protecting LSP is done using
APS protocol in the data plane. APS protocol in the data plane.
After protection switching completes the protecting LSP MUST be After protection switching completes the protecting LSP MUST be
signaled with the S bit set to 0 and O bit set to 1 in the PROTECTION signaled with the S bit set to 0 and O bit set to 1 in the PROTECTION
object. At this point, the link and node resources MUST be allocated object. At this point, the link and node resources MUST be allocated
for this LSP that becomes a primary LSP (ready to carry normal for this LSP that becomes a primary LSP (ready to carry traffic).
traffic). The formerly working LSP MAY be signaled with the A bit The formerly working LSP MAY be signaled with the A bit set in the
set in the ADMIN_STATUS object (see [RFC3473]). ADMIN_STATUS object (see [RFC3473]).
Support for extra traffic in SMP is for further study. Therefore, Support for extra traffic in SMP is for further study. Therefore,
mechanisms to set up LSPs for extra traffic are also for further mechanisms to set up LSPs for extra traffic are outside the scope of
study. this document.
5.4. SMP Preemption Priority 5.4. SMP Preemption Priority
The SMP preemption priority of a protecting LSP that the APS protocol The SMP preemption priority of a protecting LSP that the APS protocol
uses to resolve the competition for shared resources among multiple uses to resolve the competition for shared resources among multiple
protecting LSPs, is indicated in Preemption Priority field of the protecting LSPs, is indicated in 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.
In SMP, the Setup and Holding priorities in the SESSION_ATTRIBUTE The Setup and Holding priorities in the SESSION_ATTRIBUTE object can
object can be used by GMPLS to control LSP preemption, but, they are be used by GMPLS to control LSP preemption, but, they are not used by
not used by the APS to resolve the competition among multiple the APS to resolve the competition among multiple protecting LSPs.
protecting LSPs. This avoids the need to define a complex policy for This avoids the need to define a complex policy for defining Setup
defining Setup and Holding priorities when used for both GMPLS and Holding priorities when used for both GMPLS control plane LSP
control plane LSP preemption and SMP shared resource competition preemption and SMP shared resource competition resolution.
resolution.
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 MUST 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 the competition. A lower value has a
higher priority.
In SMP, a preempted LSP MUST NOT be torn down. Once the working LSP In SMP, a preempted LSP MUST NOT be terminated even after its
and the protecting LSP are configured or pre-configured, the end node resources have been deallocated. Once the working LSP and the
MUST keep refreshing both working and protecting LSPs regardless of protecting LSP are configured or pre-configured, the end node MUST
keep refreshing both working and protecting LSPs regardless of
failure or preempted situation. failure or preempted situation.
5.5. Notifying Availability of Shared Resources 5.5. Notifying Availability of Shared Resources
When a lower priority protecting LSP is preempted, the intermediate When a lower priority protecting LSP is preempted, the intermediate
node that performed preemption MUST send a Notify message with error node that performed preemption MUST send a Notify message with error
code "Notify Error" (25) (see [RFC4872]) and error sub-code "Shared code "Notify Error" (25) (see [RFC4872]) and error sub-code "Shared
resources unavailable" (TBA1) to the end nodes of that protecting resources unavailable" (TBA1) to the end nodes of that protecting
LSP. Upon receipt of this Notify message, the end node MUST stop LSP. Upon receipt of this Notify message, the end node MUST stop
sending and selecting normal traffic to/from its protecting LSP and sending and selecting traffic to/from its protecting LSP and try
try switching the traffic to another protection LSP, if available. switching the traffic to another protecting LSP, if available.
When the shared resources become unavailable, including a case of the When a protecting LSP occupies the shared resources and they become
shared resources failure, the same Notify message MUST also be unavailable, the same Notify message MUST be generated by the
generated by the intermediate node to all the end nodes of the intermediate node to all the end nodes of the protecting LSPs that
protecting LSPs that have lower SMP preemption priorities than the have lower SMP preemption priorities than the one that has occupied
one that has occupied the shared resources. These end nodes, in case the shared resources. In case the shared resources become
of a failure of the working LSP, MUST avoid trying to switch the unavailable due to a failure in the shared resources, the same Notify
traffic to these protection LSPs that have been configured to use the message MUST be generated by the intermediate node to all the end
shared resources and try switching the traffic to other protection nodes of the protecting LSPs that have been configured to use the
LSPs, if available. shared resources. These end nodes, in case of a failure of the
working LSP, MUST avoid trying to switch traffic to these protecting
LSPs that have been configured to use the shared resources and try
switching the traffic to other protecting LSPs, if available.
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 sub-code "Shared resources error code "Notify Error" (25) and error sub-code "Shared resources
available" (TBA2) MUST be generated by the intermediate node. The available" (TBA2) MUST be generated by the intermediate node. The
recipients of this Notify message are the end nodes of the lower recipients of this Notify message are the end nodes of the lower
priority protecting LSPs that have been preempted and/or all the end priority protecting LSPs that have been preempted and/or all the end
nodes of the protecting LSPs that have lower SMP preemption nodes of the protecting LSPs that have lower SMP preemption
priorities than the one that does not need the shared resources any priorities than the one that does not need the shared resources any
more. Upon receipt of this Notify message, the end node is allowed more. Upon receipt of this Notify message, the end node is allowed
to reinitiate the protection switching operation as described in to reinitiate the protection switching operation as described in
Section 4, if it still needs the protection resource. Section 4, if it still needs the protection resource.
5.6. SMP APS Configuration 5.6. SMP APS Configuration
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 an SMP protecting LSP.
In order to allow exchange of APS protocol messages, an APS channel In order to allow the exchange of APS protocol messages, an APS
has to be configured between adjacent nodes along the path of the SMP channel has to be configured between adjacent nodes along the path of
protecting LSP. This should be done before any SMP protecting LSP the SMP protecting LSP. This is done by other means than GMPLS
has been set up by other means than GMPLS signaling which are signaling, before any SMP protecting LSP has been set up. Therefore,
therefore outside the scope of this document. there are likely additional requirements for APS configuration which
are outside the scope of this document.
Depending on the APS protocol message format, the APS protocol may Depending on the APS protocol message format, the APS protocol may
use different identifiers than GMPLS signaling to identify the SMP use different identifiers than GMPLS signaling to identify the SMP
protecting LSP. protecting LSP.
Since APS protocol is for further study in [G808.3], it can be Since APS protocol is for further study in [G808.3], it can be
assumed that APS message format and identifiers are technology- assumed that APS message format and identifiers are technology-
specific and/or vendor-specific. Therefore, additional requirements specific and/or vendor-specific. Therefore, additional requirements
for APS configuration are outside the scope of this document. for APS configuration are outside the scope of this document.
skipping to change at page 10, line 26 skipping to change at page 10, line 45
purposes. The N bit is only applicable when the LSP Protection purposes. 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), 0x10 (1+1 Bidirectional 0x08 (1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional
Protection), or 0x20 (Shared Mesh Protection). If 0x20 (SMP), the Protection), or 0x20 (Shared Mesh Protection). If 0x20 (SMP), the
N bit MUST be set to 1. The N bit MUST be set to 0 in any other N bit MUST be set to 1. The N bit MUST be set to 0 in any other
case. case.
Operational (O): 1 bit Operational (O): 1 bit
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 the normal traffic after protection switching. The O bit carrying traffic after protection switching. The O bit is only
is only applicable when the P bit is set to 1, and the LSP applicable when the P bit is set to 1, and the LSP Protection Type
Protection Type Flag is set to 0x04 (1:N Protection with Extra- Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 (1+1
Traffic), 0x08 (1+1 Unidirectional Protection), 0x10 (1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional Protection),
Bidirectional Protection), or 0x20 (Shared Mesh Protection). The or 0x20 (Shared Mesh Protection). The O bit MUST be set to 0 in
O bit MUST be set to 0 in any other case. any other case.
6.3. Preemption Priority 6.3. Preemption Priority
In order to indicate the SMP preemption priority, the 16-bit Reserved In order to indicate the SMP preemption priority, the 16-bit Reserved
field [RFC4873] of the PROTECTION object is redefined. The last 32 field [RFC4873] of the PROTECTION object is redefined. The last 32
bits in the PROTECTION object defined in [RFC4873] are updated as bits in the PROTECTION object defined in [RFC4873] are updated as
follows: follows:
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
skipping to change at page 11, line 45 skipping to change at page 12, line 19
priority of LSP [A,E,F,G,D] is higher than that of LSP [H,E,F,G,K] priority of LSP [A,E,F,G,D] is higher than that of LSP [H,E,F,G,K]
and the protecting LSP [H,E,F,G,K] is being used to transport and the protecting LSP [H,E,F,G,K] is being used to transport
traffic. If link B-C is attacked, traffic on LSP [H,E,F,G,K] can be traffic. If link B-C is attacked, traffic on LSP [H,E,F,G,K] can be
disrupted. For this reason, it is important not only to use security disrupted. For this reason, it is important not only to use security
mechanisms as discussed in [RFC4872] but also to preserve privacy of mechanisms as discussed in [RFC4872] but also to preserve privacy of
information about protecting LSPs within the network. information about protecting LSPs within the network.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Adrian Farrel, Vishnu Pavan Beeram, The authors would like to thank Adrian Farrel, Vishnu Pavan Beeram,
Tom Petch, Ines Robles, and John Scudder for their valuable comments Tom Petch, Ines Robles, John Scudder, Dale Worley, and Dan Romascanu
and suggestions on this document. for their valuable comments and suggestions on this document.
10. Contributor 10. Contributor
The following person contributed significantly to the content of this The following person contributed significantly to the content of this
document and should be considered as a co-author. document and should be considered as a co-author.
Yuji Tochio Yuji Tochio
Fujitsu Fujitsu
Email: tochio@fujitsu.com Email: tochio@fujitsu.com
11. References 11. References
11.1. Normative References 11.1. Normative References
[G808.3] International Telecommunication Union, "Generic protection [G808.3] International Telecommunication Union, "Generic protection
switching - Shared mesh protection", ITU-T Recommendation switching - Shared mesh protection", ITU-T Recommendation
G.08.3, October 2012. G.808.3, October 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
skipping to change at page 13, line 15 skipping to change at page 13, line 37
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[G873.3] International Telecommunication Union, "Optical transport [G873.3] International Telecommunication Union, "Optical transport
network - Shared mesh protection", ITU-T Recommendation network - Shared mesh protection", ITU-T Recommendation
G.873.3, September 2017. G.873.3, September 2017.
[I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I.,
and O. G. D. Dios, "A YANG Data Model for Traffic
Engineering Tunnels, Label Switched Paths and Interfaces",
draft-ietf-teas-yang-te-29 (work in progress), February
2022.
[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
Profile (MPLS-TP) Survivability Framework", RFC 6372, Profile (MPLS-TP) Survivability Framework", RFC 6372,
DOI 10.17487/RFC6372, September 2011, DOI 10.17487/RFC6372, September 2011,
<https://www.rfc-editor.org/info/rfc6372>. <https://www.rfc-editor.org/info/rfc6372>.
[RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G. [RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G.
Mirsky, "Requirements for MPLS Transport Profile (MPLS-TP) Mirsky, "Requirements for MPLS Transport Profile (MPLS-TP)
Shared Mesh Protection", RFC 7412, DOI 10.17487/RFC7412, Shared Mesh Protection", RFC 7412, DOI 10.17487/RFC7412,
December 2014, <https://www.rfc-editor.org/info/rfc7412>. December 2014, <https://www.rfc-editor.org/info/rfc7412>.
[RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"Common YANG Data Types for Traffic Engineering",
RFC 8776, DOI 10.17487/RFC8776, June 2020,
<https://www.rfc-editor.org/info/rfc8776>.
Authors' Addresses Authors' Addresses
Jia He Jia He
Huawei Technologies Huawei Technologies
F3-1B, R&D Center, Huawei Industrial Base, Bantian, Longgang District F3-1B, R&D Center, Huawei Industrial Base, Bantian, Longgang District
Shenzhen Shenzhen
China China
Email: hejia@huawei.com Email: hejia@huawei.com
 End of changes. 33 change blocks. 
78 lines changed or deleted 112 lines changed or added

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