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

                                                       N. Sprecher (Ed)
                                                 Nokia Siemens Networks

                                                          June 19,

                                                       October 25, 2009

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

                          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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December April 1, 2009. 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (
   Please review these documents carefully, as they describe your
   rights and restrictions with respect to this document.

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort


   MPLS-TP is based on a profile of the MPLS and PW procedures as
   specified in the MPLS-TE and (MS-)PW architectures developed by the
   IETF.  The 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

   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   3
      1.1.  Contributing Authors 4
      1.2.  Abbreviations  4
      SCC   Signaling Communication Channel  5
   2. Terminology   4 5
      2.1.  MPLS-TP Terminology Sources   4   5
      2.2.  ITU-T Transport Network Terminology Sources  4  5
      2.3.  Common Terminology Sources 5
   3. Thesaurus   5
      3.1.  Associated bidirectional path:   5   6
      3.2.  Bidirectional path:  5  6
      3.3.  Client layer network:   6
      3.4.  Concatenated Segment:   5
      3.4.   6
      3.5.  Control Plane: 6
      3.6.  Co-routed bidirectional path:    5
      3.5. 6
      3.7.  Domain:  5
      3.6.  7
      3.8.  Layer network: 6
      3.7. 7
      3.9.  Link:    6
      3.8. 7
      3.10. MPLS-TP Logical Ring:  6
      3.9.  Path:    6
      3.10.   7
      3.11. MPLS-TP Physical Ring:   6
      3.11.  8
      3.12. MPLS-TP Ring Topology:   6
      3.12.  Section:   7  8
      3.13.  Segment:   7 Path: 8
      3.14.  Service layer:   7 Section Layer Network:  8
      3.15.  Span:   7 Segment: 8
      3.16.  Sublayer:  7 Server layer:  9
      3.17. Span: 9
      3.18. Sublayer:   9
      3.19. Tandem Connection:  7
      3.18.   9
      3.20. Transport path:  8
      3.19.   10
      3.21. Transport path layer:  8

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort

      3.20.   10
      3.22. Transport service layer:  8
      3.21.   10
      3.23. Transmission media layer:    8
      3.22.  10
      3.24. Unidirectional path:   8
      3.23. 10
      3.25. Failure:   8
      3.24. 10
      3.26. Fault:  8
      3.25.   10
      3.27. Defect: 9
      3.26.  11
      3.28. MPLS Transport Profile (MPLS-TP):  9
      3.27.   11
      3.29. MPLS Section: 9
      3.28.  11
      3.30. MPLS-TP NE:   9
      3.29. 11
      3.31. MPLS-TP network:    9
      3.30.  11
      3.32. Equipment Management Function (EMF):  9
      3.31.   11
      3.33. Data Communication Network (DCN):  9
      3.32.   11
      3.34. Communication Channel (CC):  10
      3.33.   11
      3.35. Embedded Communication Channel (ECC):    10
      3.34.  12
      3.36. Management Communication Channel (MCC):  10
      3.35.   12
      3.37. Management Communication Network (MCN):  10
      3.36.   12
      3.38. Signaling Communication Channel (SCC):   10
      3.37. 12
      3.39. Signaling Communication Network (SCN):   10
      3.38. 12
      3.40. Operations System (OS):   10
      3.39. 12
      3.41. Maintenance Entity  11
      3.40.   13
      3.42. Maintenance End Points (MEPs)   11
      3.41. 13
      3.43. Maintenance Intermediate Points (MIPs)   12
      3.42. 14
      3.44. Server MEPs   12 14
   4. Guidance on the Application of this Thesaurus  16   18
   5. Management Considerations 16  18
   6. Security Considerations   16 19
   7. IANA Considerations 16  19
   8. Acknowledgments  17   19
   9. References 17  19
      9.1.  Normative References 17 19
      9.2.  Informative References  17  20
   Authors' Addresses  18   20
   Contributing Authors' Addresses 18  21

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

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort

   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 ITU-T
   Transport Network terminology within the context of the MPLS-TP.
   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, Nurit Sprecher, Huub van
   Helvoort, Martin Vigoureux, Yaacov Weingarten

1.2.  Abbreviations

   CC    Communications Channel

   DCN   Data Communication Network

   ECC   Embedded Communication Channel

   EMF   Equipment Management Function

   MCC   Management Communication Channel

   MCN   Management Communication Network

   ME    Maintenance Entity

   MEG   ME Group

   MEP   MEG End Point

   MIP   MEG Intermediate Point

   MPLS  Multiprotocol Label Switching

   MPLS-TP  MPLS Transport Profile
   NE    Network Element

   OAM   Operations, Administration and Maintenance

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort

   O&M   OAM and Management

   SCC   Signaling Communication Channel

   SCN   Signaling Communication Network

2.    Terminology

   Throughout this document, angle brackets ("<" and ">") are used to
   indicate that the term is used by both IETF and ITU-T but has a
   different definition. The bracketed term is the IETF term.

   [editor: check all terms used that this applies to, TBD]

2.1.  MPLS-TP Terminology Sources

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

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

3.    Thesaurus

   From: draft-ietf-mpls-tp-requirements-04 [1]

   [editor: from [RFC5654] mpls-tp-requirements]

3.1.  Associated bidirectional path:

   A path that supports traffic flow in both directions but which that is
   constructed from a pair of unidirectional paths (one for each
   direction) which that are associated with one another at the path's

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort
   ingress/egress points.  The forward and backward directions are
   setup, monitored, and protected independently.  As a consequence,
   they may or may not follow the same route (links and nodes) across
   the network.

3.2.  Bidirectional path:

   A 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.  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 multi-segment
   PW that comprises a set of segments and their interconnecting nodes
   in sequence.

3.4.  See also "Segment".

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

3.6.  Co-routed bidirectional path:

   A bidirectional path where the forward and backward directions follow the same
   route (links and nodes) across its layer the network.

3.5.  Both directions are
   setup, monitored and protected as a single entity.  A transport
   network path is typically co-routed.

3.7.  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.8.  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 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 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(s) encapsulation associated with the
   logical layers (e.g. (e.g., the label stack), and thus could be modeled as
   multiple logical elements.  A layer network may consist of zero one or
   more sublayers. For additional explanation of how layer networks
   relate to the OSI concept of layering layering, see Appendix I of [ITU-T

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort


3.9.  Link:

   A physical or logical connection between a pair of 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.10.    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.9.  Path:

   See Transport path.


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

   In an MPLS-TP ring topology topology, each LSR is connected to exactly two
   other LSRs, each via a single point-to-point bidirectional MPLS-TP
   capable data link.  A ring may also be constructed from only two LSRs
   where there are also exactly two bidirectional 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 CEs) may be connected directly to an LSR in
   the ring.

3.12.    Section:

3.13.    Path:

   See Transport path.

3.14.    Section Layer Network:

   A section layer is a server layer (which may be MPLS-TP or a
   different technology) which that provides for encapsulation and OAM the transfer of a MPLS-TP
   transport path 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] [ITU-
   T_G.805] defines the section layer as one of the two layer networks
   in a
   transmission media transmission-media layer network.  The other layer network is
   physical media physical-media layer network.

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort

   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.15.    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. (i.e., that connects a pair of adjacent

3.14.    Service
   {Switching|Terminating} Provider Edges).  See also "Concatenated

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


   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.17.    Span:

   A span is synonymous with a link.


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


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

3.18. transport path.

   [editor: this is not in [RFC5654] BUT added for completeness]

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

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

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort


3.22.    Transport path layer:

   A layer (sub)layer network which that provides point-to-point or point-to-multipoint
   transport paths which are used to carry a higher (client) layer
   network or aggregates of higher (client) layer networks, for example
   the point-to-
   multipoint transport service layer. paths.  It provides for independent OAM (of
   the client OAM) in the transport that is independent of
   the clients.

3.20. clients that it is transporting.

3.23.    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.24.    Transmission media layer:

   A layer network, consisting of a section layer network which 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 network-transport path or
   network service network-service layers on
   various physical media.


3.25.    Unidirectional path:

   A path that supports traffic flow in only one direction.


   [editor: from: draft-ietf-mpls-tp-oam-requirements-00 [2]

3.23. draft-ietf-mpls-tp-oam-requirements [1]]

3.26.    Failure:

   [editor: this is not in [2] [1] BUT added for completeness]

   The fault cause persisted long enough to consider the ability of an
   item to perform a required function to be terminated. The item may
   be considered as failed; a fault has now been detected.  See also


3.27.    Fault:

   The inability of a 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.28.    Defect:

   The situation for which density of anomalies has reached a level
   where the ability to perform a required function has been

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort
   interrupted. Defects are used as input for PM, the control of
   consequent actions, and the determination of fault cause. See also


3.29.    MPLS Transport Profile (MPLS-TP):

   The set of MPLS functions used to support packet transport services
   and network operations.


3.30.    MPLS Section:

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


   From: draft-ietf-mpls-tp-framework-00 [3]


   From: draft-gray-mpls-tp-nm-req-03 [4]


   [editor: from: draft-ietf-mpls-tp-framework [2]]

   [editor: from: draft-gray-mpls-tp-nm-req [3]]

3.31.    MPLS-TP NE:

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


3.32.    MPLS-TP network:

   A network in which MPLS-TP NEs are deployed


3.33.    Equipment Management Function (EMF):

   The management functions within an NE. See [ITU-T G.7710].


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


3.35.    Communication Channel (CC):

   A logical channel between network elements (NEs) that can be used -
   e.g. - for management plane application or control plane

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort
   applications. The physical channel supporting the CC is technology
   specific.  See [4] [3] APPENDIX A


3.36.    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
   physical channels supporting the ECC is a DCC channel within SDH.


3.37.    Management Communication Channel (MCC):

   A CC dedicated for management plane communications.


3.38.    Management Communication Network (MCN):

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


3.39.    Signaling Communication Channel (SCC):

   A CC 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.40.    Signaling Communication Network (SCN):

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


3.41.    Operations System (OS):

   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.



   [editor: from: draft-busi-mpls-tp-oam-framework-00 [5] [4]]

   [editor: MPLS Section: already defined in 3.30]

   [editor: see 3.27] OAM flow: to be added in a future revision of this document. document.]

   [editor: Tandem Connection: [editor: see 3.17]

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort

3.39. already defined in 3.19]

3.42.    Maintenance Entity

   A Maintenance Entity can be viewed as the association of two (or
   more) Maintenance End Points (MEPs), that should be configured and
   managed in order to bound the OAM responsibilities of an OAM flow
   [editor: definition?] across a network or sub-network, i.e. a
   transport path or segment, in the specific layer network that is
   being monitored and managed.

   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.

   [editor: should the following be included?]

   Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity
   (defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can
   be MIPs. In the case of Tandem Connection Maintenance Entity
   (defined below), LSRs and S-PEs can be either MEPs or MIPs.

   The following properties apply to all MPLS-TP MEs:

   o  OAM entities can be nested but not overlapped.

   o  Each OAM flow is associated to a unique Maintenance Entity.

   o  OAM packets are subject to the same forwarding treatment as the
      data traffic, but they are distinct from the data traffic.


3.43.    Maintenance End Points (MEPs)

   Maintenance 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 MEP may initiate an OAM packet to be transferred to its
   corresponding MEP, or to an intermediate MIP that is part of the ME.

   A 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 to a MEP source are tunnelled via label
   stacking and are not processed within the ME as they belong either
   to the client network layers or to an higher 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

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort
   transport path is coincident with transport path termination and
   monitors its connectivity (e.g. count packets).

   MPLS-TP MEP notifies a fault indication to the MPLS-TP client layer


3.44.    Maintenance Intermediate Points (MIPs)

   A Maintenance 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.


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

   For example, a server MEP can be either:

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

  . An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [5] section

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

  . An MPLS-TP TCM MEP for higher-level TCMs, defined in [5] 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

   [editor: the following are definitions from G.8101 which should be
   defined only if they will cause misunderstanding. It is not usefull
   to define them if the definition is the same in IETF and ITU-T, TBD]

===== [ITU-T_G.8101] =====

   3.1 access point

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort
   3.2 adapted information

   3.3 characteristic information

   3.4 client/server relationship

   3.5 connection

   3.6 connection point

   3.9 forward direction

   3.12 link connection

   3.13 matrix

   3.14 network

   3.15 network connection

   3.16 network operator

   3.17 port

   3.18 reference point

   3.19 service provider

   3.20 subnetwork

   3.21 subnetwork connection

   3.22 termination connection point

   3.23 trail

   3.24 trail termination

   3.25 trail termination point

   3.26 transport

   3.27 transport entity

   3.28 transport processing function

   3.29 unidirectional connection

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort
   3.30 unidirectional trail

   3.31 Z layer

   Transport MPLS (T-MPLS) Recommendations uses the following terms
   defined in ITU-T Rec. G.809:

   3.33 access point

   3.34 adaptation

   3.35 adapted information

   3.36 characteristic information

   3.37 client/server relationship

   3.50 network

   3.52 port

   3.53 reference point

   3.56 traffic unit

   3.57 transport

   3.58 transport entity

   Transport MPLS (T-MPLS) Recommendations uses the following term
   defined in ITU-T Rec. G.8010/Y.1306:

   3.59 point-to-point Ethernet connection

   Transport MPLS (T-MPLS) Recommendations uses the following terms
   defined in [ITU-T_Y.1711]:

   3.60 backward direction

   3.62 client/server (relationship between layer networks)

   3.63 failure

   3.64 forward direction

   3.65 user-plane

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort
   Transport MPLS (T-MPLS) Recommendations uses the following terms
   defined in [ITU-T_Y.1720]:

   3.66 1+1 protection

   3.67 1:1 protection

   3.68 bidirectional protection switching

   3.69 bridge

   3.71 extra traffic

   3.72 failure

   3.73 forced switch for working LSP

   3.74 hold-off time

   3.75 manual switch

   3.76 MPLS protection domain

   3.77 non-revertive protection switching

   3.78 no request

   3.79 packet 1+1 protection

   3.80 path switch LSR

   3.81 path merge LSR

   3.82 protection LSP

   3.83 protection switching

   3.84 rerouting

   3.85 revertive protection switching

   3.86 selector

   3.87 shared mesh protection

   3.88 Shared Risk Group (SRG)

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort
   3.89 sink of the protection domain

   3.90 source of the protection domain

   3.91 unidirectional protection switching

   3.92 wait to restore

   3.93 wait to restore timer

   3.94 working LSP

   Transport MPLS (T-MPLS) Recommendations uses the following terms
   defined in [ITU-T_Y.1731]:

   3.95 in-service OAM

===== end of [ITU-T_G.8101] =====

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.

   This lexicography should not be used in order to obtain or derive
   definitive definitions of GMPLS terms.  To obtain definitions of
   GMPLS terms that are applicable across all GMPLS architectural
   models, the reader should refer to the RFCs listed in the references
   sections of this document.  [RFC3945] provides an overview of the
   GMPLS architecture and should be read first.

5.    Management Considerations

   The MPLS-TP based network requires management. The MPLS-TP
   specifications include considerable efforts to provide operator
   control and monitoring, as well as Operations and Management (OAM)

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

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort

6.    Security Considerations

   Security is also a significant requirement of MPLS-TP.

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

7.    IANA Considerations

   To be incorporated in a future revision of 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
   T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
   specification of MPLS Transport Profile.

9.    References

9.1.  Normative References

   [1]   B. Niven-Jenkins, et al., "MPLS-TP Requirements", draft-ietf-
         mpls-mpls-tp-requirements, november 2008

   [2]   Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
         MPLS Transport Networks", draft-vigoureux-mpls-tp-oam-
         requirements, november 2008

   [3] draft-ietf-mpls-tp-oam-requirements-
         03, august 2009

   [2]   Bocci, M., Bryant, S., Levrau, L., "A Framework for MPLS in
         Networks", draft-ietf-mpls-tp-framework, november 2008

   [4] Networks'', draft-ietf-mpls-tp-framework-06, october

   [3]   Gray, E., Mansfield, S., et al., "MPLS ''MPLS TP Network Management
         Requirements", draft-gray-mpls-tp-nm-req, november 2008

         Requirements'', draft-ietf-mpls-tp-nm-req-06, october 2009

   [4]   Busi, I., Niven-Jenkins, B., et al., "MPLS-TP ''MPLS-TP OAM Framework
         and Overview", draft-busi-mpls-tp-oam-framework, november 2008 Overview'', draft-ietf-mpls-tp-oam-framework-01, july 2009

   [RFC5654] B. Niven-Jenkins, et al., ''Requirements of an MPLS
             Transport Profile'', September 2009

   [RFC3031] E. Rosen, etal., ''Requirements of an MPLS Transport
             Profile'', january 2001


Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort 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

9.2.  Informative References

   For information on the availability of the following documents,
   please see

   [ITU-T_G.8101] ITU-T Recommendation G.8101/Y.1355 (12/2006), Terms
                  and definitions for transport MPLS.

   [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_Y.1711] ITU-T Recommendation Y.1711 (10/2005) Operation &
                  Maintenance mechanism for MPLS networks.

   [ITU-T_Y.1720] ITU-T Recommendation Y.1720 (02/2008), Protection
                  switching for MPLS networks.

   [ITU-T_Y.1731] ITU-T Recommendation Y.1731 (02/2008), OAM functions
                  and mechanisms for Ethernet based networks.

   [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 Y.2611] ITU-T Recommendation Y.2611 (12/2006), High-level
                  architecture of future packet-based networks

Authors' Addresses

   Huub van Helvoort van_Helvoort (Editor)
   Huawei Technologies Co., Ltd.
   Loa Andersson (Editor)

Internet-Draft          MPLS-TP Rosetta Stone         Huub van Helvoort

   Nurit Sprecher (Editor)
   Nokia Siemens Networks

Contributing Authors' Addresses