draft-ietf-teas-gmpls-signaling-smp-02.txt   draft-ietf-teas-gmpls-signaling-smp-03.txt 
TEAS Working Group J. He TEAS Working Group J. He
Internet-Draft I. Busi Internet-Draft I. Busi
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: July 10, 2020 J. Ryoo Expires: September 9, 2020 J. Ryoo
B. Yoon B. Yoon
ETRI ETRI
P. Park P. Park
KT KT
January 7, 2020 March 8, 2020
GMPLS Signaling Extensions for Shared Mesh Protection GMPLS Signaling Extensions for Shared Mesh Protection
draft-ietf-teas-gmpls-signaling-smp-02 draft-ietf-teas-gmpls-signaling-smp-03
Abstract Abstract
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, 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 [G873.3] defines the protection ITU-T Recommendation G.873.3 [G873.3] defines the protection
switching operation and associated protocol for SMP at the Optical switching operation and associated protocol for SMP at the Optical
Data Unit (ODU) layer. RFC 7412 [RFC7412] provides requirements for Data Unit (ODU) layer. RFC 7412 [RFC7412] provides requirements for
any mechanism that would be used to implement SMP in a Multi-Protocol any mechanism that would be used to implement SMP in a Multi-Protocol
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 10, 2020. This Internet-Draft will expire on September 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. SMP Definition . . . . . . . . . . . . . . . . . . . . . . . 3 3. SMP Definition . . . . . . . . . . . . . . . . . . . . . . . 3
4. GMPLS Signaling Extension for SMP . . . . . . . . . . . . . . 4 4. GMPLS Signaling Extension for SMP . . . . . . . . . . . . . . 4
4.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Signaling Primary LSPs . . . . . . . . . . . . . . . . . 6 4.2. Signaling Primary LSPs . . . . . . . . . . . . . . . . . 7
4.3. Signaling Secondary LSPs . . . . . . . . . . . . . . . . 6 4.3. Signaling Secondary LSPs . . . . . . . . . . . . . . . . 7
4.4. SMP APS Configuration . . . . . . . . . . . . . . . . . . 7 4.4. SMP APS Configuration . . . . . . . . . . . . . . . . . . 8
5. Updates to PROTECTION Object . . . . . . . . . . . . . . . . 8 5. Updates to PROTECTION Object . . . . . . . . . . . . . . . . 8
5.1. New Protection Type . . . . . . . . . . . . . . . . . . . 8 5.1. New Protection Type . . . . . . . . . . . . . . . . . . . 8
5.2. Other Updates . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Other Updates . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 25 skipping to change at page 3, line 25
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 the control plane working LSP fails, while the latter does it via the 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 appropriately during provisioning so that each node involved behaves appropriately
in the recovery phase when activation of a protecting LSP is done. in the recovery phase when activation of a protecting LSP is done.
This document updates [RFC4872] to provide the extensions to the This document updates [RFC4872] to provide the extensions to the
Generalized Multi-Protocol Label Switching (GMPLS) signaling to Generalized Multi-Protocol Label Switching (GMPLS) signaling to
support the control of the SMP mechanism. Only the generic aspects support the control of the SMP mechanism. Only the generic aspects
for signaling SMP are addressed by this document. The technology- for signaling SMP are addressed by this document. The technology-
specific aspects are expected to be addressed by other drafts. specific aspects 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
skipping to change at page 4, line 34 skipping to change at page 4, line 34
Figure 1: An example of SMP topology Figure 1: An example of SMP topology
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
[A,E,F,G,D] and [H,E,F,G,K], respectively. Per RFC 3209 [RFC3209], [A,E,F,G,D] and [H,E,F,G,K], respectively. Per RFC 3209 [RFC3209],
in order to achieve resource sharing during the signaling of these in order to achieve resource sharing during the signaling of these
protecting LSPs, they must have the same Tunnel Endpoint Address (as protecting LSPs, they must have the same Tunnel Endpoint Address (as
part of their SESSION object). However, these addresses are not the part of their SESSION object). However, these addresses are not the
same in this example. Similar to SMR, a new LSP Protection Type of same in this example. Similar to SMR, a new LSP Protection Type of
the secondary LSP is defined as "Shared Mesh Protection" (see the secondary LSP is defined as "Shared Mesh Protection" (see
PROTECTION object defined in [RFC4872]) to allow resource sharing Section 5.1) to allow resource sharing along nodes E, F, and G. In
along nodes E, F, and G. In this case, the protecting LSPs are not this case, the protecting LSPs are not merged (which is useful since
merged (which is useful since the paths diverge at G), but the the paths diverge at G), but the resources along E, F, G can be
resources along E, F, G can be shared. 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. The end-node A will send a protection switching operation. The end-node A will send a
protection switching request APS message (for example SF) to its protection switching request APS message (for example SF) to its
adjacent (downstream) intermediate node (say node E) to activate adjacent (downstream) intermediate node (say node E) to activate
setting up the corresponding protecting LSP and will wait for a setting up the corresponding protecting LSP and will wait for a
confirmation message from node E. If the protection resource is confirmation message from node E. If the protection resource is
available, node E will send the confirmation APS message to the end- available, node E will send the confirmation APS message to the end-
skipping to change at page 5, line 11 skipping to change at page 5, line 11
(downstream) node (say node F). When the confirmation APS message is (downstream) node (say node F). When the confirmation APS message is
received by node A, the cross-connection on node A is established. received by node A, the cross-connection on node A is established.
At this time the traffic is bridged to and selected from the At this time the traffic is bridged to and selected from the
protecting LSP at node A. After forwarding the switching request APS protecting LSP at node A. After forwarding the switching request APS
message, node E will wait for a confirmation APS message from node F, message, node E will wait for a confirmation APS message from node F,
which triggers node E to set up the cross-connection for the which triggers node E to set up the cross-connection for the
protecting LSP being activated. If the protection resource is not protecting LSP being activated. If the protection resource is not
available (due to failure or being used by higher priority available (due to failure or being used by higher priority
connections), the switching will not be successful; the intermediate connections), the switching will not be successful; the intermediate
node may send a message to notify the end node, or may keep trying node may send a message to notify the end node, or may keep trying
until the resource is available or the switching request is until the resource is available, or the switching request is
cancelled. If the resource is in use by a lower priority protecting cancelled. If the resource is in use by a lower priority protecting
LSP, the lower priority service will be removed and then the LSP, the lower priority service will be removed and then the
intermediate node will follow the procedure as described for the case intermediate node will follow the procedure as described for the case
when the protection resource is available for the higher priority when the protection resource is available for the higher priority
protecting LSP. protecting LSP.
The SMP preemption priority of a protecting LSP that the APS protocol
uses to resolve the competition for shared resources among multiple
protecting LSPs, is indicated in the TBD1 field of the PROTECTION
object in the Path message of the protecting LSP. In SMP, the Setup
and Holding priorities in the SESSION_ATTRIBUTE object can be used to
configure or pre-configure a LSP, but is irrelevant to resolving the
competition among multiple protecting LSPs, when controlled by the
APS.
When an intermediate node on the protecting LSP receives the Path
message, the preemption priority value in the TBD1 field MUST be
stored for that protecting LSP. When resource competition among
multiple protecting LSPs occurs, the APS protocol will use their
priority values to resolve the competition.
[EDITOR'S NOTE: The TBD1 field for the preemption priority will be
defined in the next version of this draft.]
In SMP, a preempted LSP SHOULD not be torn down. Once the working
LSP and the protecting LSP are configured or pre-configured, the end
node SHOULD keep refreshing both working and protecting LSPs
regardless of failure or preempted situation.
When a lower priority protecting LSP is preempted, the intermediate
node that performed preemption MAY send a Notify message with a new
sub-code "Shared resources unavailable" under "Notify Error" code
(see [RFC4872]) to the end nodes of that protecting LSP. Upon
receipt of this Notify message, the end node MAY stop sending and
selecting normal traffic to/from its protecting LSP and try switching
the traffic to another protection LSP, if available.
When the shared resources become unavailable, the same Notify message
MAY also be generated by the intermediate node to all the end nodes
of the protecting LSPs that have lower preemption priorities than the
one that has occupied the shared resources. These end nodes, in case
of a failure of the working LSP, MAY avoid trying to switch the
traffic to these protection LSPs that have been configured to use the
shared resources and try switching the traffic to other protection
LSPs, if available.
When the shared resources become available, a Notify message with a
new sub-code "Shared resources available" under "Notify Error" code
MAY be generated by the intermediate node. The recipients of 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
protecting LSPs that have lower preemption priorities than the one
that does not need the shared resources any more.
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 includes;
(1) the ability to identify a "secondary protecting LSP" (hereby (1) the ability to identify a "secondary protecting LSP" (hereby
called the "secondary LSP") used to recover another primary called the "secondary LSP") used to recover another primary
working LSP (hereby called the "protected LSP"), working LSP (hereby called the "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 5, line 44 skipping to change at page 6, line 44
(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.
4.1. Identifiers 4.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 carrying
working traffic and the secondary LSP. normal traffic and the secondary LSP.
A new LSP Protection Type "Shared Mesh Protection" is introduced to A new LSP Protection Type "Shared Mesh Protection" is introduced to
the LSP Flags of PROTECTION object (see [RFC4872]) to set up the two the LSP Flags of PROTECTION object (see [RFC4872]) to set up the two
LSPs. This LSP Protection Type value is applicable only to LSPs. This LSP Protection Type value is applicable only to
bidirectional LSPs as required in [G808.3]. bidirectional LSPs as required in [G808.3].
4.2. Signaling Primary LSPs 4.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
Type value set to "Shared Mesh Protection". Type value set to "Shared Mesh Protection".
Primary working LSPs are signaled by setting in the POTECTION object Primary working LSPs are signaled by setting in the PROTECTION object
the S bit to 0, the P bit to 0, the N bit to 1 and in the ASSOCIATION the S bit to 0, the P bit to 0, the N bit to 1 and in the ASSOCIATION
object, the Association ID to the associated secondary protecting object, the Association ID to the associated secondary protecting
LSP_ID. LSP_ID.
Note: N bit is set to indicate that the protection switching Note: N bit is set to indicate that the protection switching
signaling is done via data plane. signaling is done via data plane.
4.3. Signaling Secondary LSPs 4.3. Signaling Secondary LSPs
The PROTECTION object (see [RFC4872]) is included in the Path message The PROTECTION object (see [RFC4872]) is included in the Path message
skipping to change at page 7, line 5 skipping to change at page 8, line 5
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 normal
traffic). The formerly working LSP MAY be signaled with the A bit traffic). The formerly working LSP MAY be signaled with the A bit
set in the ADMIN_STATUS object (see [RFC3473]). set in the 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 setup LSPs for extra traffic are also for further mechanisms to setup LSPs for extra traffic are also for further
study. study.
The preemption priority of a protecting LSP that is used to resolve
the competition for the same shared resource among multiple
protecting LSPs, is indicated in the TBD1 field of the PROTECTION
object in the Path message of the protecting LSP. In SMP, the Setup
and Holding priorities in the SESSION_ATTRIBUTE object can be used to
configure or pre-configure a LSP, but is irrelevant to resolving the
competition among multiple protecting LSPs, which experience failures
on their working LSPs.
When an intermediate node on the protection LSP receives the Path
message, the preemption priority value in the TBD1 field MUST be
stored for that protection LSP. When resource competition among
multiple protecting LSPs occurs, their priority values will be used
to resolve the competition. Once the preemption priorities are
configured, the preemption of the protecting LSPs is fully controlled
by the APS.
[EDITOR'S NOTE: The TBD1 field for the preemption priority will be
defined in the next version of this draft.]
In SMP, a preempted LSP SHOULD not be torn down. Once the working
LSP and the protecting LSP are configured or pre-configured, the end
node SHOULD keep refreshing both working and protecting LSPs
regardless of failure or preempted situation.
[EDITOR'S NOTE: Behavior to notify the end nodes of the lower
priority protecting LSP that is preempted or no longer preempted will
be described in the next version. Feedback from the TEAS WG in the
105th IETF meeting in Montreal: Use "Notify" message to perform
nodification for resource available/unavailable. We may need to
define two new sub-codes under "Notify Error" code, such as "Shared
resource unavailable" and "Shared resource available."]
4.4. SMP APS Configuration 4.4. 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 a SMP protecting LSP. along the path to activate a SMP protecting LSP.
In order to allow exchange of APS protocol messages, an APS channel In order to allow exchange of APS protocol messages, an APS channel
has to be configured between adjacent nodes along the path of the SMP has to be configured between adjacent nodes along the path of the SMP
protecting LSP. This should be done before any SMP protecting LSP protecting LSP. This should be done before any SMP protecting LSP
has been setup by other means than GMPL signaling which are therefore has been setup by other means than GMPL signaling which are therefore
outside the scope of this document. outside the scope of this document.
 End of changes. 12 change blocks. 
49 lines changed or deleted 64 lines changed or added

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