draft-ietf-teas-gmpls-signaling-smp-04.txt   draft-ietf-teas-gmpls-signaling-smp-05.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 Updates: 4872 (if approved) Huawei Technologies
Expires: March 12, 2021 J. Ryoo Intended status: Standards Track J. Ryoo
B. Yoon Expires: July 18, 2021 B. Yoon
ETRI ETRI
P. Park P. Park
KT KT
September 8, 2020 January 14, 2021
GMPLS Signaling Extensions for Shared Mesh Protection GMPLS Signaling Extensions for Shared Mesh Protection
draft-ietf-teas-gmpls-signaling-smp-04 draft-ietf-teas-gmpls-signaling-smp-05
Abstract Abstract
ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of ITU-T Recommendation G.808.3 defines the generic aspects of a Shared
a Shared Mesh Protection (SMP) mechanism, where the difference Mesh Protection (SMP) mechanism, where the difference between SMP and
between SMP and Shared Mesh Restoration (SMR) is also identified. Shared Mesh Restoration (SMR) is also identified. ITU-T
ITU-T Recommendation G.873.3 [G873.3] defines the protection Recommendation G.873.3 defines the protection switching operation and
switching operation and associated protocol for SMP at the Optical associated protocol for SMP at the Optical Data Unit (ODU) layer.
Data Unit (ODU) layer. RFC 7412 [RFC7412] provides requirements for RFC 7412 provides requirements for any mechanism that would be used
any mechanism that would be used to implement SMP in a Multi-Protocol to implement SMP in a Multi-Protocol Label Switching - Transport
Label Switching - Transport Profile (MPLS-TP) network. Profile (MPLS-TP) network.
This document updates RFC 4872 [RFC4872] to provide the extensions to This document updates RFC 4872 to provide the extensions to the
the Generalized Multi-Protocol Label Switching (GMPLS) signaling to Generalized Multi-Protocol Label Switching (GMPLS) signaling to
support the control of the shared mesh protection. support the control of the SMP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 12, 2021. This Internet-Draft will expire on July 18, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. SMP Definition . . . . . . . . . . . . . . . . . . . . . . . 3 3. SMP Definition . . . . . . . . . . . . . . . . . . . . . . . 4
4. GMPLS Signaling Extension for SMP . . . . . . . . . . . . . . 4 4. GMPLS Signaling Extension for SMP . . . . . . . . . . . . . . 4
4.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Signaling Primary LSPs . . . . . . . . . . . . . . . . . 7 4.2. Signaling Primary LSPs . . . . . . . . . . . . . . . . . 7
4.3. Signaling Secondary LSPs . . . . . . . . . . . . . . . . 7 4.3. Signaling Secondary LSPs . . . . . . . . . . . . . . . . 7
4.4. SMP APS Configuration . . . . . . . . . . . . . . . . . . 8 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. Updates on Notification and Operational Bits . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5.3. Preemption Priority . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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) mechanism. SMR can be seen as a particular case of pre-planned (SMR) mechanism. SMR can be seen as a particular case of pre-planned
Label Switched Path (LSP) rerouting that reduces the recovery 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
skipping to change at page 5, line 20 skipping to change at page 5, line 35
successful; the intermediate node may send a message to notify the successful; the intermediate node may send a message to notify the
end node, or may keep trying until the resource is available, or the end node, or may keep trying until the resource is available, or the
switching request is cancelled. If the resource is in use by a lower switching request is cancelled. If the resource is in use by a lower
priority protecting LSP, the lower priority service will be removed priority protecting LSP, the lower priority service will be removed
and then the intermediate node will follow the procedure as described and then the intermediate node will follow the procedure as described
for the case when the protection resource is available for the higher for the case when the protection resource is available for the higher
priority protecting LSP. priority protecting LSP.
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 the TBD1 field of the PROTECTION protecting LSPs, is indicated in Preemption Priority field of the
object in the Path message of the protecting LSP. In SMP, the Setup PROTECTION object in the Path message of the protecting LSP.
and Holding priorities in the SESSION_ATTRIBUTE object can be used to
configure or pre-configure a LSP, but is irrelevant to resolving the In SMP, the Setup and Holding priorities in the SESSION_ATTRIBUTE
competition among multiple protecting LSPs, when controlled by the object can be used by GMPLS to control LSP preemption, but, they are
APS. not used by the APS to resolve the competition among multiple
protecting LSPs. This would avoid the need to define a complex
policy for defining Setup and Holding priorities when used for both
GMPLS control plane LSP preemption and SMP shared resource
competition resolution.
When an intermediate node on the protecting LSP receives the Path When an intermediate node on the protecting LSP receives the Path
message, the preemption priority value in the TBD1 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.
[EDITOR'S NOTE: The TBD1 field for the preemption priority will be In SMP, a preempted LSP SHOULD NOT be torn down. Once the working
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 LSP and the protecting LSP are configured or pre-configured, the end
node SHOULD keep refreshing both working and protecting LSPs node SHOULD keep refreshing both working and protecting LSPs
regardless of failure or preempted situation. regardless of failure or preempted situation.
When a lower priority protecting LSP is preempted, the intermediate When a lower priority protecting LSP is preempted, the intermediate
node that performed preemption MAY send a Notify message with a new node that performed preemption MAY send a Notify message with a new
sub-code "Shared resources unavailable" under "Notify Error" code sub-code "Shared resources unavailable" under "Notify Error" code
(see [RFC4872]) to the end nodes of that protecting LSP. Upon (see [RFC4872]) to the end nodes of that protecting LSP. Upon
receipt of this Notify message, the end node MAY stop sending and receipt of this Notify message, the end node MAY stop sending and
selecting normal traffic to/from its protecting LSP and try switching selecting normal traffic to/from its protecting LSP and try switching
the traffic to another protection LSP, if available. the traffic to another protection LSP, if available.
When the shared resources become unavailable, the same Notify message When the shared resources become unavailable, the same Notify message
MAY also be generated by the intermediate node to all the end nodes MAY also be generated by the intermediate node to all the end nodes
of the protecting LSPs that have lower preemption priorities than the of the protecting LSPs that have lower SMP preemption priorities than
one that has occupied the shared resources. These end nodes, in case the one that has occupied the shared resources. These end nodes, in
of a failure of the working LSP, MAY avoid trying to switch the 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 traffic to these protection LSPs that have been configured to use the
shared resources and try switching the traffic to other protection shared resources and try switching the traffic to other protection
LSPs, if available. LSPs, if available.
When the shared resources become available, a Notify message with a When the shared resources become available, a Notify message with a
new sub-code "Shared resources available" under "Notify Error" code new sub-code "Shared resources available" under "Notify Error" code
MAY be generated by the intermediate node. The recipients of this MAY be generated by the intermediate node. The recipients of this
Notify message are the end nodes of the lower priority protecting 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 preemption priorities than the one protecting LSPs that have lower SMP preemption priorities than the
that does not need the shared resources any more. 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
skipping to change at page 8, line 25 skipping to change at page 8, line 39
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.
[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.
5. Updates to PROTECTION Object 5. Updates to PROTECTION Object
GMPLS extension requirements for SMP introduce several updates to the GMPLS extension requirements for SMP introduce several updates to the
Protection Object (see [RFC4872]). Protection Object (see [RFC4872]).
5.1. New Protection Type 5.1. New Protection Type
A new LSP protection type "Shared Mesh Protection" is added in the A new LSP protection type "Shared Mesh Protection" is added in the
protection object. This LSP Protection Type value is applicable to PROTECTION object. This LSP Protection Type value is applicable to
only bidirectional LSPs. only bidirectional LSPs.
LSP (Protection Type) Flags: LSP (Protection Type) Flags:
0x11: Shared Mesh Protection 0x11: Shared Mesh Protection
5.2. Other Updates According to the rules defined in Section 14.2 of [RFC4872], all the
nodes along an SMP LSP MUST be SMP aware and therefore there are no
backward compatibility issues.
N bit and O bit in the Protection object as defined in [RFC4872] are 5.2. Updates on Notification and Operational Bits
N bit and O bit in the PROTECTION object as defined in [RFC4872] are
also updated to include applicability to SMP. also updated to include applicability to SMP.
Notification (N): 1 bit Notification (N): 1 bit
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 protection-switching
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 either 0x04 (1:N Protection with Extra- Type Flag is set to either 0x04 (1:N Protection with Extra-
Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1 Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 (1+1
Bidirectional Protection). In SMP, N bit MUST be set to 1. The N Bidirectional Protection). In SMP, N bit MUST be set to 1. The N
bit MUST be set to 0 in any other case. bit MUST be set to 0 in any other case.
skipping to change at page 9, line 24 skipping to change at page 9, line 38
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 the normal 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 the P bit is set to 1, and the LSP
Protection Type Flag is set to either 0x04 (1:N Protection with Protection Type Flag is set to either 0x04 (1:N Protection with
Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10 Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10
(1+1 Bidirectional Protection), or 0x11 (Shared Mesh Protection). (1+1 Bidirectional Protection), or 0x11 (Shared Mesh Protection).
The O bit MUST be set to 0 in any other case. The O bit MUST be set to 0 in any other case.
5.3. Preemption Priority
The 32-bit Reserved field in the PROTECTION object defined in
[RFC4872] is updated as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Preempt Prio |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Preemption Priority (Preempt Prio): 8 bit
This field indicates the SMP preemption priority of a protecting
LSP, when the LSP Protection Type field indicates "Shared Mesh
Protection". A lower value has a higher priority. The decision
of how many priority levels to be operated in an SMP network is a
network operator's choice.
6. IANA Considerations 6. IANA Considerations
IANA actions required by this document will be described later. This document requests IANA to define two new sub-code values under
"Notify Error" code in Resource Reservation Protocol (RSVP)
parameters.
Value Description Reference
----- ---------------------------- ---------------
TBD1 Shared resources unavailable (this document)
TBD2 Shared resources available (this document)
7. Security Considerations 7. Security Considerations
No further security considerations than [RFC4872]. No further security considerations than [RFC4872].
8. Contributor 8. 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.
 End of changes. 24 change blocks. 
54 lines changed or deleted 94 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/