draft-ietf-mpls-tp-rosetta-stone-00.txt   draft-ietf-mpls-tp-rosetta-stone-01.txt 
MPLS Working Group H. van Helvoort (Ed) MPLS Working Group H. van_Helvoort (Ed)
Internet Draft Huawei Technologies Internet Draft Huawei Technologies
Intended status: Informational Intended status: Informational
Expires: December 2009 L. Andersson (Ed) Expires: April 2010 L. Andersson (Ed)
Redback Redback
N. Sprecher (Ed) N. Sprecher (Ed)
Nokia Siemens Networks Nokia Siemens Networks
June 19, 2009 October 25, 2009
A Thesaurus for the Terminology used in Multiprotocol Label A Thesaurus for the Terminology used in Multiprotocol Label
Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's
Transport Network Recommendations. Transport Network Recommendations.
draft-ietf-mpls-tp-rosetta-stone-00 draft-ietf-mpls-tp-rosetta-stone-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 1, 2009. This Internet-Draft will expire on April 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your Please review these documents carefully, as they describe your
rights and restrictions with respect to this document. rights and restrictions with respect to this document.
Internet-Draft MPLS-TP Rosetta Stone Huub van Helvoort
Abstract Abstract
MPLS-TP is based on a profile of the MPLS and PW procedures as 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 specified in the MPLS-TE and (MS-)PW architectures developed by the
IETF. The ITU-T has specified a Transport Network architecture. IETF. The ITU-T has specified a Transport Network architecture.
This document provides a thesaurus for the interpretation of MPLS-TP This document provides a thesaurus for the interpretation of MPLS-TP
terminology within the context of the ITU-T Transport Network terminology within the context of the ITU-T Transport Network
recommendations. recommendations.
It is important to note that MPLS-TP is applicable in a wider set of It is important to note that MPLS-TP is applicable in a wider set of
contexts than just Transport Networks. The definitions presented in contexts than just Transport Networks. The definitions presented in
this document do not provide exclusive nor complete interpretations this document do not provide exclusive nor complete interpretations
of MPLS-TP concepts. This document simply allows the MPLS-TP terms of MPLS-TP concepts. This document simply allows the MPLS-TP terms
to be applied within the Transport Network context. to be applied within the Transport Network context.
Table of Contents Table of Contents
1. Introduction 3 1. Introduction 3
1.1. Contributing Authors 4 1.1. Contributing Authors 4
1.2. Abbreviations 4 1.2. Abbreviations 4
2. Terminology 4 SCC Signaling Communication Channel 5
2.1. MPLS-TP Terminology Sources 4 2. Terminology 5
2.2. ITU-T Transport Network Terminology Sources 4 2.1. MPLS-TP Terminology Sources 5
2.2. ITU-T Transport Network Terminology Sources 5
2.3. Common Terminology Sources 5 2.3. Common Terminology Sources 5
3. Thesaurus 5 3. Thesaurus 5
3.1. Associated bidirectional path: 5 3.1. Associated bidirectional path: 6
3.2. Bidirectional path: 5 3.2. Bidirectional path: 6
3.3. Concatenated Segment: 5 3.3. Client layer network: 6
3.4. Co-routed bidirectional path: 5 3.4. Concatenated Segment: 6
3.5. Domain: 5 3.5. Control Plane: 6
3.6. Layer network: 6 3.6. Co-routed bidirectional path: 6
3.7. Link: 6 3.7. Domain: 7
3.8. Logical Ring: 6 3.8. Layer network: 7
3.9. Path: 6 3.9. Link: 7
3.10. Physical Ring: 6 3.10. MPLS-TP Logical Ring: 7
3.11. Ring Topology: 6 3.11. MPLS-TP Physical Ring: 8
3.12. Section: 7 3.12. MPLS-TP Ring Topology: 8
3.13. Segment: 7 3.13. Path: 8
3.14. Service layer: 7 3.14. Section Layer Network: 8
3.15. Span: 7 3.15. Segment: 8
3.16. Sublayer: 7 3.16. Server layer: 9
3.17. Tandem Connection: 7 3.17. Span: 9
3.18. Transport path: 8 3.18. Sublayer: 9
3.19. Transport path layer: 8 3.19. Tandem Connection: 9
3.20. Transport path: 10
Internet-Draft MPLS-TP Rosetta Stone Huub van Helvoort 3.21. Transport path layer: 10
3.22. Transport service layer: 10
3.20. Transport service layer: 8 3.23. Transmission media layer: 10
3.21. Transmission media layer: 8 3.24. Unidirectional path: 10
3.22. Unidirectional path: 8 3.25. Failure: 10
3.23. Failure: 8 3.26. Fault: 10
3.24. Fault: 8 3.27. Defect: 11
3.25. Defect: 9 3.28. MPLS Transport Profile (MPLS-TP): 11
3.26. MPLS Transport Profile (MPLS-TP): 9 3.29. MPLS Section: 11
3.27. MPLS Section: 9 3.30. MPLS-TP NE: 11
3.28. MPLS-TP NE: 9 3.31. MPLS-TP network: 11
3.29. MPLS-TP network: 9 3.32. Equipment Management Function (EMF): 11
3.30. Equipment Management Function (EMF): 9 3.33. Data Communication Network (DCN): 11
3.31. Data Communication Network (DCN): 9 3.34. Communication Channel (CC): 11
3.32. Communication Channel (CC): 10 3.35. Embedded Communication Channel (ECC): 12
3.33. Embedded Communication Channel (ECC): 10 3.36. Management Communication Channel (MCC): 12
3.34. Management Communication Channel (MCC): 10 3.37. Management Communication Network (MCN): 12
3.35. Management Communication Network (MCN): 10 3.38. Signaling Communication Channel (SCC): 12
3.36. Signaling Communication Channel (SCC): 10 3.39. Signaling Communication Network (SCN): 12
3.37. Signaling Communication Network (SCN): 10 3.40. Operations System (OS): 12
3.38. Operations System (OS): 10 3.41. Maintenance Entity 13
3.39. Maintenance Entity 11 3.42. Maintenance End Points (MEPs) 13
3.40. Maintenance End Points (MEPs) 11 3.43. Maintenance Intermediate Points (MIPs) 14
3.41. Maintenance Intermediate Points (MIPs) 12 3.44. Server MEPs 14
3.42. Server MEPs 12 4. Guidance on the Application of this Thesaurus 18
4. Guidance on the Application of this Thesaurus 16 5. Management Considerations 18
5. Management Considerations 16 6. Security Considerations 19
6. Security Considerations 16 7. IANA Considerations 19
7. IANA Considerations 16 8. Acknowledgments 19
8. Acknowledgments 17 9. References 19
9. References 17 9.1. Normative References 19
9.1. Normative References 17 9.2. Informative References 20
9.2. Informative References 17 Authors' Addresses 20
Authors' Addresses 18 Contributing Authors' Addresses 21
Contributing Authors' Addresses 18
1. Introduction 1. Introduction
Multiprotocol Label Switching - Transport Profile (MPLS-TP) has been Multiprotocol Label Switching - Transport Profile (MPLS-TP) has been
developed by the IETF to facilitate the Operation, Administration developed by the IETF to facilitate the Operation, Administration
and Management of Label Switched Paths (LSPs) in a Transport Network and Management of Label Switched Paths (LSPs) in a 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.
Internet-Draft MPLS-TP Rosetta Stone Huub van Helvoort
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 ITU-T This document provides a thesaurus for the interpretation of ITU-T
Transport Network terminology within the context of the MPLS-TP. Transport Network terminology within the context of the MPLS-TP.
This allows MPLS-TP documents to be generally understood by those This allows MPLS-TP documents to be generally understood by those
familiar with MPLS RFCs. The definitions presented in this document familiar with MPLS RFCs. The definitions presented in this document
do not provide exclusive or complete interpretations of the ITU-T do not provide exclusive or complete interpretations of the ITU-T
Transport Network concepts. Transport Network concepts.
1.1. Contributing Authors 1.1. Contributing Authors
Italo Busi, Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven Italo Busi, Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven
Levrau, Dinesh Mohan, Vincenzo Sestito, Nurit Sprecher, Huub van Levrau, Dinesh Mohan, Stuart Bryant, Dan Frost, Matthew Bocci,
Helvoort, Martin Vigoureux, Yaacov Weingarten Vincenzo Sestito, Vigoureux, Yaacov Weingarten
1.2. Abbreviations 1.2. Abbreviations
CC Communications Channel CC Communications Channel
DCN Data Communication Network DCN Data Communication Network
ECC Embedded Communication Channel ECC Embedded Communication Channel
EMF Equipment Management Function EMF Equipment Management Function
skipping to change at page 4, line 49 skipping to change at page 5, line 4
MEG ME Group MEG ME Group
MEP MEG End Point MEP MEG End Point
MIP MEG Intermediate Point MIP MEG Intermediate Point
MPLS Multiprotocol Label Switching MPLS Multiprotocol Label Switching
MPLS-TP MPLS Transport Profile MPLS-TP MPLS Transport Profile
NE Network Element NE Network Element
OAM Operations, Administration and Maintenance OAM Operations, Administration and Maintenance
Internet-Draft MPLS-TP Rosetta Stone Huub van Helvoort
O&M OAM and Management O&M OAM and Management
SCC Signaling Communication Channel SCC Signaling Communication Channel
SCN Signaling Communication Network SCN Signaling Communication Network
2. Terminology 2. Terminology
Throughout this document, angle brackets ("<" and ">") are used to Throughout this document, angle brackets ("<" and ">") are used to
indicate that the term is used by both IETF and ITU-T but has a indicate that the term is used by both IETF and ITU-T but has a
skipping to change at page 5, line 42 skipping to change at page 5, line 43
[ITU-T_G.8101] contains an overview of the Terms and Definitions for [ITU-T_G.8101] contains an overview of the Terms and Definitions for
transport MPLS. 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. requirements.
3. Thesaurus 3. Thesaurus
From: draft-ietf-mpls-tp-requirements-04 [1] [editor: from [RFC5654] mpls-tp-requirements]
3.1. Associated bidirectional path: 3.1. Associated bidirectional path:
A path that supports traffic flow in both directions but which is A path that supports traffic flow in both directions but that is
constructed from a pair of unidirectional paths (one for each constructed from a pair of unidirectional paths (one for each
direction) which are associated with one another at the path's direction) that are associated with one another at the path's
ingress/egress points. The forward and backward directions are
Internet-Draft MPLS-TP Rosetta Stone Huub van Helvoort setup, monitored, and protected independently. As a consequence,
they may or may not follow the same route (links and nodes) across
ingress/egress points. The forward and backward directions may or the network.
may not follow the same route (links and nodes) across the network.
3.2. Bidirectional path: 3.2. Bidirectional path:
A path that supports traffic flow in two opposite directions, i.e. A path that supports traffic flow in two opposite directions, i.e.
the forward and backward direction. the forward and backward direction.
3.3. Concatenated Segment: 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 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 concatenated segment is a contiguous part of an LSP or multi-segment
PW that comprises a set of segments and their interconnecting nodes PW that comprises a set of segments and their interconnecting nodes
in sequence. in sequence. See also "Segment".
3.4. Co-routed bidirectional path: 3.5. Control Plane:
A bidirectional path where the forward and backward directions Within the scope of [RFC5654], the control plane performs transport
follow the same route (links and nodes) across its layer network. 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.5. Domain: 3.6. Co-routed bidirectional path:
A path where the forward and backward directions follow the same
route (links and nodes) across the network. 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 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.6. Layer network: 3.8. 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 provides
for the transfer of client information and independent operation of for the transfer of client information and independent operation of
the client OAM. A Layer Network may be described in a service the client OAM. A layer network may be described in a service
context as follows: one layer network may provide a (transport) context as follows: one layer network may provide a (transport)
service to higher client layer network and may, in turn, be a client service to a higher client layer network and may, in turn, be a
to a lower layer network. A layer network is a logical construction client to a lower-layer network. A layer network is a logical
somewhat independent of arrangement or composition of physical construction somewhat independent of arrangement or composition of
network elements. A particular physical network element may physical network elements. A particular physical network element
topologically belong to more than one layer network, depending on may topologically belong to more than one layer network, depending
the actions it takes on the encapsulation(s) associated with the on the actions it takes on the encapsulation associated with the
logical layers (e.g. the label stack), and thus could be modeled as logical layers (e.g., the label stack), and thus could be modeled as
multiple logical elements. A layer network may consist of zero or multiple logical elements. A layer network may consist of one or
more sublayers. For additional explanation of how layer networks more sublayers. For additional explanation of how layer networks
relate to the OSI concept of layering see Appendix I of [ITU-T relate to the OSI concept of layering, see Appendix I of [ITU-T
Y.2611]. Y.2611].
Internet-Draft MPLS-TP Rosetta Stone Huub van Helvoort 3.9. Link:
3.7. Link:
A physical or logical connection between a pair of LSRs that are A physical or logical connection between a pair of LSRs that are
adjacent at the (sub)layer network under consideration. A link may 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 carry zero, one or more LSPs or PWs. A packet entering a link will
emerge with the same label stack entry 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.8. Logical Ring: 3.10. 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 data links (such as MPLS-TP LSP tunnels or MSPL-TP logical data links (such as MPLS-TP LSP tunnels or MSPL-TP
pseudowires) and physical data links that form a ring topology. pseudowires) and physical data links that form a ring topology.
3.9. Path: 3.11. MPLS-TP Physical Ring:
See Transport path.
3.10. 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.11. Ring Topology: 3.12. 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 data link. A ring may also be constructed from only two capable link. A ring may also be constructed from only two LSRs
LSRs where there are also exactly two bidirectional links. Rings where there are also exactly two links. Rings may be connected to
may be connected to other LSRs to form a larger network. Traffic other LSRs to form a larger network. Traffic originating or
originating or terminating outside the ring may be carried over the terminating outside the ring may be carried over the ring. Client
ring. Client network nodes (such as CEs) may be connected directly network nodes (such as CEs) may be connected directly to an LSR in
to an LSR in the ring. the ring.
3.12. Section: 3.13. Path:
A section is a server layer (which may be MPLS-TP or a different See Transport path.
technology) which provides for encapsulation and OAM of a MPLS-TP
transport path client layer. A section layer may provide for
aggregation of multiple MPLS-TP clients. Note that [ITU-T_G.805]
defines the section layer as one of the two layer networks in a
transmission media layer network. The other layer network is the
physical media layer network.
Internet-Draft MPLS-TP Rosetta Stone Huub van Helvoort 3.14. Section Layer Network:
A section layer is a server layer (which may be MPLS-TP or a
different technology) that provides for the transfer of the section-
layer client information between adjacent nodes in the transport-
path layer or transport-service layer. A section layer may provide
for aggregation of multiple MPLS-TP clients. Note that [ITU-
T_G.805] defines the section layer as one of the two layer networks
in a transmission-media layer network. The other layer network is
the physical-media layer network.
Section layer networks are concerned with all the functions which Section layer networks are concerned with all the functions which
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 fibres,
metallic wires or radio frequency channels which support a section metallic wires or radio frequency channels which support a section
layer network. layer network.
3.13. Segment: 3.15. Segment:
A link connection as defined in [ITU-T_G.805]. A segment is the 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 part of an LSP that traverses a single link or the part of a PW that
traverses a single link (i.e. that connects a pair of adjacent traverses a single link (i.e., that connects a pair of adjacent
{S|T}-PEs). {Switching|Terminating} Provider Edges). See also "Concatenated
Segment".
3.14. Service layer: 3.16. Server layer:
A layer network in which transport paths are used to carry a A layer network in which transport paths are used to carry a
customer's (individual or bundled) service (may be point-to-point, customer's (individual or bundled) service (may be point-to-point,
point-to-multipoint or multipoint-to-multipoint services). point-to-multipoint or multipoint-to-multipoint services).
3.15. Span: 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. A span is synonymous with a link.
3.16. Sublayer: 3.18. 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.17. Tandem Connection: 3.19. 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 be monitored (via OAM) independently from the end-to-end can be monitored (via OAM) independently from the end-to-end
monitoring (OAM). It may be a monitored segment, a monitored monitoring (OAM). It may be a monitored segment, a monitored
concatenated segment or any other monitored ordered sequence of concatenated segment or any other monitored ordered sequence of
contiguous hops and/or segments (and their interconnecting nodes) of contiguous hops and/or segments (and their interconnecting nodes) of
a transport path. 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)
functions.
3.21. Transport path:
A network connection as defined in [ITU-T_G.805]. In an MPLS-TP 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. 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:
3.19. Transport path layer:
A layer network which provides point-to-point or point-to-multipoint A (sub)layer network that provides point-to-point or point-to-
transport paths which are used to carry a higher (client) layer multipoint transport paths. It provides OAM that is independent of
network or aggregates of higher (client) layer networks, for example the clients that it is transporting.
the transport service layer. It provides for independent OAM (of
the client OAM) in the transport of the clients.
3.20. Transport service layer: 3.23. Transport service layer:
A layer network in which transport paths are used to carry a A layer network in which transport paths are used to carry a
customer's (individual or bundled) service (may be point-to-point, customer's (individual or bundled) service (may be point-to-point,
point-to-multipoint or multipoint-to-multipoint services). point-to-multipoint or multipoint-to-multipoint services).
3.21. Transmission media layer: 3.24. Transmission media layer:
A layer network which provides sections (two-port point-to-point A layer network, consisting of a section layer network and a
connections) to carry the aggregate of network transport path or physical layer network as defined in [ITU-T_G.805], that provides
network service layers on various physical media. sections (two-port point-to-point connections) to carry the
aggregate of network-transport path or network-service layers on
various physical media.
3.22. Unidirectional path: 3.25. Unidirectional path:
A path that supports traffic flow in only one direction. A path that supports traffic flow in only one direction.
=== [editor: from: draft-ietf-mpls-tp-oam-requirements [1]]
from: draft-ietf-mpls-tp-oam-requirements-00 [2]
3.23. Failure: 3.26. Failure:
[editor: this is not in [2] BUT added for completeness] [editor: this is not in [1] BUT added for completeness]
The fault cause persisted long enough to consider the ability of an The fault cause persisted long enough to consider the ability of an
item to perform a required function to be terminated. The item may item to perform a required function to be terminated. The item may
be considered as failed; a fault has now been detected. See also be considered as failed; a fault has now been detected. See also
[ITU-T_G.806]. [ITU-T_G.806].
3.24. Fault: 3.27. Fault:
The inability of a function to perform a required action. This does The inability of a function to perform a required action. This does
not include an inability due to preventive maintenance, lack of not include an inability due to preventive maintenance, lack of
external resources, or planned actions. See also [ITU-T_G.806]. external resources, or planned actions. See also [ITU-T_G.806].
3.25. Defect: 3.28. Defect:
The situation for which density of anomalies has reached a level The situation for which density of anomalies has reached a level
where the ability to perform a required function has been 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 interrupted. Defects are used as input for PM, the control of
consequent actions, and the determination of fault cause. See also consequent actions, and the determination of fault cause. See also
[ITU-T_G.806]. [ITU-T_G.806].
3.26. MPLS Transport Profile (MPLS-TP): 3.29. MPLS Transport Profile (MPLS-TP):
The set of MPLS functions used to support packet transport services The set of MPLS functions used to support packet transport services
and network operations. and network operations.
3.27. MPLS Section: 3.30. MPLS Section:
A network segment between two LSRs that are immediately adjacent at A network segment between two LSRs that are immediately adjacent at
the MPLS layer. the MPLS layer.
== [editor: from: draft-ietf-mpls-tp-framework [2]]
From: draft-ietf-mpls-tp-framework-00 [3]
==
From: draft-gray-mpls-tp-nm-req-03 [4] [editor: from: draft-gray-mpls-tp-nm-req [3]]
3.28. MPLS-TP NE: 3.31. MPLS-TP NE:
A network element (NE) that supports MPLS-TP functions. A network element (NE) that supports MPLS-TP functions.
3.29. MPLS-TP network: 3.32. MPLS-TP network:
A network in which MPLS-TP NEs are deployed A network in which MPLS-TP NEs are deployed
3.30. Equipment Management Function (EMF): 3.33. Equipment Management Function (EMF):
The management functions within an NE. See [ITU-T G.7710]. The management functions within an NE. See [ITU-T G.7710].
3.31. Data Communication Network (DCN): 3.34. Data Communication Network (DCN):
A network that supports Layer 1 (physical layer), Layer 2 (data-link A network that supports Layer 1 (physical layer), Layer 2 (data-link
layer), and Layer 3 (network layer) functionality for distributed layer), and Layer 3 (network layer) functionality for distributed
management communications related to the management plane, for management communications related to the management plane, for
distributed signaling communications related to the control plane, distributed signaling communications related to the control plane,
and other operations communications (e.g., order-wire/voice and other operations communications (e.g., order-wire/voice
communications, software downloads, etc.). communications, software downloads, etc.).
3.32. Communication Channel (CC): 3.35. Communication Channel (CC):
A logical channel between network elements (NEs) that can be used - A logical channel between network elements (NEs) that can be used -
e.g. - for management plane application or control plane 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 applications. The physical channel supporting the CC is technology
specific. See [4] APPENDIX A specific. See [3] APPENDIX A
3.33. Embedded Communication Channel (ECC): 3.36. Embedded Communication Channel (ECC):
A logical operations channel between network elements (NEs) that can A logical operations channel between network elements (NEs) that can
be utilized by multiple applications (e.g., management plane 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 channel supporting the ECC is technology specific. An example of
physical channels supporting the ECC is a DCC channel within SDH. physical channels supporting the ECC is a DCC channel within SDH.
3.34. Management Communication Channel (MCC): 3.37. Management Communication Channel (MCC):
A CC dedicated for management plane communications. A CC dedicated for management plane communications.
3.35. Management Communication Network (MCN): 3.38. 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.36. Signaling Communication Channel (SCC): 3.39. Signaling Communication Channel (SCC):
A CC dedicated for control plane communications. The SCC may be used A CC dedicated for control plane communications. The SCC may be used
for GMPLS/ASON signaling and/or other control plane messages (e.g., for GMPLS/ASON signaling and/or other control plane messages (e.g.,
routing messages). routing messages).
3.37. Signaling Communication Network (SCN): 3.40. 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.38. Operations System (OS): 3.41. Operations System (OS):
A system that performs the functions that support processing of A system that performs the functions that support processing of
information related to operations, administration, maintenance, and information related to operations, administration, maintenance, and
provisioning (OAM&P) for the networks, including surveillance and provisioning (OAM&P) for the networks, including surveillance and
testing functions to support customer access maintenance. testing functions to support customer access maintenance.
== [editor: from: draft-busi-mpls-tp-oam-framework-00 [4]]
From: draft-busi-mpls-tp-oam-framework-00 [5]
MPLS Section: [editor: see 3.27]
OAM flow: to be added in a future revision of this document. [editor: MPLS Section: already defined in 3.30]
Tandem Connection: [editor: see 3.17] [editor: OAM flow: to be added in future revision of this document.]
Internet-Draft MPLS-TP Rosetta Stone Huub van Helvoort [editor: Tandem Connection: already defined in 3.19]
3.39. Maintenance Entity 3.42. Maintenance Entity
A Maintenance Entity can be viewed as the association of two (or A Maintenance Entity can be viewed as the association of two (or
more) Maintenance End Points (MEPs), that should be configured and more) Maintenance End Points (MEPs), that should be configured and
managed in order to bound the OAM responsibilities of an OAM flow managed in order to bound the OAM responsibilities of an OAM flow
[editor: definition?] across a network or sub-network, i.e. a [editor: definition?] across a network or sub-network, i.e. a
transport path or segment, in the specific layer network that is transport path or segment, in the specific layer network that is
being monitored and managed. being monitored and managed.
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
skipping to change at page 12, line 36 skipping to change at page 13, line 34
The following properties apply to all MPLS-TP MEs: The following properties apply to all MPLS-TP MEs:
o OAM entities can be nested but not overlapped. o OAM entities can be nested but not overlapped.
o Each OAM flow is associated to a unique Maintenance Entity. o Each OAM flow is associated to a unique Maintenance Entity.
o OAM packets are subject to the same forwarding treatment as the o OAM packets are subject to the same forwarding treatment as the
data traffic, but they are distinct from the data traffic. data traffic, but they are distinct from the data traffic.
3.40. Maintenance End Points (MEPs) 3.43. Maintenance End Points (MEPs)
Maintenance End Points (MEPs) are the end points of a pre-configured Maintenance End Points (MEPs) are the end points of a pre-configured
(through the management or control planes) ME. MEPs are responsible (through the management or control planes) ME. MEPs are responsible
for activating and controlling all of the OAM functionality for the for activating and controlling all of the OAM functionality for the
ME. A MEP may initiate an OAM packet to be transferred to its 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. corresponding MEP, or to an intermediate MIP that is part of the ME.
A MEP terminates all the OAM packets that it receives corresponding A MEP terminates all the OAM packets that it receives corresponding
to its ME and does not forward them further along the path. to its ME and does not forward them further along the path.
All OAM packets coming to a MEP source are tunnelled via label All OAM packets coming to a MEP source are tunnelled 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 the client network layers or to an higher TCM level. to the client network layers or to an higher 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. 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 transport path is coincident with transport path termination and
monitors its connectivity (e.g. count packets). monitors its connectivity (e.g. count packets).
MPLS-TP MEP notifies a fault indication to the MPLS-TP client layer MPLS-TP MEP notifies a fault indication to the MPLS-TP client layer
network. network.
3.41. Maintenance Intermediate Points (MIPs) 3.44. Maintenance Intermediate Points (MIPs)
A Maintenance Intermediate Point (MIP) is a point between the two 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 MEPs in an ME and is capable of responding to some OAM packets and
forwarding all OAM packets while ensuring fate sharing with data forwarding all OAM packets while ensuring fate sharing with data
plane packets. A MIP responds only to OAM packets that are sent on 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 the ME it belongs to and that are addressed to the MIP, it does not
initiate OAM messages. initiate OAM messages.
3.42. Server MEPs 3.45. 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 (MPLS-TP) layer
network. network.
For example, a server MEP can be either: For example, a server MEP can be either:
. A termination point of a physical link (e.g. 802.3), an SDH VC or . 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] OTH ODU for the MPLS-TP Section layer network, defined in [5]
skipping to change at page 14, line 4 skipping to change at page 15, line 4
detection, and notifies a fault indication to the MPLS-TP layer detection, and notifies a fault indication to the MPLS-TP layer
network. network.
[editor: the following are definitions from G.8101 which should be [editor: the following are definitions from G.8101 which should be
defined only if they will cause misunderstanding. It is not usefull 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] to define them if the definition is the same in IETF and ITU-T, TBD]
===== [ITU-T_G.8101] ===== ===== [ITU-T_G.8101] =====
3.1 access point 3.1 access point
Internet-Draft MPLS-TP Rosetta Stone Huub van Helvoort
3.2 adapted information 3.2 adapted information
3.3 characteristic information 3.3 characteristic information
3.4 client/server relationship 3.4 client/server relationship
3.5 connection 3.5 connection
3.6 connection point 3.6 connection point
skipping to change at page 15, line 4 skipping to change at page 16, line 4
3.25 trail termination point 3.25 trail termination point
3.26 transport 3.26 transport
3.27 transport entity 3.27 transport entity
3.28 transport processing function 3.28 transport processing function
3.29 unidirectional connection 3.29 unidirectional connection
Internet-Draft MPLS-TP Rosetta Stone Huub van Helvoort
3.30 unidirectional trail 3.30 unidirectional trail
3.31 Z layer 3.31 Z layer
Transport MPLS (T-MPLS) Recommendations uses the following terms Transport MPLS (T-MPLS) Recommendations uses the following terms
defined in ITU-T Rec. G.809: defined in ITU-T Rec. G.809:
3.33 access point 3.33 access point
3.34 adaptation 3.34 adaptation
skipping to change at page 16, line 4 skipping to change at page 17, line 4
3.60 backward direction 3.60 backward direction
3.62 client/server (relationship between layer networks) 3.62 client/server (relationship between layer networks)
3.63 failure 3.63 failure
3.64 forward direction 3.64 forward direction
3.65 user-plane 3.65 user-plane
Internet-Draft MPLS-TP Rosetta Stone Huub van Helvoort
Transport MPLS (T-MPLS) Recommendations uses the following terms Transport MPLS (T-MPLS) Recommendations uses the following terms
defined in [ITU-T_Y.1720]: defined in [ITU-T_Y.1720]:
3.66 1+1 protection 3.66 1+1 protection
3.67 1:1 protection 3.67 1:1 protection
3.68 bidirectional protection switching 3.68 bidirectional protection switching
3.69 bridge 3.69 bridge
skipping to change at page 17, line 4 skipping to change at page 18, line 4
3.84 rerouting 3.84 rerouting
3.85 revertive protection switching 3.85 revertive protection switching
3.86 selector 3.86 selector
3.87 shared mesh protection 3.87 shared mesh protection
3.88 Shared Risk Group (SRG) 3.88 Shared Risk Group (SRG)
Internet-Draft MPLS-TP Rosetta Stone Huub van Helvoort
3.89 sink of the protection domain 3.89 sink of the protection domain
3.90 source of the protection domain 3.90 source of the protection domain
3.91 unidirectional protection switching 3.91 unidirectional protection switching
3.92 wait to restore 3.92 wait to restore
3.93 wait to restore timer 3.93 wait to restore timer
skipping to change at page 18, line 5 skipping to change at page 19, line 5
5. Management Considerations 5. Management Considerations
The MPLS-TP based network requires management. The MPLS-TP The MPLS-TP based network requires management. The MPLS-TP
specifications include considerable efforts to provide operator specifications include considerable efforts to provide operator
control and monitoring, as well as Operations and Management (OAM) control and monitoring, as well as Operations and Management (OAM)
functionality. functionality.
These concepts are, however, out of scope of this document. These concepts are, however, out of scope of this document.
Internet-Draft MPLS-TP Rosetta Stone Huub van Helvoort
6. Security Considerations 6. Security Considerations
Security is also a significant requirement of MPLS-TP. Security is also a significant requirement of MPLS-TP.
However, this informational document is intended only to provide a However, this informational document is intended only to provide a
lexicography, and the security concerns are, therefore, out of lexicography, and the security concerns are, therefore, out of
scope. scope.
7. IANA Considerations 7. IANA Considerations
skipping to change at page 18, line 32 skipping to change at page 19, line 30
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 IETF and the
T-MPLS Ad Hoc Group in ITU-T) involved in the definition and T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS Transport Profile. specification of MPLS Transport Profile.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] B. Niven-Jenkins, et al., "MPLS-TP Requirements", draft-ietf- [1] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
mpls-mpls-tp-requirements, november 2008 MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-
03, august 2009
[2] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
MPLS Transport Networks", draft-vigoureux-mpls-tp-oam-
requirements, november 2008
[3] Bocci, M., Bryant, S., "A Framework for MPLS in Transport [2] Bocci, M., Bryant, S., Levrau, L., "A Framework for MPLS in
Networks", draft-ietf-mpls-tp-framework, november 2008 Transport Networks'', draft-ietf-mpls-tp-framework-06, october
2009
[4] Gray, E., Mansfield, S., et al., "MPLS TP Network Management [3] Gray, E., Mansfield, S., et al., ''MPLS TP Network Management
Requirements", draft-gray-mpls-tp-nm-req, november 2008 Requirements'', draft-ietf-mpls-tp-nm-req-06, october 2009
[5] Busi, I., Niven-Jenkins, B., et al., "MPLS-TP OAM Framework [4] Busi, I., Niven-Jenkins, B., et al., ''MPLS-TP OAM Framework
and Overview", draft-busi-mpls-tp-oam-framework, november 2008 and Overview'', draft-ietf-mpls-tp-oam-framework-01, july 2009
[RFC3031] [RFC5654] B. Niven-Jenkins, et al., ''Requirements of an MPLS
Transport Profile'', September 2009
[RFC4397] [RFC3031] E. Rosen, etal., ''Requirements of an MPLS Transport
Profile'', january 2001
Internet-Draft MPLS-TP Rosetta Stone Huub van Helvoort [RFC4397] I. Bryskin, A. Farrel, ''A Lexicography for the
Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within the Context of the
ITU-T's Automatically Switched Optical Network (ASON)
Architecture'', february 2006
9.2. Informative References 9.2. Informative References
For information on the availability of the following documents, For information on the availability of the following documents,
please see http://www.itu.int please see http://www.itu.int
[ITU-T_G.8101] ITU-T Recommendation G.8101/Y.1355 (12/2006), Terms [ITU-T_G.8101] ITU-T Recommendation G.8101/Y.1355 (12/2006), Terms
and definitions for transport MPLS. and definitions for transport MPLS.
[ITU-T_G.805] ITU-T Recommendation G.805 (03/2000), Generic [ITU-T_G.805] ITU-T Recommendation G.805 (03/2000), Generic
skipping to change at page 19, line 42 skipping to change at page 20, line 43
optical transport networks. optical transport networks.
[ITU-T G.7710] ITU-T Recommendation G.7710 (07/2007), Common [ITU-T G.7710] ITU-T Recommendation G.7710 (07/2007), Common
equipment management function requirements equipment management function requirements
[ITU-T Y.2611] ITU-T Recommendation Y.2611 (12/2006), High-level [ITU-T Y.2611] ITU-T Recommendation Y.2611 (12/2006), High-level
architecture of future packet-based networks architecture of future packet-based networks
Authors' Addresses Authors' Addresses
Huub van Helvoort (Editor) Huub van_Helvoort (Editor)
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
Email: hhelvoort@huawei.com Email: hhelvoort@huawei.com
Loa Andersson (Editor) Loa Andersson (Editor)
Redback Redback
Email: loa@pi.nu Email: loa@pi.nu
Internet-Draft MPLS-TP Rosetta Stone Huub van Helvoort
Nurit Sprecher (Editor) Nurit Sprecher (Editor)
Nokia Siemens Networks Nokia Siemens Networks
Email: nurit.sprecher@nsn.com Email: nurit.sprecher@nsn.com
Contributing Authors' Addresses Contributing Authors' Addresses
 End of changes. 96 change blocks. 
233 lines changed or deleted 225 lines changed or added

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