GMPLS Signaling Extensions for Shared Mesh ProtectionHuawei TechnologiesF3-1B, R&D Center, Huawei Industrial BaseBantian, Longgang DistrictShenzhenChinahejia@huawei.comHuawei Technologiesitalo.busi@huawei.comETRI218 GajeongnoYuseong-guDaejeon34129South Korea+82-42-860-5384ryoo@etri.re.krETRIbyyun@etri.re.krKTpeter.park@kt.com
Routing Area
TEAS Working GroupGMPLSShared mesh protection
ITU-T Recommendation G.808.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 defines the protection switching operation
and associated protocol for SMP at the Optical Data Unit (ODU) layer.
RFC 7412 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 RFCs 4872 and 4873 to provide extensions
for Generalized Multi-Protocol Label Switching (GMPLS) signaling to
support the control of the SMP mechanism.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised 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
. Introduction
. Conventions Used in This Document
. SMP Definition
. Operation of SMP with GMPLS Signaling Extensions
. GMPLS Signaling Extensions for SMP
. Identifiers
. Signaling Primary LSPs
. Signaling Secondary LSPs
. SMP Preemption Priority
. Availability of Shared Resources: The Notify Message
. SMP APS Configuration
. Updates to PROTECTION Object
. New Protection Type
. Updates to Definitions of Notification and Operational Bits
. Preemption Priority
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Contributors
Authors' Addresses
Introduction
RFC 4872 defines extensions for
Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
to support Shared Mesh Restoration (SMR) mechanisms.
SMR can be seen as a particular case of preplanned
Label Switched Path (LSP) rerouting that
reduces the recovery resource requirements by allowing multiple
protecting LSPs to share common link and node resources.
The recovery resources for the protecting LSPs are pre-reserved during
the provisioning phase, and explicit restoration signaling is
required to activate (i.e., commit resource allocation at the data
plane) a specific protecting LSP that was instantiated during the
provisioning phase.
RFC 4873 details the encoding of
the last 32-bit Reserved field of the PROTECTION object defined in
.
ITU-T Recommendation G.808.3 defines
the generic aspects of a Shared Mesh Protection (SMP) mechanism,
which are not specific to a particular network technology in terms of
architecture types, preemption principle, path monitoring methods,
etc.
ITU-T Recommendation G.873.3 defines
the protection switching operation and associated protocol
for SMP at the Optical Data Unit (ODU) layer.
RFC 7412 provides requirements for any
mechanism that would 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
operation. The former activates a protecting LSP via the Automatic
Protection Switching (APS) protocol in the data plane when the
working LSP fails, while the latter does it via control plane
signaling. It is therefore necessary to distinguish SMP from SMR
during provisioning so that each node involved behaves
appropriately in the recovery phase when activation of a
protecting LSP is done.
SMP has advantages with regard to the recovery speed compared with SMR.
This document updates and
to provide
extensions for Generalized Multi-Protocol Label Switching (GMPLS)
signaling to support the control of the SMP mechanism.
Specifically, it
defines a new LSP Protection Type, "Shared Mesh Protection", for the LSP
Flags field of the PROTECTION object
(see ),
updates the definitions of the Notification (N) and Operational (O) fields
of the PROTECTION object to take the new SMP
type into account (see ), and
updates the definition of the 16-bit Reserved field
of the PROTECTION object to allocate 8 bits
to signal the SMP preemption priority (see ).
Only the generic aspects for signaling SMP are addressed by this
document. The technology-specific aspects are expected to be
addressed by other documents.
RFC 8776 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,
is expected to be updated to support
the SMP mechanism specified in this document.
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 mechanism are outside the scope of this
document, and they are expected to be addressed by other documents.
Conventions Used in This DocumentThe key words "MUST", "MUST NOT",
"REQUIRED", "SHALL",
"SHALL NOT", "SHOULD",
"SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14
when, and only
when, they appear in all capitals, as shown here.
In addition, the reader is assumed to be familiar with the
terminology used in ,
RFC 4426 , and RFC 6372 .
SMP Definition defines the generic aspects of an SMP mechanism.
defines the protection switching operation and
associated protocol for SMP at the ODU layer.
provides requirements for any
mechanism that would be used to implement SMP in an MPLS-TP network.
The SMP mechanism is based on precomputed protecting LSPs
that are preconfigured into the network elements.
Preconfiguration here means pre-reserving resources for the
protecting LSPs without activating a particular protecting LSP
(e.g., in circuit networks, the cross-connects in the intermediate
nodes of the protecting LSP are not preestablished).
Preconfiguring but not activating protecting LSPs allows
link and node resources to be shared by
the protecting LSPs of multiple working LSPs (which are
themselves disjoint and thus unlikely to fail simultaneously).
Protecting LSPs are activated in response to
failures of working LSPs or operator commands by means of the
APS protocol, which operates in the data plane.
The APS protocol messages are exchanged along the protecting LSP.
SMP is always revertive.
SMP is very similar to SMR, except that activation in the
case of SMR is achieved by control plane signaling during the
recovery operation, while the same is done for SMP by the APS protocol in the data
plane.
Operation of SMP with GMPLS Signaling Extensions
Consider the network topology shown in :
An Example of an SMP Topology
A---B---C---D
\ /
E---F---G
/ \
H---I---J---K
The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by
the protecting LSPs [A,E,F,G,D] and [H,E,F,G,K], respectively.
Per RFC 3209 , in order
to achieve resource sharing during the signaling of these
protecting LSPs, they have the same Tunnel Endpoint Address
(as part of their SESSION object).
However, these addresses are not the same in this example.
Similar to SMR, this document defines a new LSP Protection Type of
the secondary LSP as "Shared Mesh Protection"
(see )
to allow resource sharing 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, the protecting LSPs
are not merged (which is useful, since the paths diverge at G), but
the resources along E, F, and G can be shared.
When a failure, such as Signal Fail (SF) or Signal Degrade (SD),
occurs on one of the working LSPs (say, working LSP [A,B,C,D]),
the end node (say, node A) that detects the failure initiates
the protection switching operation.
End node A will send a protection switching request APS message
(for example, SF) to its adjacent (downstream) intermediate node (say, node E)
to activate the corresponding protecting LSP
and will wait for a confirmation message from node E.
If the protection resource is available, node E will send the confirmation
APS message to the end node (node A) and forward the switching request APS message
to its adjacent (downstream) node (say, node F).
When the confirmation APS message is received by node A, the
cross-connection on node A is established.
At this time, traffic is bridged to and selected from the protecting LSP
at node A.
After forwarding the switching request APS message, node E will wait for
a confirmation APS message from node F, which triggers node E to set up
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 connections), the switching will not be successful;
the intermediate node (node E) MUST send a message to notify the end node
(node A) (see ).
If the resource is in use by a lower-priority protecting LSP, the
lower-priority service will be removed, and the intermediate node
will then follow the procedure as described for the case when the protection
resource is 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 ).
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.
GMPLS Signaling Extensions for SMP
The following subsections detail how LSPs using SMP can be
signaled in an interoperable fashion using GMPLS RSVP-TE
extensions (see RFC 3473 ).
This signaling enables:
the ability to identify a "secondary protecting LSP"
(LSP [A,E,F,G,D] or LSP [H,E,F,G,K] from ,
here called the "secondary LSP") used to recover
another "primary working LSP"
(LSP [A,B,C,D] or LSP [H,I,J,K] from ,
here called the "protected LSP"),
the ability to associate the secondary LSP with the protected LSP,
the capability to include information about the resources
used by the protected LSP while instantiating the secondary LSP,
the capability to instantiate
several secondary LSPs efficiently during the provisioning phase, and
the capability to support activation of a secondary LSP via the APS protocol in the data plane if a failure occurs.
Identifiers
To simplify association operations, both LSPs (i.e., the protected LSP
and the secondary LSP) belong to the same session.
Thus, the SESSION object MUST be the same for both LSPs.
The LSP ID, however, MUST be different to distinguish between the protected
LSP and the secondary LSP.
A new LSP Protection Type, "Shared Mesh Protection", is defined
(see )
for the LSP Flags field of the PROTECTION object (see )
to set up the two LSPs.
This LSP Protection Type value is only applicable to
bidirectional LSPs as required in .
Signaling Primary LSPs
The PROTECTION object (see ) is included
in the Path message during signaling of the primary working LSPs,
with the LSP Protection Type value set to "Shared Mesh Protection".
Primary working LSPs are signaled by setting in the PROTECTION
object the S bit to 0, the P bit to 0, and the N bit to 1; and setting in the
ASSOCIATION object the Association ID to the associated secondary
protecting LSP_ID.
Signaling Secondary LSPs
The PROTECTION object (see ) is included in the Path
message during signaling of the secondary protecting LSPs, with
the LSP Protection Type value set to "Shared Mesh Protection".
Secondary protecting LSPs are signaled by setting in the
PROTECTION object the S bit, the P bit, and the N bit to 1; and setting
in the ASSOCIATION object the Association ID to the associated
primary working LSP_ID, which MUST be known before signaling of
the secondary LSP.
Moreover, the Path message used to instantiate
the secondary LSP MUST include at least one PRIMARY_PATH_ROUTE
object (see ) that further allows for
recovery resource sharing at each intermediate node
along the secondary path.
With this setting, the resources for the secondary LSP MUST be
pre-reserved but not committed at the data plane level, meaning
that the internals of the switch need not be established until
explicit action is taken to activate this LSP. Activation of a
secondary LSP and protection switching to the activated protecting
LSP is done using the APS protocol in the data plane.
After protection switching completes, the protecting LSP MUST be
signaled by setting the S bit to 0 and the O bit to 1 in the
PROTECTION object. At this point, the link and node resources MUST
be allocated for this LSP, which becomes a primary LSP (ready to
carry traffic).
The formerly working LSP MAY be signaled with the A bit set in the
ADMIN_STATUS object (see ).
Support for extra traffic in SMP is left for further study.
Therefore, mechanisms to set up LSPs for extra traffic
are outside the scope of this document.
SMP Preemption Priority
The SMP preemption priority of a protecting LSP is used by the APS protocol
to resolve competition for shared resources among multiple
protecting LSPs and is indicated in the Preemption Priority field of the
PROTECTION object in the Path message of the protecting LSP.
The Setup and Holding priorities in the SESSION_ATTRIBUTE
object can be used by GMPLS to control LSP preemption, but they are
not used by the APS to resolve competition among multiple
protecting LSPs. This avoids 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
message, the priority value in the Preemption Priority 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 this competition.
A lower value has a higher priority.
In SMP, a preempted LSP MUST NOT be terminated even after its resources
have been deallocated. Once the working
LSP and the protecting LSP are configured or preconfigured, the end
node MUST keep refreshing both working and protecting LSPs,
regardless of failure or preemption status.
Availability of Shared Resources: The Notify Message
When a lower-priority protecting LSP is preempted, the intermediate
node that performed the preemption MUST send a Notify message with
error code "Notify Error" (25) (see ) and
error sub-code "Shared resources unavailable" (17)
to the end nodes of that protecting LSP.
Upon receipt of this Notify message, the end node MUST stop sending and
selecting traffic to/from its protecting LSP and try switching
the traffic to another protecting LSP, if available.
When a protecting LSP occupies the shared resources
and they become unavailable, the same Notify message MUST be
generated by the intermediate node to all the end nodes of the
protecting LSPs that have lower SMP preemption priorities than the
one that has occupied the shared resources.
If the shared resources become unavailable
due to a failure in the shared resources,
the same Notify message MUST be generated by the intermediate node
to all the end nodes of the protecting LSPs that have been configured
to use the shared resources.
In the case of a failure of the working LSP, these end nodes
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
error code "Notify Error" (25) and
error sub-code "Shared resources available" (18)
MUST 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 SMP preemption priorities than the
one that does not need the shared resources anymore.
Upon receipt of this Notify message, the end node is allowed to
reinitiate the protection switching operation as described in
, if it still needs the protection
resource.
SMP APS Configuration
SMP relies on APS protocol messages being exchanged between the nodes
along the path to activate a protecting LSP.
In order to allow the exchange of APS protocol messages,
an APS channel has to be configured between adjacent nodes
along the path of the protecting LSP.
This is done by means other than GMPLS signaling,
before any protecting LSP has been set up.
Therefore, there are likely additional requirements for APS configuration
that are 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 protecting LSP.
Since the APS protocol is left for further study per ,
it can be assumed that the 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.
Updates to PROTECTION Object
GMPLS extension requirements for SMP introduce several updates to
the PROTECTION object (see ), as
detailed below.
New Protection Type
A new LSP Protection Type, "Shared Mesh Protection", is added in the
PROTECTION object. This LSP Protection Type value is only applicable to
bidirectional LSPs.
LSP (Protection Type) Flags:
0x20: Shared Mesh Protection
The rules defined in
ensure that all the nodes along an SMP LSP are SMP aware.
Therefore, there are no backward-compatibility issues.
Updates to Definitions of Notification and Operational Bits
The definitions of the N and O bits in are replaced as follows:
Notification (N): 1 bit
When set to 1, this bit indicates that the control plane message
exchange is only used for notification during protection
switching. When set to 0 (default), it indicates that the control
plane message exchanges are used for purposes of protection switching.
The N bit is only applicable when the LSP Protection
Type Flag is set to 0x04 (1:N Protection with Extra-Traffic),
0x08 (1+1 Unidirectional Protection),
0x10 (1+1 Bidirectional Protection),
or 0x20 (Shared Mesh Protection).
The N bit MUST be set to 0 in any other case.
If 0x20 (SMP), the N bit MUST be set to 1.
Operational (O): 1 bit
When set to 1, this bit indicates that the protecting LSP is
carrying traffic after protection switching. The O bit
is only applicable when (1) the P bit is set to 1 and (2) the LSP
Protection Type Flag is set to 0x04 (1:N Protection with
Extra-Traffic), 0x08 (1+1 Unidirectional Protection), 0x10
(1+1 Bidirectional Protection), or 0x20 (Shared Mesh Protection).
The O bit MUST be set to 0 in any other case.
Preemption Priority reserved a 32-bit field in the PROTECTION object
header. Subsequently, allocated several bits
from that field and left the remainder of the bits reserved.
This specification further allocates the Preemption Priority field
from the remaining formerly reserved bits.
The 32-bit field in the PROTECTION object as defined in and modified by
is updated by this document 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|R| Reserved | Seg.Flags | Reserved | Preempt Prio |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Preemption Priority (Preempt Prio): 8 bits
This field indicates the SMP preemption priority of a protecting LSP,
when the LSP Protection Type field indicates "Shared Mesh Protection".
The SMP preemption priority value is configured
at the end nodes of the protecting LSP by a network operator.
A lower value has a higher priority.
The decision regarding how many priority levels should be implemented in an
SMP network is left to network operators.
See for the definitions of the other fields.
IANA Considerations
IANA maintains a group of registries called "Resource Reservation Protocol
(RSVP) Parameters", which includes the "Error Codes and
Globally-Defined Error Value Sub-Codes" registry. IANA has added the following values to the "Sub-Codes - 25 Notify Error" subregistry, which lists error value sub-codes that may be
used with error code 25. IANA has allocated the following
error value sub-codes () for use with this error code as described in
this document.
New Error Sub-Codes
Value
Description
Reference
17
Shared resources unavailable
RFC 9270
18
Shared resources available
RFC 9270
Security Considerations
Since this document makes use of the exchange of RSVP messages
that include a Notify message, the security threats discussed in
also apply to this document.
Additionally, it may be possible to cause disruption to
traffic on one protecting LSP by targeting a link used by the primary
LSP of another, higher-priority LSP somewhere completely different in
the network.
For example, in ,
assume that the preemption priority of LSP [A,E,F,G,D] is higher than
that of LSP [H,E,F,G,K] and the protecting LSP [H,E,F,G,K] is being
used to transport 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 mechanisms as discussed in
but also to acknowledge that
detailed knowledge of a network's topology, including routes and priorities
of LSPs, can help an attacker better target or improve the efficacy of
an attack.
ReferencesNormative ReferencesGeneric protection switching - Shared mesh protectionInternational Telecommunication UnionITU-T Recommendation G.808.3Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.RSVP-TE: Extensions to RSVP for LSP TunnelsThis document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) ExtensionsThis document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional SpecificationThis document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. [STANDARDS-TRACK]RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) RecoveryThis document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK]GMPLS Segment RecoveryThis document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872). Implications and interactions with fast reroute are also addressed. This document also updates the handling of NOTIFY_REQUEST objects. [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Informative ReferencesOptical transport network - Shared mesh protectionInternational Telecommunication UnionITU-T Recommendation G.873.3MPLS Transport Profile (MPLS-TP) Survivability FrameworkNetwork survivability is the ability of a network to recover traffic delivery following failure or degradation of network resources. Survivability is critical for the delivery of guaranteed network services, such as those subject to strict Service Level Agreements (SLAs) that place maximum bounds on the length of time that services may be degraded or unavailable.The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS data plane that reuses many aspects of the MPLS management and control planes.This document comprises a framework for the provision of survivability in an MPLS-TP network; it describes recovery elements, types, methods, and topological considerations. To enable data-plane recovery, survivability may be supported by the control plane, management plane, and by Operations, Administration, and Maintenance (OAM) functions. This document describes mechanisms for recovering MPLS-TP Label Switched Paths (LSPs). A detailed description of pseudowire recovery in MPLS-TP networks is beyond the scope of this document.This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet-based transport network as defined by the ITU-T.This document is not an Internet Standards Track specification; it is published for informational purposes.Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh ProtectionThis document presents the basic network objectives for the behavior of Shared Mesh Protection (SMP) that are not based on control-plane support. This document provides an expansion of the basic requirements presented in RFC 5654 ("Requirements of an MPLS Transport Profile") and RFC 6372 ("MPLS Transport Profile (MPLS-TP) Survivability Framework"). This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane.Common YANG Data Types for Traffic EngineeringThis document defines a collection of common data types and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities.A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and InterfacesJuniper NetworksCisco Systems IncVolta NetworksJuniper NetworksIndividualTelefonicaWork in ProgressAcknowledgementsThe authors would like to thank ,
, , , , ,
, , , , ,
, and
for their valuable comments and suggestions on this document.
Contributors
The following person contributed significantly to the content of
this document and should be considered a coauthor.
Fujitsutochio@fujitsu.comAuthors' AddressesHuawei TechnologiesF3-1B, R&D Center, Huawei Industrial BaseBantian, Longgang DistrictShenzhenChinahejia@huawei.comHuawei Technologiesitalo.busi@huawei.comETRI218 GajeongnoYuseong-guDaejeon34129South Korea+82-42-860-5384ryoo@etri.re.krETRIbyyun@etri.re.krKTpeter.park@kt.com