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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/