< draft-ietf-teas-gmpls-signaling-smp-00.txt   draft-ietf-teas-gmpls-signaling-smp-01.txt >
TEAS Working Group J. He
Internet Draft I. Busi
Updates (if published): RFC 4872 Huawei
Intended status: Standards Track
Expires: July 14, 2019 January 15, 2019 TEAS Working Group J. He
Internet-Draft I. Busi
Intended status: Standards Track Huawei Technologies
Expires: January 6, 2020 J. Ryoo
B. Yoon
ETRI
P. Park
KT
July 5, 2019
GMPLS Signaling Extensions for Shared Mesh Protection GMPLS Signaling Extensions for Shared Mesh Protection
draft-ietf-teas-gmpls-signaling-smp-00.txt draft-ietf-teas-gmpls-signaling-smp-01
Status of this Memo Abstract
ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of
a Shared Mesh Protection (SMP) mechanism, where the difference
between SMP and Shared Mesh Restoration (SMR) is also identified.
ITU-T Recommendation G.873.3 [G873.3] defines the protection
switching operation and associated protocol for SMP at the Optical
Data Unit (ODU) layer. RFC 7412 [RFC7412] provides requirements for
any mechanism that would be used to implement SMP in a Multi-Protocol
Label Switching - Transport Profile (MPLS-TP) network.
This document updates RFC 4872 [RFC4872] to provide the extensions to
the Generalized Multi-Protocol Label Switching (GMPLS) signaling to
support the control of the shared mesh protection.
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 working documents as Internet-Drafts. The list of current Internet-
Internet-Drafts is at Drafts is at https://datatracker.ietf.org/drafts/current/.
https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet-Drafts time. It is inappropriate to use Internet-Drafts as reference
as reference material or to cite them other than as "work in material or to cite them other than as "work in progress."
progress."
This Internet-Draft will expire on July 14, 2019. This Internet-Draft will expire on January 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(http://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 carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Abstract
ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects
of a shared mesh protection (SMP) mechanism, where the difference
between SMP and shared mesh restoration (SMR) is also identified.
ITU-T Recommendation G.873.3 [G873.3] defines the protection
switching operation and associated protocol for shared mesh
protection (SMP) at the optical data unit (ODU) layer. RFC 7412
provides requirements for any mechanism that would be used to
implement SMP in an MPLS-TP network.
This document updates RFC 4872 to provide the extensions to the
Generalized Multi-Protocol Label Switching (GMPLS) signaling to
support the control of the shared mesh protection.
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 . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Signaling Primary LSPs..................................6 4.2. Signaling Primary LSPs . . . . . . . . . . . . . . . . . 6
4.3. Signaling Secondary LSPs................................6 4.3. Signaling Secondary LSPs . . . . . . . . . . . . . . . . 6
5. Updates to PROTECTION Object.................................7 4.4. SMP APS Configuration . . . . . . . . . . . . . . . . . . 8
5.1. New Protection Type.....................................7 5. Updates to PROTECTION Object . . . . . . . . . . . . . . . . 8
5.2. Other Updates ..........................................7 5.1. New Protection Type . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations......................................8 5.2. Other Updates . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations .........................................8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References ..................................................8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References....................................8 8. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References..................................9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
RFC 4872 [RFC4872] defines extension of RSVP-TE to support shared RFC 4872 [RFC4872] defines extension of Resource Reservation Protocol
mesh restoration (SMR) mechanism. Shared mesh restoration can be - Traffic Engineering (RSVP-TE) to support Shared Mesh Restoration
seen as a particular case of pre-planned LSP rerouting that (SMR) mechanism. SMR can be seen as a particular case of pre-planned
reduces the recovery resource requirements by allowing multiple Label Switched Path (LSP) rerouting that reduces the recovery
protecting LSPs to share common link and node resources. The resource requirements by allowing multiple protecting LSPs to share
recovery resources for the protecting LSPs are pre-reserved during common link and node resources. The recovery resources for the
the provisioning phase, and an explicit restoration signaling is protecting LSPs are pre-reserved during the provisioning phase, and
required to activate (i.e., commit resource allocation at the data an explicit restoration signaling is required to activate (i.e.,
plane) a specific protecting LSP instantiated during the commit resource allocation at the data plane) a specific protecting
provisioning phase. LSP instantiated during the provisioning phase.
ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of
of a shared mesh protection (SMP) mechanism. ITU-T Recommendation a shared mesh protection (SMP) mechanism. ITU-T Recommendation
G.873.3 [G873.3] defines the protection switching operation and G.873.3 [G873.3] defines the protection switching operation and
associated protocol for shared mesh protection (SMP) at the optical associated protocol for SMP at the Optical Data Unit (ODU) layer.
data unit (ODU) layer. RFC 7412 provides requirements for any RFC 7412 [RFC7412] provides requirements for any mechanism that would
mechanism that would be used to implement SMP in an MPLS-TP network. be used to implement SMP in a Multi-Protocol Label Switching -
Transport Profile (MPLS-TP) network.
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 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 during provisioning so that each node involved behaves appropriately
appropriately in the recovery phase when activation of a in the recovery phase when activation of a protecting LSP is done.
protecting LSP is done.
This document updates RFC 4872 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 shared mesh protection mechanism. Only support the control of the SMP mechanism. Only the generic aspects
the generic aspects for signaling SMP are addressed by this for signaling SMP are addressed by this document. The technology-
document. The technology-specific aspects are expected to be specific aspects are expected to be addressed by other drafts.
addressed by other drafts.
2. Conventions used in this document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"MAY", and "OPTIONAL" in this document are to be interpreted as "OPTIONAL" in this document are to be interpreted as described in BCP
described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 14 [RFC2119] [RFC8174] when, and only when, they appear in all
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] and [RFC4426]. terminology used in [RFC4872] and RFC 4426 [RFC4426].
3. SMP Definition 3. SMP Definition
ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects [G808.3] defines the generic aspects of a SMP mechanism. [G873.3]
of a shared mesh protection (SMP) mechanism. ITU-T Recommendation defines the protection switching operation and associated protocol
G.873.3 [G873.3] defines the protection switching operation and for SMP at the ODU layer. [RFC7412] provides requirements for any
associated protocol for shared mesh protection (SMP) at the optical mechanism that would be used to implement SMP in a MPLS-TP network.
data unit (ODU) layer. RFC 7412 provides requirements for any
mechanism that would be used to implement SMP in an MPLS-TP network.
The SMP mechanism is based on pre-computed protection transport The SMP mechanism is based on pre-computed protection transport
entities that are pre-configured into the network elements. Pre- entities that are pre-configured into the network elements. Pre-
configuration here means pre-reserving resources for the configuration here means pre-reserving resources for the protecting
protecting LSPs without activating a particular protecting LSP LSPs without activating a particular protecting LSP (e.g. in circuit
(e.g. in circuit networks, the cross-connects in the intermediate networks, the cross-connects in the intermediate nodes of the
nodes of the protecting LSP are not pre-established). Pre- protecting LSP are not pre-established). Pre-configuring but not
configuring but not activating the protecting LSP allows the activating the protecting LSP allows the common link and node
common link and node resources in a protecting LSP to be shared by resources in a protecting LSP to be shared by multiple working LSPs
multiple working LSPs that are physically (i.e., link, node, SRLG, that are physically (i.e., link, node, Shared Risk Link Group (SRLG),
etc.) disjoint. Protecting LSPs are activated in response to etc.) disjoint. 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's commands by means of the APS
APS protocol that operates in the data plane. SMP is always protocol that operates in the data plane. The APS protocol messages
revertive. are exchanged along the protecting LSP. SMP is always revertive.
SMP has a lot of similarity to SMR except that the activation in SMP has a lot of similarity to SMR except that the activation in case
case of SMR is achieved by control plan signaling during the of SMR is achieved by control plan signaling during the recovery
recovery operation while SMP is done by APS protocol in the data operation while SMP is done by APS protocol in the data plane. SMP
plane. SMP has advantages with regard to the recovery speed has advantages with regard to the recovery speed compared with SMR.
compared with SMR.
4. GMPLS Signaling Extension for SMP 4. GMPLS Signaling Extension for SMP
Consider the following network topology: Consider the following network topology:
A---B---C---D A---B---C---D
\ / \ /
E---F---G E---F---G
/ \ / \
H---I---J---K H---I---J---K
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 [RFC3209], in order [A,E,F,G,D] and [H,E,F,G,K], respectively. Per RFC 3209 [RFC3209],
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 protecting LSPs, they must have the same Tunnel Endpoint Address (as
(as part of their SESSION object). However, these addresses are part of their SESSION object). However, these addresses are not the
not the same in this example. Similar to SMR, a new LSP Protection same in this example. Similar to SMR, a new LSP Protection Type of
Type of the secondary LSP is defined as "Shared Mesh Protection" the secondary LSP is defined as "Shared Mesh Protection" (see
(see PROTECTION object defined in [RFC4872]) to allow resource PROTECTION object defined in [RFC4872]) to allow resource sharing
sharing along nodes E, F, and G. In this case, the protecting LSPs along nodes E, F, and G. In this case, the protecting LSPs are not
are not merged (which is useful since the paths diverge at G), but merged (which is useful since the paths diverge at G), but the
the resources along E, F, G can be shared. resources along E, F, G can be shared.
When a failure is detected on one of the working LSPs (say working When a failure, such as Signal Fail (SF) and Signal Degrade (SD),
LSP [A,B,C,D]), the switching operation for the egress node (say occurs on one of the working LSPs (say working LSP [A,B,C,D]), the
node A) will be triggered by an Signal Degrade (SD) or Signal Fail end-node (say node A) that detects the failure initiates the
(SF) on the working LSP. The egress node A will send a protection protection switching operation. The end-node A will send a
switching request APS message (for example SF) to its adjacent protection switching request APS message (for example SF) to its
(downstream) intermediate node (say node E) to activate setting up adjacent (downstream) intermediate node (say node E) to activate
the corresponding protecting LSP. If the protection resource is setting up the corresponding protecting LSP and will wait for a
available, Node E will send a confirmation message to the egress node confirmation message from node E. If the protection resource is
A and forward the switching request APS message to its adjacent available, node E will send the confirmation APS message to the end-
(downstream) node (say node F). When the confirmation message is node A and forward the switching request APS message to its adjacent
received by node A and the protection resource is available, the (downstream) node (say node F). When the confirmation APS message is
cross-connection on node A is established. At this time the traffic received by node A, the cross-connection on node A is established.
is bridged to and selected from the protecting LSP at node A. The At this time the traffic is bridged to and selected from the
node E will wait for the confirmation message from node F, which protecting LSP at node A. After forwarding the switching request APS
triggers node E to set up the cross-connection for the protection message, node E will wait for a confirmation APS message from node F,
transport entity being activated. If the protection resource is not which triggers node E to set up the cross-connection for the
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 keep trying until node may send a message to notify the end node, or may keep trying
the resource is available or the switching request is cancelled. If until the resource is available or the switching request is
the resource is in use by a lower priority protection entity, the cancelled. If the resource is in use by a lower priority protecting
lower priority service will be removed and then the intermediate node LSP, the lower priority service will be removed and then the
will follow the procedure as described for the case when the resource intermediate node will follow the procedure as described for the case
is available. when the protection resource is available for the higher priority
protecting LSP.
The following subsections detail how shared mesh protection can be The following subsections detail how LSPs using SMP can be signaled
implemented in an interoperable fashion using GMPLS RSVP-TE in an interoperable fashion using GMPLS RSVP-TE extensions (see RFC
extensions (see [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,
(3) the capability to include information about the resources (3) the capability to include information about the resources used
used by the protected LSP while instantiating the secondary LSP. by the protected LSP while instantiating the secondary LSP,
(4) the capability to instantiate during the provisioning phase (4) the capability to instantiate during the provisioning phase
several secondary LSPs in an efficient manner. 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.
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, SESSION object MUST be the same for both LSPs. The LSP ID, however,
however, MUST be different to distinguish between the protected MUST be different to distinguish between the protected LSP carrying
LSP carrying working traffic and the secondary LSP. working traffic and the secondary LSP.
A new LSP Protection Type "Shared Mesh Protection" is introduced A new LSP Protection Type "Shared Mesh Protection" is introduced to
to the LSP Flags of PROTECTION object (see [RFC4872]) to set up the LSP Flags of PROTECTION object (see [RFC4872]) to set up the two
the two LSPs. This LSP Protection Type value is applicable to LSPs. This LSP Protection Type value is applicable only to
both uni- and bidirectional LSPs. 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 The PROTECTION object (see [RFC4872]) is included in the Path message
message during signaling of the primary working LSPs, with the LSP during signaling of the primary working LSPs, with the LSP Protection
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 Primary working LSPs are signaled by setting in the POTECTION object
object the S bit to 0, the P bit to 0, the N bit to 1 and in the the S bit to 0, the P bit to 0, the N bit to 1 and in the ASSOCIATION
ASSOCIATION object, the Association ID to the associated secondary object, the Association ID to the associated secondary protecting
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 The PROTECTION object (see [RFC4872]) is included in the Path message
message during signaling of the secondary protecting LSPs, with during signaling of the secondary protecting LSPs, with the LSP
the LSP Protection Type value set to "Shared Mesh Protection". Protection Type value set to "Shared Mesh Protection".
Secondary protecting LSPs are signaled by setting in the Secondary protecting LSPs are signaled by setting in the PROTECTION
PROTECTION object the S bit and the P bit to 1, the N bit to 1 and object the S bit and the P bit to 1, the N bit to 1 and in the
in the ASSOCIATION object, the Association ID to the associated ASSOCIATION object, the Association ID to the associated primary
primary working LSP_ID, which MUST be known before signaling of working LSP_ID, which MUST be known before signaling of the secondary
the secondary LSP. Moreover, the Path message used to instantiate LSP. Moreover, the Path message used to instantiate the secondary
the secondary LSP SHOULD include at least one PRIMARY_PATH_ROUTE LSP SHOULD include at least one PRIMARY_PATH_ROUTE object (see
object (see [RFC4872]) that further allows for recovery resource [RFC4872]) that further allows for recovery resource sharing at each
sharing at each intermediate node along the secondary path. intermediate node along the secondary path.
With this setting, the resources for the secondary LSP SHOULD be With this setting, the resources for the secondary LSP SHOULD be pre-
pre-reserved, but not committed at the data plane level, meaning reserved, but not committed at the data plane level, meaning that the
that the internals of the switch need not be established until internals of the switch need not be established until explicit action
explicit action is taken to activate this LSP. Activation of a is taken to activate this LSP. Activation of a secondary LSP and
secondary LSP and protection switching to the activated protecting protection switching to the activated protecting LSP is done using
LSP is done using APS protocol in the data plane. APS protocol in the data plane.
After protection switching completes the protecting LSP SHOULD be After protection switching completes the protecting LSP SHOULD be
signaled with the S bit set to 0 and O bit set to 1 in the signaled with the S bit set to 0 and O bit set to 1 in the PROTECTION
PROTECTION object. At this point, the link and node resources must object. At this point, the link and node resources must be allocated
be allocated for this LSP that becomes a primary LSP (ready to for this LSP that becomes a primary LSP (ready to carry normal
carry normal traffic). The formerly working LSP MAY be signaled traffic). The formerly working LSP MAY be signaled with the A bit
with the A bit set in the ADMIN_STATUS object (see [RFC3473]). set in the ADMIN_STATUS object (see [RFC3473]).
5. Updates to PROTECTION Object Support for extra traffic in SMP is for further study. Therefore,
mechanisms to setup LSPs for extra traffic are also for further
study.
GMPLS extension requirements for SMP introduce several updates to The preemption priority of a protecting LSP that is used to resolve
the Protection Object (see [RFC4872]). the competition for the same shared resource among multiple
protecting LSPs, is indicated in the TBD1 field of the TBD2 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.
5.1. New Protection Type 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.
When an APS request for a lower priority protecting LSP is preempted
or cannot be confirmed due to existing higher priority APS request
for another protection LSPs, an intermediate node MAY send PathErr
and ResvErr with the error code/sub-code "Policy Control Failure/Hard
Pre-empted" toward the source nodes of Path and Resv, respectively,
to notify that the lower priority protecting LSP is preempted.
Upon receiving a PathErr or ResvErr message with the error code/sub-
code "Policy Control Failure/Hard Pre-empted," the end node that has
initiated the protection switching for a protecting LSP may cancel it
(and try with another protecting LPS) or may keep trying until the
resource is available.
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: See if it is ok to add the next sentence at the end
of the previous paragraph.] The Path_State_Removed flag in the
ERROR_SPEC object MUST not be set in PathErr and ResvErr messages
generated due to preemption.
[Editor's note: Check what should be the behavior to notify the end
nodes of the lower priority protecting LSP that is no longer
preempted and therefore it is available for SMP protection switching,
if needed.]
4.4. SMP APS Configuration
SMP relies on APS protocol messages being exchanged between the nodes
along the path to activate a SMP protecting LSP.
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
protecting LSP. This should be done before any SMP protecting LSP
has been setup by other means than GMPL signaling which are therefore
outside the scope of this document.
Depending on the APS protocol message format, the APS protocol may
use different identifiers than GMPLS signaling to identify the SMP
protecting LSP.
Since APS protocol is for further study in [G808.3], it can be
assumed that APS message format and identifiers are technology-
specific and/or vendor-specific. Therefore, additional requirements
for APS configuration are outside the scope of this document.
5. Updates to PROTECTION Object
GMPLS extension requirements for SMP introduce several updates to the
Protection Object (see [RFC4872]).
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
both uni- and 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 5.2. Other Updates
N bit and O bit in the Protection object as defined in [RFC4872] N bit and O bit in the Protection object as defined in [RFC4872] are
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), or 0x11 (Shared Mesh Protection). The Bidirectional Protection). In SMP, N bit MUST be set to 1. The N
N bit MUST be set to 0 in any other case. bit MUST be set to 0 in any other case.
Operational (O): 1 bit Operational (O): 1 bit
When set to 1, this bit indicates that the protecting LSP is
carrying the normal traffic after protection switching. The O bit
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
Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10
(1+1 Bidirectional Protection), or 0x11 (Shared Mesh Protection).
The O bit MUST be set to 0 in any other case.
6. Security Considerations When set to 1, this bit indicates that the protecting LSP is
carrying the normal traffic after protection switching. The O bit
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
Extra-Traffic), or 0x08 (1+1 Unidirectional Protection), or 0x10
(1+1 Bidirectional Protection), or 0x11 (Shared Mesh Protection).
The O bit MUST be set to 0 in any other case.
6. IANA Considerations
IANA actions required by this document will be described later.
7. Security Considerations
No further security considerations than [RFC4872]. No further security considerations than [RFC4872].
7. IANA Considerations 8. Contributor
There are no IANA actions required. The following person contributed significantly to the content of this
document and should be considered as a co-author.
8. References Yuji Tochio
Fujitsu
Email: tochio@fujitsu.com
8.1. Normative References 9. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 9.1. Normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, [G808.3] International Telecommunication Union, "Generic protection
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP switching - Shared mesh protection", ITU-T Recommendation
Tunnels", RFC 3209, December 2001. G.08.3, October 2012.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
(GMPLS) Signaling Resource ReserVation Protocol-Traffic Requirement Levels", BCP 14, RFC 2119,
Engineering (RSVP-TE) Extensions", RFC 3473, January DOI 10.17487/RFC2119, March 1997,
2003. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4426] Lang, J., Rajagopalan, B., and D. Papadimitriou, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
"Generalized Multi-Protocol Label Switching (GMPLS) and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Recovery Functional Specification", RFC 4426, March Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
2006. <https://www.rfc-editor.org/info/rfc3209>.
[RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Ed., "RSVP-TE Extensions in support of End-to-End Switching (GMPLS) Signaling Resource ReserVation Protocol-
Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
Recovery", RFC 4872, May 2007. DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou,
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, Ed., "Generalized Multi-Protocol Label Switching (GMPLS)
May 2017. Recovery Functional Specification", RFC 4426,
DOI 10.17487/RFC4426, March 2006,
<https://www.rfc-editor.org/info/rfc4426>.
[G808.3] ITU-T, "Generic protection switching - Shared mesh [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
protection", G.808.3, October 2012. Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
<https://www.rfc-editor.org/info/rfc4872>.
8.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[G873.3] ITU-T, "Optical transport network - Shared mesh 9.2. Informative References
protection", G.873.3, September 2017.
[RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., Mirsky, [G873.3] International Telecommunication Union, "Optical transport
G., "Requirements for MPLS Transport Profile (MPLS-TP) network - Shared mesh protection", ITU-T Recommendation
Shared Mesh Protection", RFC 7412, December 2014. G.873.3, September 2017.
[RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G.
Mirsky, "Requirements for MPLS Transport Profile (MPLS-TP)
Shared Mesh Protection", RFC 7412, DOI 10.17487/RFC7412,
December 2014, <https://www.rfc-editor.org/info/rfc7412>.
Authors' Addresses Authors' Addresses
Jia He Jia He
Huawei Technologies Co.,Ltd. Huawei Technologies
F3-1B, R&D Center, Huawei Industrial Base, Bantian, Longgang F3-1B, R&D Center, Huawei Industrial Base, Bantian, Longgang District
District, Shenzhen, China Shenzhen
China
Email: hejia@huawei.com Email: hejia@huawei.com
Italo Busi Italo Busi
Huawei Huawei Technologies
Email: italo.busi@huawei.com Email: italo.busi@huawei.com
Jeong-dong Ryoo
ETRI
218 Gajeongno
Yuseong-gu, Daejeon 34129
South Korea
Phone: +82-42-860-5384
Email: ryoo@etri.re.kr
Bin Yeong Yoon
ETRI
Email: byyun@etri.re.kr
Peter Park
KT
Email: peter.park@kt.com
 End of changes. 75 change blocks. 
270 lines changed or deleted 364 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/