RFC 7087

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

📅 published December 2013, from ietf

RFC 7087: 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 🦋

okay bestie, let's start with the title block 💅 It's an Informational RFC, published in December 2013, with ISSN 2070-1721. The editors are H. van Helvoort (Ed.), L. Andersson (Ed.), and N. Sprecher (Ed.), from Huawei Technologies and Nokia Solutions and Networks. There's no Obsoletes or Updates line in the header, so it doesn't list any RFCs it replaces or changes. 🌸

Abstract ✨

so the MPLS Transport Profile (MPLS-TP) is built on a profile of the MPLS and Pseudowire (PW) procedures from the MPLS Traffic Engineering (MPLS-TE), PW, and Multi-Segment Pseudowire (MS-PW) architectures. The IETF made all of those 🎀 Meanwhile, the ITU-T (International Telecommunication Union Telecommunication Standardization Sector) specified its own Transport Network architecture.

this document is a thesaurus, a little dictionary, for reading MPLS-TP terms in the context of the ITU-T Transport Network Recommendations 📖

and it's important to know that MPLS-TP works in a bunch of contexts, not only Transport Networks 🌈 The definitions here are not the only or complete meanings of MPLS-TP concepts. They just let MPLS-TP terms be used inside the Transport Network context. no cap, that's the whole point 💜

Status of This Memo 🌷

this one is not an Internet Standards Track specification. It's published just for information 🧚

It's a product of the Internet Engineering Task Force (IETF) and it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is up for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🫶

You can find the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7087. 🔗

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, which you can read at http://trustee.ietf.org/license-info as they stood on the publication date. Please actually read them, because they explain your rights and restrictions for this document 👀

If you pull Code Components out of this document, they have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, same as the Simplified BSD License says 🍓

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
   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

1. Introduction 🎀

okay so the MPLS Transport Profile (MPLS-TP) was developed by the IETF to make Operations, Administration, and Maintenance (OAM) easier for Label Switched Paths (LSPs). The goal is for them to be used in a Transport Network environment, which is the kind the ITU-T defines 🚀

the ITU-T has its own Transport Network architecture for moving signals from different technologies around. That architecture is the foundation for lots of ITU-T Recommendations 🌍

the vibe is that MPLS and MPLS-TP come from the Internet world, and the Transport Network comes from the ITU Telecommunication Sector. Because they have different histories, they use different words for things. it's giving two friends who speak different languages but are both obsessed with the same movie 😭

so this document is a thesaurus (the working groups called it a Rosetta Stone, which is iconic 💜) for reading MPLS-TP terms in the context of the ITU-T Transport Network Recommendations. That means MPLS-TP documents can be understood by people who already know MPLS RFCs 🦋 The definitions here don't give the only or complete meanings of ITU-T Transport Network concepts, so keep that in mind 🌸

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
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 gives you an overview of the terminology used in the document 💅

2.1. MPLS-TP Terminology Sources 📘

MPLS-TP terminology is mainly defined in [RFC3031]. Other documents, including [RFC4397], provide more key definitions 💖

2.2. ITU-T Transport Network Terminology Sources 🌐

the ITU-T Transport Network is specified across a bunch of Recommendations. The generic functional architectures and requirements are 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] has an overview of the terms and definitions for transport MPLS 🫶

2.3. Common Terminology Sources 💅

This bit is all about where the shared MPLS-TP vocab comes from 🧚 The work here builds on the shared view of MPLS requirements, and it's meant to be a source for common MPLS-TP terminology. Generally, the original terminology is kept, so no making things up 🌸

These are the sources being used 👇

  • IETF framework and requirements RFCs: [RFC6371], [RFC6372], [RFC5654], [RFC5921], [RFC5860], [RFC5951], [RFC3031], and [RFC4397].
  • 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 🔗

Okay so an associated bidirectional path is a path that carries traffic both ways, but it's built from a pair of unidirectional paths (one for each direction) that are linked to each other at the path's ingress/egress points. It doesn't have to be one single management and operational entity, fr. The forward and backward directions get set up, monitored, and protected independently, so they may or may not follow the same route (links and nodes) across the network 🦋

3.2. Bidirectional Path ↔️

A bidirectional path is a path that handles traffic in two opposite directions, aka the forward and backward direction. Simple and iconic 💖

3.3. Client-Layer Network 🧁

In a client/server relationship (see [ITU-T_G.805]), the client-layer network gets a (transport) service from the lower server-layer network, which is usually the layer network under consideration. It's giving layers within layers 🎀

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. For more, see [RFC5951], Appendix A 🌈

3.5. Concatenated Segment 🔗

A concatenated segment is a serial-compound link connection as defined in [ITU-T_G.805]. It's 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 does the transport path control functions. Through signaling, it sets up, modifies, and releases transport paths, and it may recover a transport path if something fails. It also does other stuff that supports transport path control, like routing information dissemination 💅 And here's the plot twist: 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. It's managed and operated as a single entity, so both directions get set up, monitored, and protected together 🫶 A Transport Network path is typically co-routed, which is very on-brand for it 💜

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. It covers distributed management communications related to the management plane, distributed routing and signaling communications related to the control plane, and other operations communications (e.g., order-wire/voice communications, software downloads, etc.) 🎧

3.9. Defect 🚨

"Defect" refers to the situation where 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 is a collection of entities (for example, network elements) grouped together for a particular purpose. Examples of that purpose include 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 used by multiple applications (e.g., management-plane applications, control-plane applications, etc.). The physical channel supporting the ECC is technology specific. One 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) gives an element management system (EMS) and other managing entities the means to manage the network element function (NEF). See [ITU-T_G.7710] 🧚

3.13. Failure 💥

A failure is a detected fault. A failure gets declared when the fault cause has persisted long enough to consider that a required transport function cannot be performed. The item may be considered as failed, because 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] 🌸

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. In a service context, 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. Layer networks are logical constructions, somewhat independent of the 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 so it could be modeled as multiple logical elements. A layer network may consist of one or more sublayers. For more on how layer networks relate to the OSI concept of layering, see Appendix I of [ITU-T_Y.2611] 🎀

A link, as discussed in this document, is 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. In other words, it's 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 🌈

So, 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. For a tandem connection ME, LSRs and S-PEs can be either MEPs or MIPs 👑

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. That set of connection points may be located at the boundary of one administrative domain or a protection domain, or at 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. Just one, bestie 🙈

3.19. Maintenance Entity Group End Point (MEP) 📍

Maintenance Entity Group End Points (MEPs) are the end points of a pre-configured ME (configured through the management or control planes). 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 it 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, because 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 it monitors its connectivity (e.g., counts packets) 📊

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. It's 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, and 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's 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) ✨

okay so a path segment is either a segment or a concatenated segment 🦋 and then we get Path Segment Tunnels (PSTs), which are instantiated to monitor a portion of a set of co-routed transport paths (LSPs or MS-PWs) 💖 they can also be used to meet the need for Tandem Connection Monitoring, so check out "Tandem Connection" (Section 3.23.3) 🧚

3.23.2. Sub-Path Maintenance Element (SPME) 💅

bestie, so say you want to monitor, protect, and manage just a piece (a segment or concatenated segment) of an LSP 🌸 you can set up a hierarchical LSP [RFC3031] for that, and when you do it for this purpose it's called a Sub-Path Maintenance Element (SPME) 🎀 lowkey the key thing: by definition, an SPME does not carry user traffic as a direct client 🙈

the SPME gets defined between the edges of the portion of the LSP that needs the monitoring, protection, or management 🫶 it forms an MPLS-TP Section that carries the original LSP over that part of the network as a client ✨ OAM messages can start at the edge of the SPME and get sent to the peer edge of the SPME or to a MIP along the SPME 🦋 and a P router only pushes or pops a label if it's at the end of an SPME 💜 in that mode, it's an LER for the SPME 👑 it's giving main character energy ngl 😭

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 can 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 done 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 🎀 so the PST used for TCM can carry one and only one transport path ✨ which means you can directly correlate all the fault-management and performance-monitoring info gathered for the PST with 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 ✨

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 🧚

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 it's 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 💜

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 💅

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: 🌸

  • 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 💜
  • an MPLS-TP Section MEP for MPLS-TP LSPs, defined in [RFC6371], Section 4.2 🧚
  • an MPLS-TP LSP MEP for MPLS-TP PWs, defined in [RFC6371], Section 4.3 ✨; or
  • an MPLS-TP TCM MEP for higher-level TCMs, defined in [RFC6371], Section 3.2 🌈

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 🫶

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 🔥

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 🎀

Okay so, networks built on MPLS-TP need management, bestie 💅 Operators need to be in control and keep an eye on things. The MPLS-TP specs in [RFC5654], [RFC5860], [RFC5921], [RFC5951], [RFC6371], [RFC6372], [ITU-T_G.8110.1], and [ITU-T_G.7710] put in serious work on operator control, monitoring, and OAM functionality ✨

That said, these concepts are out of the scope of this document 🦋

6. Security Considerations 💀

Security is a big deal for MPLS-TP 🔥 For more info, go check out [RFC6941].

This informational document is only meant to provide a lexicography, so the security concerns are out of the scope of this document. Please don't skip over this one. Security matters, and the full picture lives in the other specs.

7. Acknowledgments 🫶

The authors want to thank everyone in the teams that helped define and specify the MPLS Transport Profile: the Joint Working Team, the MPLS Interoperability Design Team in the IETF, and the MPLS-TP Ad Hoc Group in the ITU-T 🌈 Special shout-out to Tom Petch, whose contributions made this document so much better, and to Abdussalam Baryun, who also reviewed it 💜

8. Contributors 🌸

The following people 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. Iconic squad 👑

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/>.
  • [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.

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

📦 where this page comes from