Internet DRAFT - draft-ietf-mpls-tp-rosetta-stone

draft-ietf-mpls-tp-rosetta-stone



MPLS Working Group                                H. van Helvoort (Ed)
Internet Draft                                     Huawei Technologies
Intended status: Informational
Expires: April 2014                                  L. Andersson (Ed)
                                                   Huawei Technologies

                                                      N. Sprecher (Ed)
                                          Nokia Solutions and Networks

                                                      October 20, 2013


        A Thesaurus for the Terminology used in Multiprotocol Label
       Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's
                    Transport Network Recommendations.
                    draft-ietf-mpls-tp-rosetta-stone-13


                          Status of this Memo

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

   Internet-Drafts are working documents 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 of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 20, 2014.

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

van Helvoort et al.    Expires April 20, 2014                 [Page 1]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


   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.

Abstract

   MPLS Transport Profile (MPLS-TP) is based on a profile of the MPLS
   and Pseudowire (PW) procedures as specified in the MPLS-TE, PW and
   Multi-Segment Pseudowire (MS-PW) architectures developed by the
   Internet Engineering Task Force (IETF).  The International
   Telecommunications Union Telecommunications 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 complete interpretations
   of MPLS-TP concepts.  This document simply allows the MPLS-TP terms
   to be applied within the Transport Network context.

Table of Contents

   1 Introduction  4
      1.1  Contributing Authors 4
      1.2  Abbreviations 4
   2 Terminology 6
      2.1  MPLS-TP Terminology Sources  6
      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: 7
      3.3  Client layer network:  7
      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):  8
      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:  9


van Helvoort et al.    Expires April 20, 2014                 [Page 2]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


      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): 12
         3.23.2  Sub-Path Maintenance Element (SPME):  12
         3.23.3  Tandem Connection:  12
      3.24 MPLS Section: 13
      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  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 System (OS): 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:  17
         3.42.3  Recovery entity: 17
      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:  18
      3.48 Unidirectional path: 18
   4 Guidance on the Application of this Thesaurus  18
   5 Management Considerations 18


van Helvoort et al.    Expires April 20, 2014                 [Page 3]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


   6 Security Considerations 18
   7 IANA Considerations 19
   8 Acknowledgments  19
   9 References 19
      9.1  Normative References 19
      9.2  Informative References 20


1 Introduction

   Multiprotocol Label Switching - Transport Profile (MPLS-TP) has been
   developed by the IETF to facilitate the Operation, Administration
   and Management 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 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 Contributing Authors

   Italo Busi, Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven
   Levrau, Dinesh Mohan, Stuart Bryant, Dan Frost, Matthew Bocci,
   Vincenzo Sestito, Vigoureux, Yaacov Weingarten

1.2 Abbreviations

   CE   Customer Edge

   DCC  Data Communication Channel

   DCN  Data Communication Network

   ECC  Embedded Communication Channel

   EMF  Equipment Management Function


van Helvoort et al.    Expires April 20, 2014                 [Page 4]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


   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

   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


van Helvoort et al.    Expires April 20, 2014                 [Page 5]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


   T-PE PW Terminating Provider Edge

   TCM  Tandem Connection Monitoring



2 Terminology

2.1 MPLS-TP Terminology Sources

   MPLS-TP terminology is principally defined in [RFC3031].  Other
   documents provide further key definitions including [RFC4397].

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

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



van Helvoort et al.    Expires April 20, 2014                 [Page 6]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


   independently.  As a consequence, they may or may not follow the
   same route (links and nodes) across the network.

3.2 Bidirectional path:

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

3.4 Communication Channel:

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

3.5 Concatenated Segment:

   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
   comprises a set of segments and their interconnecting nodes in
   sequence.  See also "Segment".

3.6 Control Plane:

   Within the scope of [RFC5654], the control plane performs transport
   path control functions.  Through signalling, 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 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 and protected as a single entity.  A
   transport network path is typically co-routed.




van Helvoort et al.    Expires April 20, 2014                 [Page 7]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


3.8 Data Communication Network (DCN):

   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 other operations communications (e.g., order-
   wire/voice communications, software downloads, etc.).

3.9 Defect:

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

   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 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 the ability of an item
   to perform a required transport function to be terminated. The item


van Helvoort et al.    Expires April 20, 2014                 [Page 8]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


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

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


van Helvoort et al.    Expires April 20, 2014                 [Page 9]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


   and managed. See also [RFC6371] section 3.1 and [ITU-T G.8113.1],
   [ITU-T G.8113.2] clause 6.1.

   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 a 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 a ME for a 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 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 (ME). See also [RFC6371] section 3.1 and
   [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.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 or sink MEP, or to an
   intermediate MIP that is part of the ME. See also [RFC6371] section
   3.3 and [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.3.





van Helvoort et al.    Expires April 20, 2014                [Page 10]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


   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 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 packets). A MEP of an MPLS-TP network
   transport path is coincident with transport path termination and
   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 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 [RFC6371] section
   3.4 and [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.4.

3.21 Management Communication Channel (MCC):

   A Communication Channel dedicated for management plane
   communications.

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,


van Helvoort et al.    Expires April 20, 2014                [Page 11]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


   - 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).
   Path segment tunnels can also be employed to meet the requirement to
   provide Tandem Connection Monitoring, see Tandem Connection.

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 a 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 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 [RFC6371] section 3.2 and
   [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.2.1.



van Helvoort et al.    Expires April 20, 2014                [Page 12]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


3.24 MPLS Section:

   A network segment between two LSRs that are immediately adjacent at
   the MPLS layer.

3.25 MPLS Transport Profile (MPLS-TP):

   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.

3.27 MPLS-TP network:

   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


van Helvoort et al.    Expires April 20, 2014                [Page 13]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


   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 MSPL-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 instrument one direction of a MEG (or
   possibly both in the special case of data plane loopback).

3.31 Operations Support System (OSS):

   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.

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-


van Helvoort et al.    Expires April 20, 2014                [Page 14]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


   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 which
   provide for the transfer of information between locations in path
   layer networks.

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

3.35 Segment:

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

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 (MPLS-TP) layer
   network. See also [RFC6371] section 3.5 and [ITU-T G.8113.1] clause
   6.5.

   For example, a server MEP can be either:

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




van Helvoort et al.    Expires April 20, 2014                [Page 15]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


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

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

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

   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 Communication Channel dedicated for control plane communications.
   The SCC may be used for GMPLS/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.




van Helvoort et al.    Expires April 20, 2014                [Page 16]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


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 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 Operations, Administration and Maintenance (OAM)
   functions.

3.45 Transport path:

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







van Helvoort et al.    Expires April 20, 2014                [Page 17]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


3.47 Transport service layer:

   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

   The MPLS-TP based network requires 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 Operations, Administration and
   Maintenance (OAM) functionality.

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



6 Security Considerations

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

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




van Helvoort et al.    Expires April 20, 2014                [Page 18]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


7 IANA Considerations

   There are no IANA actions resulting from this document.



8 Acknowledgments

   The authors would like to thank all members of the teams (the Joint
   Working Team, the MPLS Interoperability Design Team in IETF and the
   MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and
   specification of MPLS Transport Profile. We would in particular like
   to acknowledge the contributions by Tom Petch to improve the quality
   of this draft.



9 References

9.1 Normative References

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

   [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., et al.,
             "Requirements of an MPLS Transport Profile", September
             2009.

   [RFC5860] Vigoureux, M., Ward, D., Betts, M., "Requirements for OAM
             in MPLS Transport Networks", May 2010.

   [RFC5921] Bocci, M., Bryant, S., Frost, D, et al., "A Framework for
             MPLS in Transport Networks", July 2010.

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

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

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





van Helvoort et al.    Expires April 20, 2014                [Page 19]

Internet-Draft          MPLS-TP Rosetta Stone             October 2013


   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), "Generic
                  functional architecture of transport networks."

   [ITU-T_G.806] ITU-T Recommendation G.806 (03/2006), "Characteristics
                  of transport equipment - Description methodology and
                  generic functionality."

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

   [ITU-T G.7710] ITU-T Recommendation G.7710 (07/2007), "Common
                  equipment management function requirements."

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

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

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

   [ITU-T G.8113.2] ITU-T Recommendation G.8113.2/Y.1372.2 (11/2012),
                  "Operations, administration and maintenance mechanisms
                  for MPLS-TP networks using the tools defined for
                  MPLS."

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

9.2 Informative References

    [RFC4397] I. Bryskin, 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", February 2006.

   [RFC6941] L. Fang, B. Niven-Jenkins, S. Mansfield, R. Graveman,
             "MPLS Transport Profile (MPLS-TP) Security Framework",
             April 2013.



van Helvoort et al.    Expires April 20, 2014                [Page 20]

Internet-Draft          MPLS-TP Rosetta Stone             October 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.    Expires April 20, 2014                [Page 21]