MPLS Working Group
Internet Engineering Task Force (IETF)              H. van Helvoort (Ed)
Internet Draft                                     Huawei Technologies
Intended status: Informational
Expires: April 2014 Helvoort, Ed.
Request for Comments: 7087                             L. Andersson (Ed) Andersson, Ed.
Category: Informational                              Huawei Technologies
ISSN: 2070-1721                                         N. Sprecher (Ed) Sprecher, Ed.
                                            Nokia Solutions and Networks

                                                      October 20,
                                                           December 2013

         A Thesaurus for the Interpretation of Terminology used Used
      in Multiprotocol Label
       Switching MPLS Transport Profile (MPLS-TP) drafts/RFCs Internet-Drafts and RFCs
    in the Context of the ITU-T's Transport Network Recommendations.
                    draft-ietf-mpls-tp-rosetta-stone-13 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-TE, PW MPLS Traffic
   Engineering (MPLS-TE), PW, and Multi-Segment Pseudowire (MS-PW)
   architectures developed by the Internet Engineering Task Force
   (IETF).  The International
   Telecommunications Telecommunication Union Telecommunications 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 nor 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 This Memo

   This Internet-Draft document is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum
   (IETF).  It represents the consensus of six
   months the IETF community.  It has
   received public review and may be updated, replaced, or obsoleted has been approved for publication by other the
   Internet Engineering Steering Group (IESG).  Not all documents
   at
   approved by the IESG are a candidate for any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list status of Internet-Draft Shadow Directories can this document, any errata,
   and how to provide feedback on it may be accessed obtained at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 20, 2014.
   http://www.rfc-editor.org/info/rfc7087.

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

   1. Introduction  4
      1.1  Contributing Authors 4
      1.2 ....................................................4
      1.1. Abbreviations 4
   2 ..............................................4
   2. Terminology 6
      2.1 .....................................................5
      2.1. MPLS-TP Terminology Sources  6
      2.2 ................................5
      2.2. ITU-T Transport Network Terminology Sources 6
      2.3 ................6
      2.3. Common Terminology Sources 6
   3 .................................6
   3. Thesaurus  6
      3.1 .......................................................6
      3.1. Associated bidirectional path:  6
      3.2 Bidirectional path: 7
      3.3  Client layer network:  7
      3.4 Path ..............................6
      3.2. Bidirectional Path .........................................6
      3.3. Client-Layer Network .......................................6
      3.4. Communication Channel: 7
      3.5 Channel ......................................7
      3.5. Concatenated Segment:  7
      3.6 Segment .......................................7
      3.6. Control Plane: 7
      3.7  Co-routed bidirectional path: 7
      3.8 Plane ..............................................7
      3.7. Co-Routed Bidirectional Path ...............................7
      3.8. Data Communication Network (DCN):  8
      3.9  Defect: 8
      3.10 Domain: 8
      3.11 (DCN) ...........................7
      3.9. Defect .....................................................8
      3.10. Domain ....................................................8
      3.11. Embedded Communication Channel (ECC): 8
      3.12 (ECC) ......................8
      3.12. Equipment Management Function (EMF):  8
      3.13 Failure: 8
      3.14 Fault:  9
      3.15 (EMF) .......................8
      3.13. Failure ...................................................8
      3.14. Fault .....................................................8
      3.15. Layer network: 9
      3.16 Link: 9
      3.17 Network .............................................9
      3.16. Link ......................................................9
      3.17. Maintenance Entity (ME):  9
      3.18 (ME) ...................................9
      3.18. Maintenance Entity Group (MEG): 10
      3.19 (MEG) ...........................10
      3.19. Maintenance Entity Group End Point (MEP): 10
      3.20 (MEP) .................10
      3.20. Maintenance Entity Group Intermediate Point (MIP): 11
      3.21 (MIP) ........11
      3.21. Management Communication Channel (MCC):  11
      3.22 (MCC) ...................11
      3.22. Management Communication Network (MCN):  11
      3.23 (MCN) ...................11
      3.23. Monitoring 11
         3.23.1 ...............................................11
           3.23.1. Path Segment Tunnel (PST): 12
         3.23.2 (PST) .........................11
           3.23.2. Sub-Path Maintenance Element (SPME):  12
         3.23.3 (SPME) ...............12
           3.23.3. Tandem Connection:  12
      3.24 Connection .................................12
      3.24. MPLS Section: 13
      3.25 Section .............................................12
      3.25. MPLS Transport Profile (MPLS-TP):  13
      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 (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 Recovery .....................................13
           3.28.3. Segment recovery: 13
      3.29 Recovery ..................................13
      3.29. MPLS-TP Ring Topology: 13
         3.29.1 Topology ....................................13
           3.29.1. MPLS-TP Logical Ring:  14
         3.29.2 Ring ..............................14
           3.29.2. MPLS-TP Physical Ring: 14
      3.30 Ring .............................14
      3.30. OAM flow:  14
      3.31 Flow .................................................14
      3.31. Operations Support System (OS): 14
      3.32 Path: 14
      3.33 (OSS) ..........................14
      3.32. Path .....................................................14
      3.33. Protection priority: 14
      3.34 Section Layer Network: 14
      3.35 Segment: 15
      3.36 Priority ......................................14
      3.34. Section-Layer Network ....................................14
      3.35. Segment ..................................................15
      3.36. Server layer: 15
      3.37 Layer .............................................15
      3.37. Server MEPs:  15
      3.38 MEPs ..............................................15
      3.38. Signaling Communication Channel (SCC): 16
      3.39 (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 (SCN) ....................16
      3.40. Span .....................................................16
      3.41. Sublayer .................................................16
      3.42. Transport Entity .........................................16
           3.42.1. Working Entity:  16
         3.42.2 Entity ....................................16
           3.42.2. Protection Entity:  17
         3.42.3 Entity .................................16
           3.42.3. Recovery entity: 17
      3.43 Entity ...................................16
      3.43. Transmission media layer: 17
      3.44 Transport Network:  17
      3.45 Transport path:  17
      3.46 Media Layer .................................17
      3.44. Transport path layer:  17
      3.47 Network ........................................17
      3.45. Transport service layer:  18
      3.48 Path ...........................................17
      3.46. Transport-Path Layer .....................................17
      3.47. Transport-Service Layer ..................................17
      3.48. Unidirectional path: 18
   4 Path ......................................17
   4. Guidance on the Application of this This Thesaurus  18
   5 ..................18
   5. Management Considerations 18
   6 ......................................18
   6. Security Considerations 18
   7 IANA Considerations 19
   8 ........................................18
   7. Acknowledgments  19
   9 ................................................18
   8. Contributors ...................................................18
   9. References 19
      9.1 .....................................................19
      9.1. Normative References 19
      9.2 ......................................19
      9.2. Informative References 20

1 ....................................20

1.  Introduction

   Multiprotocol Label Switching -

   The MPLS Transport Profile (MPLS-TP) has been developed by the IETF
   to facilitate the Operation, Administration Operations, Administration, and Management 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.2

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

   NEF  Network Element Function

   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 PW     Switching Provider Edge

   SCC      Signaling Communication Channel

   SCN      Signaling Communication Network

   SPME     Sub-Path Maintenance Element

   T-PE PW     Terminating Provider Edge

   TCM      Tandem Connection Monitoring

2

2.  Terminology

2.1

   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
   documents, including [RFC4397], provide further key definitions including [RFC4397].

2.2 definitions.

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 terms and Definitions definitions for transport MPLS.

2.3

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 general, the original terminology is used.

   The following sources are used:

   o  IETF framework and requirements RFCs: [RFC6371], [RFC6372],
      [RFC5654], [RFC5921], [RFC5860], [RFC5951], [RFC3031] [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]
      [ITU-T_G.7710], and
   [ITU-T Y.2611].

3 [ITU-T_Y.2611].

3.  Thesaurus

3.1

3.1.  Associated Bidirectional Path

   An associated bidirectional path:

   A 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 needs need not be a single management and operational
   entity.  The forward and backward directions are setup, 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

3.2.  Bidirectional path: Path

   A bidirectional path refers to a path that supports traffic flow in
   two opposite directions, i.e. i.e., the forward and backward direction.

3.3 Client layer network:

3.3.  Client-Layer Network

   In a client/server relationship (see [ITU-T_G.805]), the client
   layer client-layer
   network receives a (transport) service from the lower server
   layer server-layer
   network (usually the layer network under consideration).

3.4

3.4.  Communication Channel: Channel

   A Communication Channel is a logical channel between network elements
   (NEs) that can be used -
   e.g. - used, e.g., for management plane application management-plane applications or control plane
   control-plane applications.  The physical channel supporting the
   Communication Channel is technology specific.  See [RFC5951] [RFC5951],
   Appendix A.

3.5

3.5.  Concatenated Segment: 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-PWthat MS-PW that comprises a set of segments and their
   interconnecting nodes in sequence.  See also "Segment".

3.6 "Segment"
   (Section 3.35).

3.6.  Control Plane: Plane

   Within the scope of [RFC5654], the control plane performs transport
   path control functions.  Through signalling, signaling, the control plane sets
   up, modifies modifies, and releases transport paths, 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: 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 setup, monitored set up, monitored, and
   protected as a single entity.  A
   transport network Transport Network path is typically
   co-routed.

3.8

3.8.  Data Communication Network (DCN): (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
   order-wire/voice communications, software downloads, etc.).

3.9 Defect:

   The

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:

3.10.  Domain

   A domain represents a collection of entities (for example 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

3.11.  Embedded Communication Channel (ECC):

   A (ECC)

   An ECC is a logical operations channel between network elements (NEs)
   that can be utilized by multiple applications (e.g., management plane management-plane
   applications, control plane 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 SDH.

3.12 the Synchronous Digital Hierarchy (SDH).

3.12.  Equipment Management Function (EMF): (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: [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 the ability of an item
   to perform that a required
   transport function to cannot be terminated. 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

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:

3.15.  Layer network 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 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), 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: [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 one, or more LSPs or PWs.  A packet entering a link will
   emerge with the same label stack 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

3.17.  Maintenance Entity (ME): (ME)

   A Maintenance Entity (ME) can be viewed as the association of two (or
   more) Maintenance Entity Group End Points (MEPs), (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. i.e., a transport path
   or segment, segment in the specific layer network that is being monitored and
   managed.  See also [RFC6371] section Section 3.1 of [RFC6371] and Clause 6.1 of
   [ITU-T_G.8113.1] and [ITU-T G.8113.1],
   [ITU-T G.8113.2] clause 6.1. [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 point-
   to-multipoint connectivity in an MPLS-TP layer network.

   Therefore, in the context of a an MPLS-TP LSP ME or PW ME ME, Label Edge
   Routers (LERs) and PW Terminating Provider Edges (T-PEs) can be MEPs MEPs,
   while LSRs and PW Switching Provider Edges (S-PEs) can be MIPs.  In
   the case of a an ME for a Tandem Connection, tandem connection, 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 to 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

3.18.  Maintenance Entity Group (MEG): (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, domain or the boundaries of two
   adjacent administrative domains.  The MEG may consist of one or more
   Maintenance Entities (ME). (MEs).  See also [RFC6371] section Section 3.1 of [RFC6371] and
   [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.2.
   Clause 6.2 of [ITU-T_G.8113.1] and [ITU-T_G.8113.2].

   In an MPLS-TP layer network network, a MEG consists of only one ME.

3.19

3.19.  Maintenance Entity Group End Point (MEP): (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 or MEP (called the sink MEP, MEP) or
   to an intermediate MIP that is part of the ME.  See also [RFC6371] section Section 3.3
   of [RFC6371] and [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.3. 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 tunnelled 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. count (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. (e.g., counts packets).

   An MPLS-TP sink MEP can notify a fault condition to its MPLS-TP
   client layer
   client-layer network.

3.20

3.20.  Maintenance Entity Group Intermediate Point (MIP): (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 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,
   MIP; it does not initiate OAM messages.  See also [RFC6371] section Section 3.4 of
   [RFC6371] and Clause 6.4 of [ITU-T_G.8113.1] and [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.4.

3.21 [ITU-T_G.8113.2].

3.21.  Management Communication Channel (MCC): (MCC)

   A Communication Channel dedicated for management plane
   communications.

3.22 to management-plane communications
   is referred to as a Management Communication Channel (MCC).

3.22.  Management Communication Network (MCN): (MCN)

   A DCN supporting management plane management-plane communication is referred to as a
   Management Communication Network (MCN).

3.23

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

3.23.1.  Path Segment Tunnel (PST): (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).
   Path segment tunnels  PSTs
   can also be employed to meet the requirement to provide Tandem
   Connection Monitoring, see Tandem Connection.

3.23.2 Monitoring.  See "Tandem Connection" (Section 3.23.3).

3.23.2.  Sub-Path Maintenance Element (SPME): (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
   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 protected, or managed.  The SPME forms a MPLS-
   TP 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
   a an SPME.  In this mode, it is an LER for the SPME.

3.23.3

3.23.3.  Tandem Connection: 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
   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 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 path, thus allowing
   direct correlation between all fault management fault-management and performance 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 [RFC6371] section Section 3.2 of [RFC6371] and
   Clause 6.2.1 of [ITU-T_G.8113.1] and
   [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.2.1.

3.24 [ITU-T_G.8113.2].

3.24.  MPLS Section:

   A Section

   An MPLS Section is a network segment between two LSRs that are
   immediately adjacent at the MPLS layer.

3.25

3.25.  MPLS Transport Profile (MPLS-TP):

   The (MPLS-TP)

   An MPLS Transport Profile refers to the set of MPLS functions used to
   support packet transport services and network operations.

3.26

3.26.  MPLS-TP NE: NE

   A network element (NE) that supports MPLS-TP functions.

3.27 functions is referred to
   as an MPLS-TP network:

   A NE.

3.27.  MPLS-TP Network

   An MPLS-TP network is a network in which MPLS-TP NEs are deployed.

3.28

3.28.  MPLS-TP Recovery:

3.28.1  End-to-end recovery: Recovery

3.28.1.  End-to-End Recovery

   MPLS-TP End-to-end end-to-end recovery refers to the recovery of an entire LSP,
   from its ingress to its egress node.

3.28.2

3.28.2.  Link recovery: 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
   server-layer recovery.

3.28.3

3.28.3.  Segment recovery: Recovery

   MPLS-TP Segment 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 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

3.29.  MPLS-TP Ring Topology: 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

3.29.1.  MPLS-TP Logical Ring: Ring

   An MPLS-TP logical ring is constructed from a set of LSRs and logical
   data links (such as MPLS-TP LSP tunnels or MSPL-TP MPLS-TP pseudowires) and
   physical data links that form a ring topology.

3.29.2

3.29.2.  MPLS-TP Physical Ring: Ring

   An MPLS-TP physical ring is constructed from a set of LSRs and
   physical data links that form a ring topology.

3.30

3.30.  OAM flow: Flow

   An OAM flow is the set of all OAM packets originating with a specific
   source MEP that instrument measure the performance of one direction of a MEG (or
   possibly both in the special case of data plane data-plane loopback).

3.31

3.31.  Operations Support System (OSS):

   A (OSS)

   An OSS is a system that performs the functions that support
   processing of information related to operations, administration, maintenance, Operations, Administration,
   Maintenance, and
   provisioning Provisioning (OAM&P) for the networks, including
   surveillance and testing functions to support customer access
   maintenance.

3.32 Path:

3.32.  Path

   See Transport path.

3.33 "Transport Path" (Section 3.45).

3.33.  Protection priority: Priority

   Fault conditions (e.g., signal failed), external commands (e.g,
   forced switch, manual switch) 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:

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 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] [ITU-T_G.805]
   defines the section layer as one of the two layer networks in a transmission-media layer
   transmission-media-layer network.  The other layer network is the physical-media layer
   physical-media-layer network.

   Section layer

   Section-layer networks are concerned with all the functions which that
   provide for the transfer of information between locations in path path-
   layer networks.

   Physical media layer

   Physical-media-layer networks are concerned with the actual fibres, fibers,
   metallic wires wires, or radio frequency channels which that support a section section-
   layer network.

3.35 Segment:

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 S-PEs and/or T-PEs).  See also "Concatenated Segment".

3.36 Segment"
   (Section 3.5).

3.36.  Server layer: 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 point-to-multipoint, or multipoint-to-multipoint services).

   In a client/server relationship (see [ITU-T_G.805]) [ITU-T_G.805]), the server layer server-layer
   network provides a (transport) service to the higher client layer client-layer
   network (usually the layer network under consideration).

3.37

3.37.  Server MEPs: 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 client-layer (MPLS-TP) layer
   network.  See also [RFC6371] section Section 3.5 of [RFC6371] and [ITU-T G.8113.1] clause
   6.5. Clause 6.5 of
   [ITU-T_G.8113.1].

   For example, a server MEP can be either:

   . one of the following:

   o  A termination point of a physical link (e.g. (e.g., IEEE 802.3), an SDH
     VC
      Virtual Circuit (VC), or OTH ODU OTN Optical Data Unit (ODU) for the MPLS-TP MPLS-
      TP Section layer network, defined in
     [RFC6371] section 3.1.;
   . [RFC6371], Section 4.1;

   o  An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [RFC6371]
     section 3.2.;

   . [RFC6371],
      Section 4.2;

   o  An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [RFC6371] section
     3.4.;

   . [RFC6371],
      Section 4.3; or

   o  An MPLS-TP TCM MEP for higher-level TCMs, defined in [RFC6371]
     sections 3.3. and 3.5. [RFC6371],
      Section 3.2.

   The server MEP can run appropriate OAM functions for fault
   detection, detection
   and notifies a fault indication to the MPLS-TP layer network.

3.38

3.38.  Signaling Communication Channel (SCC): (SCC)

   A Signaling Communication Channel is a Communication Channel
   dedicated for control plane to control-plane communications.  The SCC may be used for GMPLS/ASON
   GMPLS / Automatically Switched Optical Network (ASON) signaling
   and/or other control
   plane control-plane messages (e.g., routing messages).

3.39

3.39.  Signaling Communication Network (SCN): (SCN)

   A DCN supporting control plane control-plane communication is referred to as a
   Signaling Communication Network (SCN).

3.40 Span:

3.40.  Span

   A span is synonymous with a link.

3.41 Sublayer:

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 higher-layer (client)
   network.

3.42

3.42.  Transport Entity: Entity

   A "Transport Entity" transport entity is a node, link, transport path segment,
   concatenated transport path segment, or entire transport path.

3.42.1

3.42.1.  Working Entity: Entity

   A "Working Entity" working entity is a transport entity that carries traffic during
   normal network operation.

3.42.2

3.42.2.  Protection Entity: Entity

   A "Protection Entity" 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

3.42.3.  Recovery entity: Entity

   A "Recovery Entity" recovery entity is a transport entity that is used to recover and
   transport traffic when the working entity fails.

3.43

3.43.  Transmission media layer: Media Layer

   A transmission media layer is a layer network, consisting of a section layer
   section-layer network and a
   physical layer 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

3.44.  Transport Network: Network

   A Transport Network provides transmission of traffic between attached
   client devices by establishing and maintaining point-to-
   point 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 Operations, Administration and Maintenance (OAM)
   OAM functions.

3.45

3.45.  Transport path: Path

   A transport path is a network connection as defined in [ITU-T_G.805].
   In an MPLS-TP
   environment environment, a transport path corresponds to an LSP or
   a PW.

3.46 Transport path layer:

3.46.  Transport-Path Layer

   A transport-path layer is a (sub)layer network that provides point-to-point point-
   to-point or point-to-
   multipoint point-to-multipoint transport paths.  It provides OAM
   that is independent of the clients that it is transporting.

3.47 Transport service layer:

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 point-to-multipoint, or multipoint-to-multipoint
   services).

3.48 Unidirectional path:

   A

3.48.  Unidirectional Path

   A unidirectional path is a path that supports traffic flow in only
   one direction.

4

4.  Guidance on the Application of this 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

5.  Management Considerations

   The MPLS-TP

   Networks based network requires on MPLS-TP require management.  The MPLS-TP
   specifications described in [RFC5654], [RFC5860], [RFC5921],
   [RFC5951], [RFC6371], [RFC6372], [ITU-T G.8110.1] [ITU-T_G.8110.1], and [ITU-T
   G.7710], [ITU-T_G.7710]
   include considerable efforts to provide operator control and monitoring,
   monitoring as well as Operations, Administration and
   Maintenance (OAM) OAM functionality.

   These concepts are, however, out of the scope of this document.

6

6.  Security Considerations

   Security is a significant requirement of MPLS-TP.  See [RFC6941] for
   more
   information [RFC6941]. information.

   However, this informational document is intended only to provide a
   lexicography, and the security concerns are, therefore, out of
   scope.

7 IANA Considerations

   There are no IANA actions resulting from the
   scope of this document.

8

7.  Acknowledgments

   The authors would like to thank all members of the teams (the Joint
   Working Team, the MPLS Interoperability Design Team in IETF 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 draft.

1.1 Contributing Authors 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, Stuart Stewart Bryant, Dan Frost, Matthew Bocci, Vincenzo Sestito,
   Martin Vigoureux, and Yaacov Weingarten

9 Weingarten.

9.  References

9.1

9.1.  Normative References

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, R., "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC5654]  Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., et al., 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, M., Ed.,
              "Requirements for OAM Operations, Administration, and
              Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
              May 2010.

   [RFC5921]  Bocci, M., Ed., Bryant, S., Ed., Frost, D, et al., D., Ed., Levrau,
              L., and L. Berger, "A Framework for MPLS in Transport
              Networks", RFC 5921, July 2010.

   [RFC5951]  Lam, K., Gray, E., Mansfield, S., and E. Gray, "Network Management
              Requirements for MPLS-based Transport Networks", RFC 5951,
              September 2010.

   [RFC6371]  Busi, I., Ed., and D. Allan, D., Ed., "Operations,
              Administration, and Maintenance Framework for MPLS-Based
              Transport Networks", RFC 6371, September 2011.

   [RFC6372]  Sprecher, N., Ed., and A. Farrel, A., Ed., "MPLS Transport
              Profile (MPLS-
             TP) (MPLS-TP) Survivability Framework", RFC 6372,
              September 2011.

   For information on the availability of the following documents,
   please see http://www.itu.int

   [ITU-T_G.805]
              ITU-T Recommendation G.805 (03/2000), G.805, "Generic functional
              architecture of transport networks." networks", March 2000,
              <http://www.itu.int/rec/T-REC/>.

   [ITU-T_G.806]
              ITU-T Recommendation G.806 (03/2006), G.806, "Characteristics of transport
              equipment - Description methodology and generic functionality."
              functionality", March 2006, <http://www.itu.int/rec/T-
              REC/>.

   [ITU-T_G.872]
              ITU-T Recommendation G.872 (11/2001), G.872, "Architecture of optical
              transport networks."

   [ITU-T G.7710] networks", November 2001,
              <http://www.itu.int/rec/T-REC/>.

   [ITU-T_G.7710]
              ITU-T Recommendation G.7710 (07/2007), G.7710, "Common equipment management
              function requirements." requirements", July 2007,
              <http://www.itu.int/rec/T-REC/>.

   [ITU-T_G.8101]
              ITU-T Recommendation G.8101/Y.1355 (09/2013), G.8101/Y.1355, "Terms and definitions
              for MPLS Transport Profile."

   [ITU-T G.8110.1] Profile", September 2013,
              <http://www.itu.int/rec/T-REC/>.

   [ITU-T_G.8110.1]
              ITU-T Recommendation G.8110.1/Y.1370.1 (12/2011), G.8110.1/Y.1370.1, "Architecture of
              the Multi-Protocol Label Switching transport profile layer network."

   [ITU-T G.8113.1]
              network", December 2011, <http://www.itu.int/rec/T-REC/>.

   [ITU-T_G.8113.1]
              ITU-T Recommendation G.8113.1/Y.1372.1 (11/2012), G.8113.1/Y.1372.1, "Operations, Administration
              administration and Maintenance maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)."

   [ITU-T G.8113.2]
              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 (11/2012), G.8113.2/Y.1372.2, "Operations,
              administration and maintenance mechanisms for MPLS-TP
              networks using the tools defined for
                  MPLS."

    [ITU-T Y.2611] MPLS", November 2012,
              <http://www.itu.int/rec/T-REC/>.

   [ITU-T_Y.2611]
              ITU-T Recommendation Y.2611 (12/2006), Y.2611, "High-level architecture of
              future packet-based networks."

9.2 networks", December 2006,
              <http://www.itu.int/rec/T-REC/>.

9.2.  Informative References

   [RFC4397] I.  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] L.  Fang, B. L., Ed., Niven-Jenkins, S. 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) (editor)
   Huawei Technologies Co., Ltd.
   Email:

   EMail: Huub.van.Helvoort@huawei.com

   Loa Andersson (Editor) (editor)
   Huawei Technologies Co., Ltd.
   Email:

   EMail: loa@mail01.huawei.com

   Nurit Sprecher (Editor) (editor)
   Nokia Solutions and Networks
   Email:

   EMail: nurit.sprecher@nsn.com