summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7087.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7087.txt')
-rw-r--r--doc/rfc/rfc7087.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc7087.txt b/doc/rfc/rfc7087.txt
new file mode 100644
index 0000000..8b19065
--- /dev/null
+++ b/doc/rfc/rfc7087.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) H. van Helvoort, Ed.
+Request for Comments: 7087 L. Andersson, Ed.
+Category: Informational Huawei Technologies
+ISSN: 2070-1721 N. Sprecher, Ed.
+ Nokia Solutions and Networks
+ December 2013
+
+
+ A Thesaurus for the Interpretation of Terminology Used
+ in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs
+ in the Context of the ITU-T's Transport Network Recommendations
+
+Abstract
+
+ The MPLS Transport Profile (MPLS-TP) is based on a profile of the
+ MPLS and Pseudowire (PW) procedures as specified in the MPLS Traffic
+ Engineering (MPLS-TE), PW, and Multi-Segment Pseudowire (MS-PW)
+ architectures developed by the Internet Engineering Task Force
+ (IETF). The International Telecommunication Union Telecommunication
+ Standardization Sector (ITU-T) has specified a Transport Network
+ architecture.
+
+ This document provides a thesaurus for the interpretation of MPLS-TP
+ terminology within the context of the ITU-T Transport Network
+ Recommendations.
+
+ It is important to note that MPLS-TP is applicable in a wider set of
+ contexts than just Transport Networks. The definitions presented in
+ this document do not provide exclusive or complete interpretations of
+ MPLS-TP concepts. This document simply allows the MPLS-TP terms to
+ be applied within the Transport Network context.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ 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). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7087.
+
+
+
+
+van Helvoort, et al. Informational [Page 1]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+Copyright Notice
+
+ Copyright (c) 2013 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
+ (http://trustee.ietf.org/license-info) 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 Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Abbreviations ..............................................4
+ 2. Terminology .....................................................5
+ 2.1. MPLS-TP Terminology Sources ................................5
+ 2.2. ITU-T Transport Network Terminology Sources ................6
+ 2.3. Common Terminology Sources .................................6
+ 3. Thesaurus .......................................................6
+ 3.1. Associated Bidirectional Path ..............................6
+ 3.2. Bidirectional Path .........................................6
+ 3.3. Client-Layer Network .......................................6
+ 3.4. Communication Channel ......................................7
+ 3.5. Concatenated Segment .......................................7
+ 3.6. Control Plane ..............................................7
+ 3.7. Co-Routed Bidirectional Path ...............................7
+ 3.8. Data Communication Network (DCN) ...........................7
+ 3.9. Defect .....................................................8
+ 3.10. Domain ....................................................8
+ 3.11. Embedded Communication Channel (ECC) ......................8
+ 3.12. Equipment Management Function (EMF) .......................8
+ 3.13. Failure ...................................................8
+ 3.14. Fault .....................................................8
+ 3.15. Layer Network .............................................9
+ 3.16. Link ......................................................9
+ 3.17. Maintenance Entity (ME) ...................................9
+ 3.18. Maintenance Entity Group (MEG) ...........................10
+ 3.19. Maintenance Entity Group End Point (MEP) .................10
+ 3.20. Maintenance Entity Group Intermediate Point (MIP) ........11
+ 3.21. Management Communication Channel (MCC) ...................11
+ 3.22. Management Communication Network (MCN) ...................11
+
+
+
+
+
+van Helvoort, et al. Informational [Page 2]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+ 3.23. Monitoring ...............................................11
+ 3.23.1. Path Segment Tunnel (PST) .........................11
+ 3.23.2. Sub-Path Maintenance Element (SPME) ...............12
+ 3.23.3. Tandem Connection .................................12
+ 3.24. MPLS Section .............................................12
+ 3.25. MPLS Transport Profile (MPLS-TP) .........................12
+ 3.26. MPLS-TP NE ...............................................13
+ 3.27. MPLS-TP Network ..........................................13
+ 3.28. MPLS-TP Recovery .........................................13
+ 3.28.1. End-to-End Recovery ...............................13
+ 3.28.2. Link Recovery .....................................13
+ 3.28.3. Segment Recovery ..................................13
+ 3.29. MPLS-TP Ring Topology ....................................13
+ 3.29.1. MPLS-TP Logical Ring ..............................14
+ 3.29.2. MPLS-TP Physical Ring .............................14
+ 3.30. OAM Flow .................................................14
+ 3.31. Operations Support System (OSS) ..........................14
+ 3.32. Path .....................................................14
+ 3.33. Protection Priority ......................................14
+ 3.34. Section-Layer Network ....................................14
+ 3.35. Segment ..................................................15
+ 3.36. Server Layer .............................................15
+ 3.37. Server MEPs ..............................................15
+ 3.38. Signaling Communication Channel (SCC) ....................16
+ 3.39. Signaling Communication Network (SCN) ....................16
+ 3.40. Span .....................................................16
+ 3.41. Sublayer .................................................16
+ 3.42. Transport Entity .........................................16
+ 3.42.1. Working Entity ....................................16
+ 3.42.2. Protection Entity .................................16
+ 3.42.3. Recovery Entity ...................................16
+ 3.43. Transmission Media Layer .................................17
+ 3.44. Transport Network ........................................17
+ 3.45. Transport Path ...........................................17
+ 3.46. Transport-Path Layer .....................................17
+ 3.47. Transport-Service Layer ..................................17
+ 3.48. Unidirectional Path ......................................17
+ 4. Guidance on the Application of This Thesaurus ..................18
+ 5. Management Considerations ......................................18
+ 6. Security Considerations ........................................18
+ 7. Acknowledgments ................................................18
+ 8. Contributors ...................................................18
+ 9. References .....................................................19
+ 9.1. Normative References ......................................19
+ 9.2. Informative References ....................................20
+
+
+
+
+
+
+van Helvoort, et al. Informational [Page 3]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+1. Introduction
+
+ The MPLS Transport Profile (MPLS-TP) has been developed by the IETF
+ to facilitate the Operations, Administration, and Maintenance (OAM)
+ of Label Switched Paths (LSPs) to be used in a Transport Network
+ environment as defined by the ITU-T.
+
+ The ITU-T has specified a Transport Network architecture for the
+ transfer of signals from different technologies. This architecture
+ forms the basis of many Recommendations within the ITU-T.
+
+ Because of the difference in historic background of MPLS, and
+ inherently MPLS-TP (the Internet) and the Transport Network (ITU
+ Telecommunication Sector), the terminology used is different.
+
+ This document provides a thesaurus (the analogy to the Rosetta Stone
+ has been used within the working groups) for the interpretation of
+ MPLS-TP terminology within the context of the ITU-T Transport Network
+ Recommendations. This allows MPLS-TP documents to be generally
+ understood by those familiar with MPLS RFCs. The definitions
+ presented in this document do not provide exclusive or complete
+ interpretations of the ITU-T Transport Network concepts.
+
+1.1. Abbreviations
+
+ CE Customer Edge
+
+ DCC Data Communication Channel
+
+ DCN Data Communication Network
+
+ ECC Embedded Communication Channel
+
+ EMF Equipment Management Function
+
+ EMS Element Management System
+
+ GAL Generic Associated Channel Label
+
+ LER Label Edge Router
+
+ LSR Label Switching Router
+
+ MCC Management Communication Channel
+
+ MCN Management Communication Network
+
+ ME Maintenance Entity
+
+
+
+van Helvoort, et al. Informational [Page 4]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+ MEG Maintenance Entity Group
+
+ MEP Maintenance Entity Group End Point
+
+ MIP Maintenance Entity Group Intermediate Point
+
+ MPLS Multiprotocol Label Switching
+
+ MPLS-TP MPLS Transport Profile
+
+ MS-PW Multi-Segment Pseudowire
+
+ NE Network Element
+
+ NEF Network Element Function
+
+ OAM Operations, Administration, and Maintenance
+
+ OSS Operations Support System
+
+ PM Performance Monitoring
+
+ PST Path Segment Tunnel
+
+ PW Pseudowire
+
+ S-PE Switching Provider Edge
+
+ SCC Signaling Communication Channel
+
+ SCN Signaling Communication Network
+
+ SPME Sub-Path Maintenance Element
+
+ T-PE Terminating Provider Edge
+
+ TCM Tandem Connection Monitoring
+
+2. Terminology
+
+ This section provides an overview regarding terminology used in this
+ document.
+
+2.1. MPLS-TP Terminology Sources
+
+ MPLS-TP terminology is principally defined in [RFC3031]. Other
+ documents, including [RFC4397], provide further key definitions.
+
+
+
+
+van Helvoort, et al. Informational [Page 5]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+2.2. ITU-T Transport Network Terminology Sources
+
+ The ITU-T Transport Network is specified in a number of
+ Recommendations: generic functional architectures and requirements
+ are specified in [ITU-T_G.805], [ITU-T_G.806], and [ITU-T_G.872].
+ ITU-T Recommendation G.8101/Y.1355 [ITU-T_G.8101] contains an
+ overview of the terms and definitions for transport MPLS.
+
+2.3. Common Terminology Sources
+
+ The work in this document builds on the shared view of MPLS
+ requirements. It is intended to provide a source for common MPLS-TP
+ terminology. In general, the original terminology is used.
+
+ The following sources are used:
+
+ o IETF framework and requirements RFCs: [RFC6371], [RFC6372],
+ [RFC5654], [RFC5921], [RFC5860], [RFC5951], [RFC3031], and
+ [RFC4397].
+
+ o ITU-T architecture and requirements Recommendations:
+ [ITU-T_G.8101], [ITU-T_G.805], [ITU-T_G.806], [ITU-T_G.872],
+ [ITU-T_G.7710], and [ITU-T_Y.2611].
+
+3. Thesaurus
+
+3.1. Associated Bidirectional Path
+
+ An associated bidirectional path is a path that supports traffic flow
+ in both directions but that is constructed from a pair of
+ unidirectional paths (one for each direction) that are associated
+ with one another at the path's ingress/egress points. An associated
+ bidirectional path need not be a single management and operational
+ entity. The forward and backward directions are set up, monitored,
+ and protected independently. As a consequence, they may or may not
+ follow the same route (links and nodes) across the network.
+
+3.2. Bidirectional Path
+
+ A bidirectional path refers to a path that supports traffic flow in
+ two opposite directions, i.e., the forward and backward direction.
+
+3.3. Client-Layer Network
+
+ In a client/server relationship (see [ITU-T_G.805]), the client-layer
+ network receives a (transport) service from the lower server-layer
+ network (usually the layer network under consideration).
+
+
+
+
+van Helvoort, et al. Informational [Page 6]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+3.4. Communication Channel
+
+ A Communication Channel is a logical channel between network elements
+ (NEs) that can be used, e.g., for management-plane applications or
+ control-plane applications. The physical channel supporting the
+ Communication Channel is technology specific. See [RFC5951],
+ Appendix A.
+
+3.5. Concatenated Segment
+
+ A concatenated segment is a serial-compound link connection as
+ defined in [ITU-T_G.805]. A concatenated segment is a contiguous
+ part of an LSP or MS-PW that comprises a set of segments and their
+ interconnecting nodes in sequence. See also "Segment"
+ (Section 3.35).
+
+3.6. Control Plane
+
+ Within the scope of [RFC5654], the control plane performs transport
+ path control functions. Through signaling, the control plane sets
+ up, modifies, and releases transport paths and may recover a
+ transport path in case of a failure. The control plane also performs
+ other functions in support of transport path control, such as routing
+ information dissemination. It is possible to operate an MPLS-TP
+ network without using a control plane.
+
+3.7. Co-Routed Bidirectional Path
+
+ A co-routed bidirectional path is a path where the forward and
+ backward directions follow the same route (links and nodes) across
+ the network. A co-routed bidirectional path is managed and operated
+ as a single entity. Both directions are set up, monitored, and
+ protected as a single entity. A Transport Network path is typically
+ co-routed.
+
+3.8. Data Communication Network (DCN)
+
+ A DCN is a network that supports Layer 1 (physical layer), Layer 2
+ (data-link layer), and Layer 3 (network layer) functionality for
+ distributed management communications related to the management
+ plane, for distributed routing and signaling communications related
+ to the control plane, and for other operations communications (e.g.,
+ order-wire/voice communications, software downloads, etc.).
+
+
+
+
+
+
+
+
+van Helvoort, et al. Informational [Page 7]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+3.9. Defect
+
+ "Defect" refers to the situation for which the density of anomalies
+ has reached a level where the ability to perform a required function
+ has been interrupted. Defects are used as input for Performance
+ Monitoring (PM), the control of consequent actions, and the
+ determination of fault cause. See also [ITU-T_G.806].
+
+3.10. Domain
+
+ A domain represents a collection of entities (for example, network
+ elements) that are grouped for a particular purpose, examples of
+ which are administrative and/or managerial responsibilities, trust
+ relationships, addressing schemes, infrastructure capabilities,
+ aggregation, survivability techniques, distributions of control
+ functionality, etc. Examples of such domains include IGP areas and
+ Autonomous Systems.
+
+3.11. Embedded Communication Channel (ECC)
+
+ An ECC is a logical operations channel between network elements (NEs)
+ that can be utilized by multiple applications (e.g., management-plane
+ applications, control-plane applications, etc.). The physical
+ channel supporting the ECC is technology specific. An example of a
+ physical channel supporting the ECC is a Data Communication Channel
+ (DCC) within the Synchronous Digital Hierarchy (SDH).
+
+3.12. Equipment Management Function (EMF)
+
+ The equipment management function (EMF) provides the means through
+ which an element management system (EMS) and other managing entities
+ manage the network element function (NEF). See [ITU-T_G.7710].
+
+3.13. Failure
+
+ A failure is a detected fault. A failure will be declared when the
+ fault cause persisted long enough to consider that a required
+ transport function cannot be performed. The item may be considered
+ as failed; a fault has now been detected. See also [ITU-T_G.806]. A
+ failure can be used as a trigger for corrective actions.
+
+3.14. Fault
+
+ A fault is the inability of a transport function to perform a
+ required action. This does not include an inability due to
+ preventive maintenance, lack of external resources, or planned
+ actions. See also [ITU-T_G.806].
+
+
+
+
+van Helvoort, et al. Informational [Page 8]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+3.15. Layer Network
+
+ "Layer network" is defined in [ITU-T_G.805]. A layer network
+ provides for the transfer of client information and independent
+ operation of the client OAM. A layer network may be described in a
+ service context as follows: one layer network may provide a
+ (transport) service to a higher client-layer network and may, in
+ turn, be a client to a lower-layer network. A layer network is a
+ logical construction somewhat independent of arrangement or
+ composition of physical network elements. A particular physical
+ network element may topologically belong to more than one layer
+ network, depending on the actions it takes on the encapsulation
+ associated with the logical layers (e.g., the label stack) and thus
+ could be modeled as multiple logical elements. A layer network may
+ consist of one or more sublayers. For additional explanation of how
+ layer networks relate to the OSI concept of layering, see Appendix I
+ of [ITU-T_Y.2611].
+
+3.16. Link
+
+ A link as discussed in this document refers to a physical or logical
+ connection between a pair of Label Switching Routers (LSRs) that are
+ adjacent at the (sub)layer network under consideration. A link may
+ carry zero, one, or more LSPs or PWs. A packet entering a link will
+ emerge with the same label-stack entry values.
+
+ A link as defined in [ITU-T_G.805] is used to describe a fixed
+ relationship between two ports.
+
+3.17. Maintenance Entity (ME)
+
+ A Maintenance Entity (ME) can be viewed as the association of two (or
+ more) Maintenance Entity Group End Points (MEPs) that should be
+ configured and managed in order to bound the OAM responsibilities of
+ an OAM flow across a network or sub-network, i.e., a transport path
+ or segment in the specific layer network that is being monitored and
+ managed. See also Section 3.1 of [RFC6371] and Clause 6.1 of
+ [ITU-T_G.8113.1] and [ITU-T_G.8113.2].
+
+ A Maintenance Entity may be defined to monitor and manage
+ bidirectional or unidirectional point-to-point connectivity or point-
+ to-multipoint connectivity in an MPLS-TP layer network.
+
+ Therefore, in the context of an MPLS-TP LSP ME or PW ME, Label Edge
+ Routers (LERs) and PW Terminating Provider Edges (T-PEs) can be MEPs,
+ while LSRs and PW Switching Provider Edges (S-PEs) can be MIPs. In
+ the case of an ME for a tandem connection, LSRs and S-PEs can be
+ either MEPs or MIPs.
+
+
+
+van Helvoort, et al. Informational [Page 9]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+ The following properties apply to all MPLS-TP MEs:
+
+ - OAM entities can be nested but not overlapped.
+
+ - Each OAM flow is associated with a unique Maintenance Entity.
+
+ - OAM packets are subject to the same forwarding treatment as the
+ data traffic, but they are distinct from the data traffic by the
+ Generic Associated Channel Label (GAL).
+
+3.18. Maintenance Entity Group (MEG)
+
+ A Maintenance Entity Group is defined, for the purpose of connection
+ monitoring, between a set of connection points within a connection.
+ This set of connection points may be located at the boundary of one
+ administrative domain or a protection domain or the boundaries of two
+ adjacent administrative domains. The MEG may consist of one or more
+ Maintenance Entities (MEs). See also Section 3.1 of [RFC6371] and
+ Clause 6.2 of [ITU-T_G.8113.1] and [ITU-T_G.8113.2].
+
+ In an MPLS-TP layer network, a MEG consists of only one ME.
+
+3.19. Maintenance Entity Group End Point (MEP)
+
+ Maintenance Entity Group End Points (MEPs) are the end points of a
+ pre-configured (through the management or control planes) ME. MEPs
+ are responsible for activating and controlling all of the OAM
+ functionality for the ME. A source MEP may initiate an OAM packet to
+ be transferred to its corresponding peer MEP (called the sink MEP) or
+ to an intermediate MIP that is part of the ME. See also Section 3.3
+ of [RFC6371] and Clause 6.3 of [ITU-T_G.8113.1] and [ITU-T_G.8113.2].
+
+ A sink MEP terminates all the OAM packets that it receives
+ corresponding to its ME and does not forward them further along the
+ path.
+
+ All OAM packets coming into a source MEP are tunneled via label
+ stacking and are not processed within the ME as they belong either to
+ the client network layers or to a higher Tandem Connection Monitoring
+ (TCM) level.
+
+ A MEP in a tandem connection is not coincident with the termination
+ of the MPLS-TP transport path (LSP or PW), though it can monitor its
+ connectivity (e.g., counts packets). A MEP of an MPLS-TP network
+ transport path is coincident with transport path termination and
+ monitors its connectivity (e.g., counts packets).
+
+
+
+
+
+van Helvoort, et al. Informational [Page 10]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+ An MPLS-TP sink MEP can notify a fault condition to its MPLS-TP
+ client-layer network.
+
+3.20. Maintenance Entity Group Intermediate Point (MIP)
+
+ A Maintenance Entity Group Intermediate Point (MIP) is a point
+ between the two MEPs in an ME and is capable of responding to some
+ OAM packets and forwarding all OAM packets while ensuring fate
+ sharing with data-plane packets. A MIP responds only to OAM packets
+ that are sent on the ME it belongs to and that are addressed to the
+ MIP; it does not initiate OAM messages. See also Section 3.4 of
+ [RFC6371] and Clause 6.4 of [ITU-T_G.8113.1] and [ITU-T_G.8113.2].
+
+3.21. Management Communication Channel (MCC)
+
+ A Communication Channel dedicated to management-plane communications
+ is referred to as a Management Communication Channel (MCC).
+
+3.22. Management Communication Network (MCN)
+
+ A DCN supporting management-plane communication is referred to as a
+ Management Communication Network (MCN).
+
+3.23. Monitoring
+
+ Monitoring is applying OAM functionality to verify and to maintain
+ the performance and the quality guarantees of a transport path.
+ There is a need to not only monitor the whole transport path (e.g.,
+ LSP or MS-PW), but also arbitrary parts of transport paths. The
+ connection between any two arbitrary points along a transport path is
+ described in one of three ways:
+
+ - as a Path Segment Tunnel,
+
+ - as a Sub-Path Maintenance Element, or
+
+ - as a Tandem Connection.
+
+3.23.1. Path Segment Tunnel (PST)
+
+ A path segment is either a segment or a concatenated segment. Path
+ Segment Tunnels (PSTs) are instantiated to provide monitoring of a
+ portion of a set of co-routed transport paths (LSPs or MS-PWs). PSTs
+ can also be employed to meet the requirement to provide Tandem
+ Connection Monitoring. See "Tandem Connection" (Section 3.23.3).
+
+
+
+
+
+
+van Helvoort, et al. Informational [Page 11]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+3.23.2. Sub-Path Maintenance Element (SPME)
+
+ To monitor, protect, and manage a portion (i.e., segment or
+ concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be
+ instantiated. A hierarchical LSP instantiated for this purpose is
+ called a Sub-Path Maintenance Element (SPME). Note that by
+ definition, an SPME does not carry user traffic as a direct client.
+
+ An SPME is defined between the edges of the portion of the LSP that
+ needs to be monitored, protected, or managed. The SPME forms an
+ MPLS-TP Section that carries the original LSP over this portion of
+ the network as a client. OAM messages can be initiated at the edge
+ of the SPME and sent to the peer edge of the SPME or to a MIP along
+ the SPME. A P router only pushes or pops a label if it is at the end
+ of an SPME. In this mode, it is an LER for the SPME.
+
+3.23.3. Tandem Connection
+
+ A tandem connection is an arbitrary part of a transport path that can
+ be monitored (via OAM) independently from the end-to-end monitoring
+ (OAM). It may be a monitored segment, a monitored concatenated
+ segment, or any other monitored ordered sequence of contiguous hops
+ and/or segments (and their interconnecting nodes) of a transport
+ path.
+
+ Tandem Connection Monitoring (TCM) for a given path segment of a
+ transport path is implemented by creating a Path Segment Tunnel that
+ has a 1:1 association with the path segment of the transport path
+ that is to be uniquely monitored. This means that the PST used to
+ provide TCM can carry one and only one transport path, thus allowing
+ direct correlation between all fault-management and performance-
+ monitoring information gathered for the PST and the monitored path
+ segment of the end-to-end transport path. The PST is monitored using
+ normal LSP monitoring. See also Section 3.2 of [RFC6371] and
+ Clause 6.2.1 of [ITU-T_G.8113.1] and [ITU-T_G.8113.2].
+
+3.24. MPLS Section
+
+ An MPLS Section is a network segment between two LSRs that are
+ immediately adjacent at the MPLS layer.
+
+3.25. MPLS Transport Profile (MPLS-TP)
+
+ An MPLS Transport Profile refers to the set of MPLS functions used to
+ support packet transport services and network operations.
+
+
+
+
+
+
+van Helvoort, et al. Informational [Page 12]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+3.26. MPLS-TP NE
+
+ A network element (NE) that supports MPLS-TP functions is referred to
+ as an MPLS-TP NE.
+
+3.27. MPLS-TP Network
+
+ An MPLS-TP network is a network in which MPLS-TP NEs are deployed.
+
+3.28. MPLS-TP Recovery
+
+3.28.1. End-to-End Recovery
+
+ MPLS-TP end-to-end recovery refers to the recovery of an entire LSP,
+ from its ingress to its egress node.
+
+3.28.2. Link Recovery
+
+ MPLS-TP link recovery refers to the recovery of an individual link
+ (and hence all or a subset of the LSPs routed over the link) between
+ two MPLS-TP nodes. For example, link recovery may be provided by
+ server-layer recovery.
+
+3.28.3. Segment Recovery
+
+ MPLS-TP segment recovery refers to the recovery of an LSP segment
+ (i.e., segment and concatenated segment) between two nodes and is
+ used to recover from the failure of one or more links or nodes.
+
+ An LSP segment comprises one or more contiguous hops on the path of
+ the LSP. [RFC5654] defines two terms: a "segment" is a single hop
+ along the path of an LSP, while a "concatenated segment" is more than
+ one hop along the path of an LSP.
+
+3.29. MPLS-TP Ring Topology
+
+ In an MPLS-TP ring topology, each LSR is connected to exactly two
+ other LSRs, each via a single point-to-point bidirectional MPLS-TP
+ capable link. A ring may also be constructed from only two LSRs
+ where there are also exactly two links. Rings may be connected to
+ other LSRs to form a larger network. Traffic originating or
+ terminating outside the ring may be carried over the ring. Client
+ network nodes (such as Customer Edges (CEs)) may be connected
+ directly to an LSR in the ring.
+
+
+
+
+
+
+
+van Helvoort, et al. Informational [Page 13]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+3.29.1. MPLS-TP Logical Ring
+
+ An MPLS-TP logical ring is constructed from a set of LSRs and logical
+ data links (such as MPLS-TP LSP tunnels or MPLS-TP pseudowires) and
+ physical data links that form a ring topology.
+
+3.29.2. MPLS-TP Physical Ring
+
+ An MPLS-TP physical ring is constructed from a set of LSRs and
+ physical data links that form a ring topology.
+
+3.30. OAM Flow
+
+ An OAM flow is the set of all OAM packets originating with a specific
+ source MEP that measure the performance of one direction of a MEG (or
+ possibly both in the special case of data-plane loopback).
+
+3.31. Operations Support System (OSS)
+
+ An OSS is a system that performs the functions that support
+ processing of information related to Operations, Administration,
+ Maintenance, and Provisioning (OAM&P) for the networks, including
+ surveillance and testing functions to support customer access
+ maintenance.
+
+3.32. Path
+
+ See "Transport Path" (Section 3.45).
+
+3.33. Protection Priority
+
+ Fault conditions (e.g., signal failed), external commands (e.g,
+ forced switch, manual switch), and protection states (e.g., no
+ request) are defined to have a relative priority with respect to each
+ other. Priority is applied to these conditions/command/states
+ locally at each end point and between the two end points.
+
+3.34. Section-Layer Network
+
+ A section layer is a server layer (which may be MPLS-TP or a
+ different technology) that provides for the transfer of the section-
+ layer client information between adjacent nodes in the transport-path
+ layer or transport-service layer. A section layer may provide for
+ aggregation of multiple MPLS-TP clients. Note that [ITU-T_G.805]
+ defines the section layer as one of the two layer networks in a
+ transmission-media-layer network. The other layer network is the
+ physical-media-layer network.
+
+
+
+
+van Helvoort, et al. Informational [Page 14]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+ Section-layer networks are concerned with all the functions that
+ provide for the transfer of information between locations in path-
+ layer networks.
+
+ Physical-media-layer networks are concerned with the actual fibers,
+ metallic wires, or radio frequency channels that support a section-
+ layer network.
+
+3.35. Segment
+
+ A segment is a link connection as defined in [ITU-T_G.805]. A
+ segment is the part of an LSP that traverses a single link or the
+ part of a PW that traverses a single link (i.e., that connects a pair
+ of adjacent S-PEs and/or T-PEs). See also "Concatenated Segment"
+ (Section 3.5).
+
+3.36. Server Layer
+
+ A server layer is a layer network in which transport paths are used
+ to carry a customer's (individual or bundled) service (may be point-
+ to-point, point-to-multipoint, or multipoint-to-multipoint services).
+
+ In a client/server relationship (see [ITU-T_G.805]), the server-layer
+ network provides a (transport) service to the higher client-layer
+ network (usually the layer network under consideration).
+
+3.37. Server MEPs
+
+ A server MEP is a MEP of an ME that is defined in a layer network
+ below the MPLS-TP layer network being referenced. A server MEP
+ coincides with either a MIP or a MEP in the client-layer (MPLS-TP)
+ network. See also Section 3.5 of [RFC6371] and Clause 6.5 of
+ [ITU-T_G.8113.1].
+
+ For example, a server MEP can be one of the following:
+
+ o A termination point of a physical link (e.g., IEEE 802.3), an SDH
+ Virtual Circuit (VC), or OTN Optical Data Unit (ODU) for the
+ MPLS-TP Section layer network, defined in [RFC6371], Section 4.1;
+
+ o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [RFC6371],
+ Section 4.2;
+
+ o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [RFC6371],
+ Section 4.3; or
+
+ o An MPLS-TP TCM MEP for higher-level TCMs, defined in [RFC6371],
+ Section 3.2.
+
+
+
+van Helvoort, et al. Informational [Page 15]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+ The server MEP can run appropriate OAM functions for fault detection
+ and notifies a fault indication to the MPLS-TP layer network.
+
+3.38. Signaling Communication Channel (SCC)
+
+ A Signaling Communication Channel is a Communication Channel
+ dedicated to control-plane communications. The SCC may be used for
+ GMPLS / Automatically Switched Optical Network (ASON) signaling
+ and/or other control-plane messages (e.g., routing messages).
+
+3.39. Signaling Communication Network (SCN)
+
+ A DCN supporting control-plane communication is referred to as a
+ Signaling Communication Network (SCN).
+
+3.40. Span
+
+ A span is synonymous with a link.
+
+3.41. Sublayer
+
+ "Sublayer" is defined in [ITU-T_G.805]. The distinction between a
+ layer network and a sublayer is that a sublayer is not directly
+ accessible to clients outside of its encapsulating layer network and
+ offers no direct transport service for a higher-layer (client)
+ network.
+
+3.42. Transport Entity
+
+ A transport entity is a node, link, transport path segment,
+ concatenated transport path segment, or entire transport path.
+
+3.42.1. Working Entity
+
+ A working entity is a transport entity that carries traffic during
+ normal network operation.
+
+3.42.2. Protection Entity
+
+ A protection entity is a transport entity that is pre-allocated and
+ used to protect and transport traffic when the working entity fails.
+
+3.42.3. Recovery Entity
+
+ A recovery entity is a transport entity that is used to recover and
+ transport traffic when the working entity fails.
+
+
+
+
+
+van Helvoort, et al. Informational [Page 16]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+3.43. Transmission Media Layer
+
+ A transmission media layer is a layer network, consisting of a
+ section-layer network and a physical-layer network as defined in
+ [ITU-T_G.805], that provides sections (two-port point-to-point
+ connections) to carry the aggregate of network-transport path or
+ network-service layers on various physical media.
+
+3.44. Transport Network
+
+ A Transport Network provides transmission of traffic between attached
+ client devices by establishing and maintaining point-to-point or
+ point-to-multipoint connections between such devices. A Transport
+ Network is independent of any higher-layer network that may exist
+ between clients, except to the extent required to supply this
+ transmission service. In addition to client traffic, a Transport
+ Network may carry traffic to facilitate its own operation, such as
+ that required to support connection control, network management, and
+ OAM functions.
+
+3.45. Transport Path
+
+ A transport path is a network connection as defined in [ITU-T_G.805].
+ In an MPLS-TP environment, a transport path corresponds to an LSP or
+ a PW.
+
+3.46. Transport-Path Layer
+
+ A transport-path layer is a (sub)layer network that provides point-
+ to-point or point-to-multipoint transport paths. It provides OAM
+ that is independent of the clients that it is transporting.
+
+3.47. Transport-Service Layer
+
+ A transport-service layer is a layer network in which transport paths
+ are used to carry a customer's (individual or bundled) service (may
+ be point-to-point, point-to-multipoint, or multipoint-to-multipoint
+ services).
+
+3.48. Unidirectional Path
+
+ A unidirectional path is a path that supports traffic flow in only
+ one direction.
+
+
+
+
+
+
+
+
+van Helvoort, et al. Informational [Page 17]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+4. Guidance on the Application of This Thesaurus
+
+ As discussed in the introduction to this document, this thesaurus is
+ intended to bring the concepts and terms associated with MPLS-TP into
+ the context of the ITU-T's Transport Network architecture. Thus, it
+ should help those familiar with MPLS to see how they may use the
+ features and functions of the Transport Network in order to meet the
+ requirements of MPLS-TP.
+
+5. Management Considerations
+
+ Networks based on MPLS-TP require management. The MPLS-TP
+ specifications described in [RFC5654], [RFC5860], [RFC5921],
+ [RFC5951], [RFC6371], [RFC6372], [ITU-T_G.8110.1], and [ITU-T_G.7710]
+ include considerable efforts to provide operator control and
+ monitoring as well as OAM functionality.
+
+ These concepts are, however, out of the scope of this document.
+
+6. Security Considerations
+
+ Security is a significant requirement of MPLS-TP. See [RFC6941] for
+ more information.
+
+ However, this informational document is intended only to provide a
+ lexicography, and the security concerns are, therefore, out of the
+ scope of this document.
+
+7. Acknowledgments
+
+ The authors would like to thank all members of the teams (the Joint
+ Working Team, the MPLS Interoperability Design Team in the IETF, and
+ the MPLS-TP Ad Hoc Group in the ITU-T) involved in the definition and
+ specification of the MPLS Transport Profile. We would in particular
+ like to acknowledge the contributions by Tom Petch to improve the
+ quality of this document. Abdussalam Baryun also reviewed this
+ document.
+
+8. Contributors
+
+ The following individuals contributed to this document: Italo Busi,
+ Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven Levrau, Dinesh
+ Mohan, Stewart Bryant, Dan Frost, Matthew Bocci, Vincenzo Sestito,
+ Martin Vigoureux, and Yaacov Weingarten.
+
+
+
+
+
+
+
+van Helvoort, et al. Informational [Page 18]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+9. References
+
+9.1. Normative References
+
+ [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+ Label Switching Architecture", RFC 3031, January 2001.
+
+ [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
+ Sprecher, N., and S. Ueno, "Requirements of an MPLS
+ Transport Profile", RFC 5654, September 2009.
+
+ [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
+ "Requirements for Operations, Administration, and
+ Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
+ May 2010.
+
+ [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
+ L., and L. Berger, "A Framework for MPLS in Transport
+ Networks", RFC 5921, July 2010.
+
+ [RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management
+ Requirements for MPLS-based Transport Networks", RFC 5951,
+ September 2010.
+
+ [RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations,
+ Administration, and Maintenance Framework for MPLS-Based
+ Transport Networks", RFC 6371, September 2011.
+
+ [RFC6372] Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport
+ Profile (MPLS-TP) Survivability Framework", RFC 6372,
+ September 2011.
+
+ [ITU-T_G.805]
+ ITU-T Recommendation G.805, "Generic functional
+ architecture of transport networks", March 2000,
+ <http://www.itu.int/rec/T-REC/>.
+
+ [ITU-T_G.806]
+ ITU-T Recommendation G.806, "Characteristics of transport
+ equipment - Description methodology and generic
+ functionality", March 2006,
+ <http://www.itu.int/rec/T-REC/>.
+
+ [ITU-T_G.872]
+ ITU-T Recommendation G.872, "Architecture of optical
+ transport networks", November 2001,
+ <http://www.itu.int/rec/T-REC/>.
+
+
+
+
+van Helvoort, et al. Informational [Page 19]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+ [ITU-T_G.7710]
+ ITU-T Recommendation G.7710, "Common equipment management
+ function requirements", July 2007,
+ <http://www.itu.int/rec/T-REC/>.
+
+ [ITU-T_G.8101]
+ ITU-T Recommendation G.8101/Y.1355, "Terms and definitions
+ for MPLS Transport Profile", September 2013,
+ <http://www.itu.int/rec/T-REC/>.
+
+ [ITU-T_G.8110.1]
+ ITU-T Recommendation G.8110.1/Y.1370.1, "Architecture of
+ the Multi-Protocol Label Switching transport profile layer
+ network", December 2011, <http://www.itu.int/rec/T-REC/>.
+
+ [ITU-T_G.8113.1]
+ ITU-T Recommendation G.8113.1/Y.1372.1, "Operations,
+ administration and maintenance mechanism for MPLS-TP in
+ packet transport network (PTN)", November 2012,
+ <http://www.itu.int/rec/T-REC/>.
+
+ [ITU-T_G.8113.2]
+ ITU-T Recommendation G.8113.2/Y.1372.2, "Operations,
+ administration and maintenance mechanisms for MPLS-TP
+ networks using the tools defined for MPLS", November 2012,
+ <http://www.itu.int/rec/T-REC/>.
+
+ [ITU-T_Y.2611]
+ ITU-T Recommendation Y.2611, "High-level architecture of
+ future packet-based networks", December 2006,
+ <http://www.itu.int/rec/T-REC/>.
+
+9.2. Informative References
+
+ [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the
+ Interpretation of Generalized Multiprotocol Label
+ Switching (GMPLS) Terminology within the Context of the
+ ITU-T's Automatically Switched Optical Network (ASON)
+ Architecture", RFC 4397, February 2006.
+
+ [RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed.,
+ and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP)
+ Security Framework", RFC 6941, April 2013.
+
+
+
+
+
+
+
+
+van Helvoort, et al. Informational [Page 20]
+
+RFC 7087 MPLS-TP Rosetta Stone December 2013
+
+
+Authors' Addresses
+
+ Huub van Helvoort (editor)
+ Huawei Technologies Co., Ltd.
+
+ EMail: Huub.van.Helvoort@huawei.com
+
+
+ Loa Andersson (editor)
+ Huawei Technologies Co., Ltd.
+
+ EMail: loa@mail01.huawei.com
+
+
+ Nurit Sprecher (editor)
+ Nokia Solutions and Networks
+
+ EMail: nurit.sprecher@nsn.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+van Helvoort, et al. Informational [Page 21]
+