draft-ietf-mpls-tp-rosetta-stone-09.txt   draft-ietf-mpls-tp-rosetta-stone-10.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: July 2013 L. Andersson (Ed) Expires: August 2013 L. Andersson (Ed)
Huawei Technologies Huawei Technologies
N. Sprecher (Ed) N. Sprecher (Ed)
Nokia Siemens Networks Nokia Siemens Networks
January 20, 2013 February 12, 2013
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-09 draft-ietf-mpls-tp-rosetta-stone-10
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.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 reference at any time. It is inappropriate to use Internet-Drafts as 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 in July 2013. This Internet-Draft will expire in August 2013.
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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
Table of Contents Table of Contents
1. Introduction 4 1. Introduction 4
1.1. Contributing Authors 4 1.1. Contributing Authors 4
1.2. Abbreviations 4 1.2. Abbreviations 4
SCC Signaling Communication Channel 5 SCC Signaling Communication Channel 5
2. Terminology 5 2. Terminology 5
2.1. MPLS-TP Terminology Sources 5 2.1. MPLS-TP Terminology Sources 5
2.2. ITU-T Transport Network Terminology Sources 5 2.2. ITU-T Transport Network Terminology Sources 5
2.3. Common Terminology Sources 5 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: 6
3.3. Client layer network: 6 3.3. Client layer network: 6
3.4. Concatenated Segment: 6 3.4. Communication Channel (CC): 6
3.5. Control Plane: 6 3.5. Concatenated Segment: 7
3.6. Co-routed bidirectional path: 7 3.6. Control Plane: 7
3.7. Domain: 7 3.7. Co-routed bidirectional path: 7
3.8. Layer network: 7 3.8. Data Communication Network (DCN): 7
3.9. Link: 7 3.9. Defect: 7
3.10. MPLS-TP Logical Ring: 8 3.10. Domain: 7
3.11. MPLS-TP Physical Ring: 8 3.11. Embedded Communication Channel (ECC): 8
3.12. MPLS-TP Ring Topology: 8 3.12. Equipment Management Function (EMF): 8
3.13. Path: 8 3.13. Failure: 8
3.14. Section Layer Network: 8 3.14. Fault: 8
3.15. Segment: 9 3.15. Layer network: 8
3.16. Server layer: 9 3.16. Link: 9
3.17. Span: 9 3.17. Maintenance Entity (ME): 9
3.18. Sublayer: 9 3.18. Maintenance Entity Group (MEG): 9
3.19. Tandem Connection: 9 3.19. Maintenance Entity Group End Point (MEP): 10
3.20. Transport Network: 9 3.20. Maintenance Entity Group Intermediate Point (MIP): 10
3.21. Transport path: 10 3.21. Management Communication Channel (MCC): 10
3.22. Transport path layer: 10 3.22. Management Communication Network (MCN): 10
3.23. Transport service layer: 10 3.23. Monitoring 11
3.24. Transmission media layer: 10 3.23.1. Path Segment Tunnel (PST): 11
3.25. Unidirectional path: 10 3.23.2. Sub-Path Maintenance Element (SMPE): 11
3.26. Failure: 10 3.23.3. Tandem Connection: 11
3.27. Fault: 10 3.24. MPLS Section: 12
3.28. Defect: 11 3.25. MPLS Transport Profile (MPLS-TP): 12
3.29. MPLS Transport Profile (MPLS-TP): 11 3.26. MPLS-TP NE: 12
3.30. MPLS Section: 11 3.27. MPLS-TP network: 12
3.31. MPLS-TP NE: 11 3.28. MPLS-TP Recovery: 12
3.32. MPLS-TP network: 11 3.28.1. End-to-end recovery: 12
3.33. Equipment Management Function (EMF): 11 3.28.2. Link recovery: 12
3.34. Data Communication Network (DCN): 11 3.28.3. Segment recovery: 12
3.35. Communication Channel (CC): 11 3.29. MPLS-TP Ring Topology: 13
3.36. Embedded Communication Channel (ECC): 12 3.29.1. MPLS-TP Logical Ring: 13
3.37. Management Communication Channel (MCC): 12 3.29.2. MPLS-TP Physical Ring: 13
3.38. Management Communication Network (MCN): 12 3.30. OAM flow: 13
3.39. Signaling Communication Channel (SCC): 12 3.31. Operations System (OS): 13
3.40. Signaling Communication Network (SCN): 12 3.32. Path: 13
3.41. Operations System (OS): 12 3.33. Section Layer Network: 13
3.42. OAM flow: 12 3.34. Segment: 14
3.43. Maintenance Entity Group (MEG): 13 3.35. Server layer: 14
3.44. Maintenance Entity (ME): 13 3.36. Server MEPs: 14
3.45. Maintenance Entity Group End Point (MEP): 13 3.37. Signaling Communication Channel (SCC): 15
3.46. Maintenance Entity Group Intermediate Point (MIP): 14 3.38. Signaling Communication Network (SCN): 15
3.47. Server MEPs: 14 3.39. Span: 15
3.48. Link recovery: 15 3.40. Sublayer: 15
3.49. Segment recovery: 15 3.41. Transport Entity: 15
3.50. End-to-end recovery: 15 3.41.1. Working Entity: 15
3.51. Transport Entity: 15 3.41.2. Protection Entity: 16
3.52. Working Entity: 15 3.41.3. Recovery entity: 16
3.53. Protection Entity: 15 3.42. Transmission media layer: 16
3.54. Recovery entity: 15 3.43. Transport Network: 16
4. Guidance on the Application of this Thesaurus 16 3.44. Transport path: 16
5. Management Considerations 16 3.45. Transport path layer: 16
6. Security Considerations 16 3.46. Transport service layer: 17
7. IANA Considerations 16 3.47. Unidirectional path: 17
8. Acknowledgments 17 4. Guidance on the Application of this Thesaurus 17
9. References 17 5. Management Considerations 17
9.1. Normative References 17 6. Security Considerations 18
9.2. Informative References 18 7. IANA Considerations 18
8. Acknowledgments 18
9. References 18
9.1. Normative References 18
9.2. Informative References 20
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
skipping to change at page 4, line 38 skipping to change at page 4, line 42
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, Stuart Bryant, Dan Frost, Matthew Bocci, Levrau, Dinesh Mohan, Stuart Bryant, Dan Frost, Matthew Bocci,
Vincenzo Sestito, Vigoureux, Yaacov Weingarten Vincenzo Sestito, Vigoureux, Yaacov Weingarten
1.2. Abbreviations 1.2. Abbreviations
CC Communications Channel CC Communications Channel
CE Customer Edge
DCN Data Communication Network DCN Data Communication Network
ECC Embedded Communication Channel ECC Embedded Communication Channel
EMF Equipment Management Function EMF Equipment Management Function
MCC Management Communication Channel MCC Management Communication Channel
MCN Management Communication Network MCN Management Communication Network
ME Maintenance Entity ME Maintenance Entity
MEG ME Group
MEP MEG End Point MEG Maintenance Entity Group
MIP MEG Intermediate Point MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group 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
O&M OAM and Management PST Path Segment Tunnel
SCC Signaling Communication Channel SCC Signaling Communication Channel
SCN Signaling Communication Network SCN Signaling Communication Network
SPME Sub-Path Maintenance Element
TCM Tandem Connection Monitoring
2. Terminology 2. Terminology
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 provide further key definitions including [RFC4397].
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
skipping to change at page 6, line 4 skipping to change at page 6, line 14
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.
The following sources are used: The following sources are used:
IETF framework and requirements RFCs: [RFC6371], [RFC6372], IETF framework and requirements RFCs: [RFC6371], [RFC6372],
[RFC5654], [RFC5921], [RFC5860], [RFC5951], [RFC3031] and [RFC4397]. [RFC5654], [RFC5921], [RFC5860], [RFC5951], [RFC3031] and [RFC4397].
ITU-T architecture and requirements Recommendations: [ITU-T_G.8101], 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_G.805], [ITU-T_G.806], [ITU-T_G.872], [ITU-T G.7710] and
[ITU-T Y.2611] [ITU-T Y.2611].
3. Thesaurus 3. Thesaurus
3.1. Associated bidirectional path: 3.1. Associated bidirectional path:
A path that supports traffic flow in both directions but that 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) that 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 ingress/egress points. The forward and backward directions are
setup, monitored, and protected independently. As a consequence, setup, monitored, and protected independently. As a consequence,
skipping to change at page 6, line 31 skipping to change at page 6, line 40
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. Client layer network: 3.3. Client layer network:
In a client/server relationship (see [ITU-T_G.805]), the client In a client/server relationship (see [ITU-T_G.805]), the client
layer network receives a (transport) service from the lower server layer network receives a (transport) service from the lower server
layer network (usually the layer network under consideration). layer network (usually the layer network under consideration).
3.4. Concatenated Segment: 3.4. Communication Channel (CC):
A logical channel between network elements (NEs) that can be used -
e.g. - for management plane application or control plane
applications. The physical channel supporting the CC is technology
specific. See [RFC5951] APPENDIX A.
3.5. 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. See also "Segment". in sequence. See also "Segment".
3.5. Control Plane: 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 signalling, 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 other functions in support of transport path control, such performs other functions in support of transport path control, such
as routing information dissemination. as routing information dissemination.
3.6. Co-routed bidirectional path: 3.7. Co-routed bidirectional path:
A path where the forward and backward directions follow the same A path where the forward and backward directions follow the same
route (links and nodes) across the network. Both directions are route (links and nodes) across the network. Both directions are
setup, monitored and protected as a single entity. A transport setup, monitored and protected as a single entity. A transport
network path is typically co-routed. network path is typically co-routed.
3.7. Domain: 3.8. Data Communication Network (DCN):
A network that supports Layer 1 (physical layer), Layer 2 (data-link
layer), and Layer 3 (network layer) functionality for distributed
management communications related to the management plane, for
distributed signaling communications related to the control plane,
and other operations communications (e.g., order-wire/voice
communications, software downloads, etc.).
3.9. Defect:
The situation for which the density of anomalies has reached a level
where the ability to perform a required function has been
interrupted. Defects are used as input for PM, the control of
consequent actions, and the determination of fault cause. See also
[ITU-T_G.806].
3.10. Domain:
A domain represents a collection of entities (for example network 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.8. Layer network: 3.11. Embedded Communication Channel (ECC):
A logical operations channel between network elements (NEs) that can
be utilized by multiple applications (e.g., management plane
applications, control plane applications, etc.). The physical
channel supporting the ECC is technology specific. An example of
physical channels supporting the ECC is a DCC channel within SDH.
3.12. Equipment Management Function (EMF):
The management functions within an NE. See [ITU-T G.7710].
3.13. Failure:
The fault cause persisted long enough to consider the ability of an
item to perform a required function to be terminated. The item may
be considered as failed; a fault has now been detected. See also
[ITU-T_G.806].
3.14. Fault:
A Fault is the inability of a function to perform a required action.
This does not include an inability due to preventive maintenance,
lack of external resources, or planned actions. See also [ITU-
T_G.806].
3.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 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 a higher client layer network and may, in turn, be a service to a higher client layer network and may, in turn, be a
client to a lower-layer network. A layer network is a logical client to a lower-layer network. A layer network is a logical
construction somewhat independent of arrangement or composition of construction somewhat independent of arrangement or composition of
physical network elements. A particular physical network element physical network elements. A particular physical network element
may topologically belong to more than one layer network, depending may topologically belong to more than one layer network, depending
on the actions it takes on the encapsulation 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 one 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].
3.9. Link: 3.16. 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.10. MPLS-TP Logical Ring: 3.17. Maintenance Entity (ME):
An MPLS-TP logical ring is constructed from a set of LSRs and
logical data links (such as MPLS-TP LSP tunnels or MSPL-TP
pseudowires) and physical data links that form a ring topology.
3.11. MPLS-TP Physical Ring:
An MPLS-TP physical ring is constructed from a set of LSRs and
physical data links that form a ring topology.
3.12. MPLS-TP Ring Topology:
In an MPLS-TP ring topology, each LSR is connected to exactly two
other LSRs, each via a single point-to-point bidirectional MPLS-TP
capable link. A ring may also be constructed from only two LSRs
where there are also exactly two links. Rings may be connected to
other LSRs to form a larger network. Traffic originating or
terminating outside the ring may be carried over the ring. Client
network nodes (such as CEs) may be connected directly to an LSR in
the ring.
3.13. Path:
See Transport path. A Maintenance Entity (ME) can be viewed as the association of two
(or more) Maintenance Entity Group End Points (MEPs), that should be
configured and managed in order to bound the OAM responsibilities of
an OAM flow across a network or sub-network, i.e. a transport path
or segment, in the specific layer network that is being monitored
and managed. See also [RFC6371] section 3.1 and [ITU-T G.8113.1],
[ITU-T G.8113.2] clause 6.1.
3.14. Section Layer Network: A Maintenance Entity may be defined to monitor and manage
bidirectional or unidirectional point-to-point connectivity or
point-to-multipoint connectivity in an MPLS-TP layer network.
A section layer is a server layer (which may be MPLS-TP or a Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity
different technology) that provides for the transfer of the section- (defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can
layer client information between adjacent nodes in the transport- be MIPs. In the case of Tandem Connection Maintenance Entity
path layer or transport-service layer. A section layer may provide (defined below), LSRs and S-PEs can be either MEPs or MIPs.
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 The following properties apply to all MPLS-TP MEs:
provide for the transfer of information between locations in path
layer networks.
Physical media layer networks are concerned with the actual fibres, o OAM entities can be nested but not overlapped.
metallic wires or radio frequency channels which support a section
layer network.
3.15. Segment: o Each OAM flow is associated to a unique Maintenance Entity.
A link connection as defined in [ITU-T_G.805]. A segment is the o OAM packets are subject to the same forwarding treatment as the
part of an LSP that traverses a single link or the part of a PW that data traffic, but they are distinct from the data traffic.
traverses a single link (i.e., that connects a pair of adjacent
{Switching|Terminating} Provider Edges). See also "Concatenated
Segment".
3.16. Server layer: 3.18. Maintenance Entity Group (MEG):
A layer network in which transport paths are used to carry a A Maintenance Entity Group is defined, for the purpose of connection
customer's (individual or bundled) service (may be point-to-point, monitoring, between a set of connection points within a connection.
point-to-multipoint or multipoint-to-multipoint services). This set of connection points may be located at the boundary of one
administrative domain or a protection domain, or the boundaries of
two adjacent administrative domains. The MEG may consist of one or
more Maintenance Entities (ME). See also [RFC6371] section 3.1 and
[ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.2.
In a client/server relationship (see [ITU-T_G.805]). the server In an MPLS-TP layer network a MEG consists of only one ME.
layer network provides a (transport) service to the higher client
layer network (usually the layer network under consideration).
3.17. Span: 3.19. Maintenance Entity Group End Point (MEP):
A span is synonymous with a link. Maintenance Entity Group End Points (MEPs) are the end points of a
pre-configured (through the management or control planes) ME. MEPs
are responsible for activating and controlling all of the OAM
functionality for the ME. A source MEP may initiate an OAM packet to
be transferred to its corresponding peer or sink MEP, or to an
intermediate MIP that is part of the ME. See also [RFC6371] section
3.3 and [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.3.
3.18. Sublayer: A sink MEP terminates all the OAM packets that it receives
corresponding to its ME and does not forward them further along the
path.
Sublayer is defined in [ITU-T_G.805]. The distinction between a All OAM packets coming into a source MEP are tunnelled via label
layer network and a sublayer is that a sublayer is not directly stacking and are not processed within the ME as they belong either
accessible to clients outside of its encapsulating layer network and to the client network layers or to an higher TCM level.
offers no direct transport service for a higher layer (client)
network.
3.19. Tandem Connection: A MEP in a tandem connection is not coincident with the termination
of the MPLS-TP transport path (LSP or PW), though it can monitor its
connectivity (e.g. count packets). A MEP of an MPLS-TP network
transport path is coincident with transport path termination and
monitors its connectivity (e.g. count packets).
A tandem connection is an arbitrary part of a transport path that An MPLS-TP sink MEP can notify a fault condition to its MPLS-TP
can be monitored (via OAM) independently from the end-to-end client layer network.
monitoring (OAM). It may be a monitored segment, a monitored
concatenated segment or any other monitored ordered sequence of
contiguous hops and/or segments (and their interconnecting nodes) of
a transport path.
3.20. Transport Network: 3.20. Maintenance Entity Group Intermediate Point (MIP):
A Transport Network provides transmission of traffic between A Maintenance Entity Group Intermediate Point (MIP) is a point
attached client devices by establishing and maintaining point-to- between the two MEPs in an ME and is capable of responding to some
point or point-to-multipoint connections between such devices. A OAM packets and forwarding all OAM packets while ensuring fate
Transport Network is independent of any higher-layer network that sharing with data plane packets. A MIP responds only to OAM packets
may exist between clients, except to the extent required to supply that are sent on the ME it belongs to and that are addressed to the
this transmission service. In addition to client traffic, a MIP, it does not initiate OAM messages. See also [RFC6371] section
Transport Network may carry traffic to facilitate its own operation, 3.4 and [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.4.
such as that required to support connection control, network
management, and Operations, Administration and Maintenance (OAM)
functions.
3.21. Transport path: 3.21. Management Communication Channel (MCC):
A network connection as defined in [ITU-T_G.805]. In an MPLS-TP A CC dedicated for management plane communications.
environment a transport path corresponds to an LSP or a PW.
3.22. Transport path layer: 3.22. Management Communication Network (MCN):
A (sub)layer network that provides point-to-point or point-to- A DCN supporting management plane communication is referred to as a
multipoint transport paths. It provides OAM that is independent of Management Communication Network (MCN).
the clients that it is transporting.
3.23. Transport service layer: 3.23. Monitoring
A layer network in which transport paths are used to carry a Monitoring is applying OAM functionality to verify and to maintain
customer's (individual or bundled) service (may be point-to-point, the performance and the quality guarantees of a transport path.
point-to-multipoint or multipoint-to-multipoint services). There is a need to not only monitor the whole transport path (e.g.
LSP or MS-PW), but also arbitrary parts of transport paths. The
connection between any two arbitrary points along a transport path
is described in three ways:
- as a Path Segment Tunnel,
- as a Sub-Path Maintenance Element, and
- as a Tandem Connections.
3.24. Transmission media layer: 3.23.1. Path Segment Tunnel (PST):
A layer network, consisting of a section layer network and a A path segment is either a segment or a concatenated segment. Path
physical layer network as defined in [ITU-T_G.805], that provides Segment Tunnels (PSTs) are instantiated to provide monitoring of a
sections (two-port point-to-point connections) to carry the portion of a set of co-routed transport paths (LSPs or MS-PWs).
aggregate of network-transport path or network-service layers on Path segment tunnels can also be employed to meet the requirement to
various physical media. provide Tandem Connection Monitoring, see Tandem Connection.
3.25. Unidirectional path: 3.23.2. Sub-Path Maintenance Element (SMPE):
A Unidirectional Path is a path that supports traffic flow in only To monitor, protect, and manage a portion (i.e., segment or
one direction. concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be
instantiated. A hierarchical LSP instantiated for this purpose is
called a Sub-Path Maintenance Element (SPME). Note that by
definition an SPME does not carry user traffic as a direct client.
3.26. Failure: An SPME is defined between the edges of the portion of the LSP that
needs to be monitored, protected or managed. The SPME forms a MPLS-
TP Section that carries the original LSP over this portion of the
network as a client. OAM messages can be initiated at the edge of
the SPME and sent to the peer edge of the SPME or to a MIP along the
SPME. A P router only pushes or pops a label if it is at the end of
a SPME. In this mode, it is an LER for the SPME.
The fault cause persisted long enough to consider the ability of an 3.23.3. Tandem Connection:
item to perform a required function to be terminated. The item may
be considered as failed; a fault has now been detected. See also
[ITU-T_G.806].
3.27. Fault: A tandem connection is an arbitrary part of a transport path that
can be monitored (via OAM) independently from the end-to-end
monitoring (OAM). It may be a monitored segment, a monitored
concatenated segment or any other monitored ordered sequence of
contiguous hops and/or segments (and their interconnecting nodes) of
a transport path.
A Fault is the inability of a function to perform a required action. Tandem Connection Monitoring (TCM) for a given path segment of a
This does not include an inability due to preventive maintenance, transport path is implemented by creating a path segment tunnel that
lack of external resources, or planned actions. See also [ITU- has a 1:1 association with the path segment of the transport path
T_G.806]. that is to be uniquely monitored. This means that the PST used to
provide TCM can carry one and only one transport path thus allowing
direct correlation between all fault management and performance
monitoring information gathered for the PST and the monitored path
segment of the end-to-end transport path. The PST is monitored
using normal LSP monitoring. See also [RFC6371] section 3.2 and
[ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.2.1.
3.28. Defect: 3.24. MPLS Section:
The situation for which the density of anomalies has reached a level A network segment between two LSRs that are immediately adjacent at
where the ability to perform a required function has been the MPLS layer.
interrupted. Defects are used as input for PM, the control of
consequent actions, and the determination of fault cause. See also
[ITU-T_G.806].
3.29. MPLS Transport Profile (MPLS-TP): 3.25. 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.30. MPLS Section: 3.26. MPLS-TP NE:
A network segment between two LSRs that are immediately adjacent at
the MPLS layer.
3.31. MPLS-TP NE:
A network element (NE) that supports MPLS-TP functions. A network element (NE) that supports MPLS-TP functions.
3.32. MPLS-TP network: 3.27. MPLS-TP network:
A network in which MPLS-TP NEs are deployed
3.33. Equipment Management Function (EMF): A network in which MPLS-TP NEs are deployed.
The management functions within an NE. See [ITU-T G.7710]. 3.28. MPLS-TP Recovery:
3.34. Data Communication Network (DCN): 3.28.1. End-to-end recovery:
A network that supports Layer 1 (physical layer), Layer 2 (data-link MPLS-TP End-to-end recovery refers to the recovery of an entire LSP,
layer), and Layer 3 (network layer) functionality for distributed from its ingress to its egress node.
management communications related to the management plane, for
distributed signaling communications related to the control plane,
and other operations communications (e.g., order-wire/voice
communications, software downloads, etc.).
3.35. Communication Channel (CC): 3.28.2. Link recovery:
A logical channel between network elements (NEs) that can be used - MPLS-TP link recovery refers to the recovery of an individual link
e.g. - for management plane application or control plane (and hence all or a subset of the LSPs routed over the link) between
applications. The physical channel supporting the CC is technology two MPLS-TP nodes. For example, link recovery may be provided by
specific. See [RFC5951] APPENDIX A server layer recovery.
3.36. Embedded Communication Channel (ECC): 3.28.3. Segment recovery:
A logical operations channel between network elements (NEs) that can MPLS-TP Segment recovery refers to the recovery of an LSP segment
be utilized by multiple applications (e.g., management plane (i.e., segment and concatenated segment in the language of
applications, control plane applications, etc.). The physical [RFC5654]) between two nodes and is used to recover from the failure
channel supporting the ECC is technology specific. An example of of one or more links or nodes.
physical channels supporting the ECC is a DCC channel within SDH.
3.37. Management Communication Channel (MCC): 3.29. MPLS-TP Ring Topology:
A CC dedicated for management plane communications. In an MPLS-TP ring topology, each LSR is connected to exactly two
other LSRs, each via a single point-to-point bidirectional MPLS-TP
capable link. A ring may also be constructed from only two LSRs
where there are also exactly two links. Rings may be connected to
other LSRs to form a larger network. Traffic originating or
terminating outside the ring may be carried over the ring. Client
network nodes (such as Customer Edges (CEs)) may be connected
directly to an LSR in the ring.
3.38. Management Communication Network (MCN): 3.29.1. MPLS-TP Logical Ring:
A DCN supporting management plane communication is referred to as a An MPLS-TP logical ring is constructed from a set of LSRs and
Management Communication Network (MCN). logical data links (such as MPLS-TP LSP tunnels or MSPL-TP
pseudowires) and physical data links that form a ring topology.
3.39. Signaling Communication Channel (SCC): 3.29.2. MPLS-TP Physical Ring:
A CC dedicated for control plane communications. The SCC may be used An MPLS-TP physical ring is constructed from a set of LSRs and
for GMPLS/ASON signaling and/or other control plane messages (e.g., physical data links that form a ring topology.
routing messages).
3.40. Signaling Communication Network (SCN): 3.30. OAM flow:
A DCN supporting control plane communication is referred to as a An OAM flow is the set of all OAM packets originating with a
Signaling Communication Network (SCN). specific source MEP that instrument one direction of a MEG (or
possibly both in the special case of data plane loopback).
3.41. Operations System (OS): 3.31. 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.
3.42. OAM flow: 3.32. Path:
An OAM flow is the set of all OAM packets originating with a
specific source MEP that instrument one direction of a MEG (or
possibly both in the special case of data plane loopback).
3.43. Maintenance Entity Group (MEG):
A Maintenance Entity Group is defined, for the purpose of connection
monitoring, between a set of connection points within a connection.
This set of connection points may be located at the boundary of one
administrative domain or a protection domain, or the boundaries of
two adjacent administrative domains. The MEG may consist of one or
more Maintenance Entities (ME).
In an MPLS-TP layer network an MEG consists of only one ME.
3.44. Maintenance Entity (ME):
A Maintenance Entity can be viewed as the association of two (or
more) MEG End Points (MEPs), that should be configured and managed
in order to bound the OAM responsibilities of an OAM flow across a
network or sub-network, i.e. a transport path or segment, in the
specific layer network that is being monitored and managed.
A Maintenance Entity may be defined to monitor and manage
bidirectional or unidirectional point-to-point connectivity or
point-to-multipoint connectivity in an MPLS-TP layer network.
Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity
(defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can
be MIPs. In the case of Tandem Connection Maintenance Entity
(defined below), LSRs and S-PEs can be either MEPs or MIPs.
The following properties apply to all MPLS-TP MEs:
o OAM entities can be nested but not overlapped.
o Each OAM flow is associated to a unique Maintenance Entity. See Transport path.
o OAM packets are subject to the same forwarding treatment as the 3.33. Section Layer Network:
data traffic, but they are distinct from the data traffic.
3.45. Maintenance Entity Group End Point (MEP): 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.
Maintenance Entity Group End Points (MEPs) are the end points of a Section layer networks are concerned with all the functions which
pre-configured (through the management or control planes) ME. MEPs provide for the transfer of information between locations in path
are responsible for activating and controlling all of the OAM layer networks.
functionality for the ME. A MEP may initiate an OAM packet to be
transferred to its corresponding MEP, or to an intermediate MIP that
is part of the ME.
A MEP terminates all the OAM packets that it receives corresponding Physical media layer networks are concerned with the actual fibres,
to its ME and does not forward them further along the path. metallic wires or radio frequency channels which support a section
layer network.
All OAM packets coming to a MEP source are tunnelled via label 3.34. Segment:
stacking and are not processed within the ME as they belong either
to the client network layers or to an higher TCM level.
A MEP in a tandem connection is not coincident with the termination A link connection as defined in [ITU-T_G.805]. A segment is the
of the MPLS-TP transport path (LSP or PW), though it can monitor its part of an LSP that traverses a single link or the part of a PW that
connectivity (e.g. count packets). A MEP of an MPLS-TP network traverses a single link (i.e., that connects a pair of adjacent
transport path is coincident with transport path termination and {Switching|Terminating} Provider Edges). See also "Concatenated
monitors its connectivity (e.g. count packets). Segment".
MPLS-TP MEP notifies a fault indication to the MPLS-TP client layer 3.35. Server layer:
network.
3.46. Maintenance Entity Group Intermediate Point (MIP): A service layer is a layer network in which transport paths are used
to carry a customer's (individual or bundled) service (may be point-
to-point, point-to-multipoint or multipoint-to-multipoint services).
A Maintenance Entity Group Intermediate Point (MIP) is a point In a client/server relationship (see [ITU-T_G.805]) the server layer
between the two MEPs in an ME and is capable of responding to some network provides a (transport) service to the higher client layer
OAM packets and forwarding all OAM packets while ensuring fate network (usually the layer network under consideration).
sharing with data plane packets. A MIP responds only to OAM packets
that are sent on the ME it belongs to and that are addressed to the
MIP, it does not initiate OAM messages.
3.47. Server MEPs: 3.36. 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. See also [RFC6371] section 3.5 and [ITU-T G.8113.1] clause
6.5.
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. IEEE 802.3), an SDH
OTH ODU for the MPLS-TP Section layer network, defined in VC or OTH ODU for the MPLS-TP Section layer network, defined in
[RFC6371] section 3.1.; [RFC6371] section 3.1.;
. An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [RFC6371] . An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [RFC6371]
section 3.2.; section 3.2.;
. An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [RFC6371] section . An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [RFC6371] section
3.4.; 3.4.;
. An MPLS-TP TCM MEP for higher-level TCMs, defined in [RFC6371] . An MPLS-TP TCM MEP for higher-level TCMs, defined in [RFC6371]
sections 3.3. and 3.5. sections 3.3. and 3.5.
The server MEP can run appropriate OAM functions for fault The server MEP can run appropriate OAM functions for fault
detection, and notifies a fault indication to the MPLS-TP layer detection, and notifies a fault indication to the MPLS-TP layer
network. network.
3.48. Link recovery: 3.37. Signaling Communication Channel (SCC):
MPLS-TP link recovery refers to the recovery of an individual link A CC dedicated for control plane communications. The SCC may be used
(and hence all or a subset of the LSPs routed over the link) between for GMPLS/ASON signaling and/or other control plane messages (e.g.,
two MPLS-TP nodes. For example, link recovery may be provided by routing messages).
server layer recovery.
3.49. Segment recovery: 3.38. Signaling Communication Network (SCN):
Segment recovery refers to the recovery of an LSP segment (i.e., A DCN supporting control plane communication is referred to as a
segment and concatenated segment in the language of [RFC5654]) Signaling Communication Network (SCN).
between two nodes and is used to recover from the failure of one or
more links or nodes.
3.50. End-to-end recovery: 3.39. Span:
End-to-end recovery refers to the recovery of an entire LSP, from A span is synonymous with a link.
its ingress to its egress node.
3.51. Transport Entity: 3.40. Sublayer:
Sublayer is defined in [ITU-T_G.805]. The distinction between a
layer network and a sublayer is that a sublayer is not directly
accessible to clients outside of its encapsulating layer network and
offers no direct transport service for a higher layer (client)
network.
3.41. 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.52. Working Entity: 3.41.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.53. Protection Entity: 3.41.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 used to protect and transport traffic when the working entity and used to protect and transport traffic when the working entity
fails. fails.
3.54. Recovery entity: 3.41.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 transport traffic when the working entity fails. and transport traffic when the working entity fails.
3.42. Transmission media layer:
A layer network, consisting of a section layer network and a
physical layer network as defined in [ITU-T_G.805], that provides
sections (two-port point-to-point connections) to carry the
aggregate of network-transport path or network-service layers on
various physical media.
3.43. 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.44. Transport path:
A network connection as defined in [ITU-T_G.805]. In an MPLS-TP
environment a transport path corresponds to an LSP or a PW.
3.45. Transport path layer:
A (sub)layer network that provides point-to-point or point-to-
multipoint transport paths. It provides OAM that is independent of
the clients that it is transporting.
3.46. Transport service layer:
A layer network in which transport paths are used to carry a
customer's (individual or bundled) service (may be point-to-point,
point-to-multipoint or multipoint-to-multipoint services).
3.47. Unidirectional path:
A Unidirectional Path is a path that supports traffic flow in only
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 the context of the ITU-T's Transport Network architecture. into the context of the ITU-T's Transport Network architecture.
Thus, it should help those familiar with MPLS to see how they may Thus, it should help those familiar with MPLS to see how they may
use the features and functions of the Transport Network in order to use the features and functions of the Transport Network in order to
meet the requirements of MPLS-TP. meet the requirements of MPLS-TP.
This lexicography should not be used in order to obtain or derive This lexicography should not be used in order to obtain or derive
definitive definitions of GMPLS terms. To obtain definitions of definitive definitions of GMPLS terms. To obtain definitions of
GMPLS terms that are applicable across all GMPLS architectural GMPLS terms that are applicable across all GMPLS architectural
models, the reader should refer to the RFCs listed in the references models, the reader should refer to the RFCs listed in the references
sections of this document. [RFC3945] provides an overview of the sections of this document. [RFC3945] provides an overview of the
GMPLS architecture and should be read first. GMPLS architecture and should be read first.
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 described in [RFC5654], [RFC5860], [RFC5921],
control and monitoring, as well as Operations and Management (OAM) [RFC5951], [RFC6371], [RFC6372], [ITU-T G.8110.1] and [ITU-T
functionality. G.7710], include considerable efforts to provide operator control
and monitoring, as well as Operations, Administration and
Maintenance (OAM) functionality.
These concepts are, however, out of scope of this document. These concepts are, however, out of scope of this document.
6. Security Considerations 6. Security Considerations
Security is a significant requirement of MPLS-TP. Security is a significant requirement of MPLS-TP. See for more
information [SECURITY].
However, this informational document is intended only to provide a However, this informational document is intended only to provide
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
There are no IANA actions resulting from this document. There are no IANA actions resulting from this document.
8. Acknowledgments 8. 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 IETF and the
MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and MPLS-TP 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
[RFC6371] Busi, I., Allan, D., "Operations, Administration, and [RFC3031] E. Rosen, et al., "Requirements of an MPLS Transport
Maintenance Framework for MPLS-Based Transport Networks", Profile", January 2001.
September 2011
[RFC6372] Sprecher, N., Farrel, A., "MPLS Transport Profile (MPLS-
TP) Survivability Framework", September 2011
[RFC5654] B. Niven-Jenkins, et al., "Requirements of an MPLS [RFC5654] B. Niven-Jenkins, et al., "Requirements of an MPLS
Transport Profile", September 2009 Transport Profile", September 2009.
[RFC5921] Bocci, M., Bryant, S., Levrau, L., "A Framework for MPLS
in Transport Networks", July 2010
[RFC5860] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM [RFC5860] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM
in MPLS Transport Networks", May 2010 in MPLS Transport Networks", May 2010.
[RFC5921] Bocci, M., Bryant, S., Levrau, L., "A Framework for MPLS
in Transport Networks", July 2010.
[RFC5951] Gray, E., Mansfield, S., et al., "MPLS TP Network [RFC5951] Gray, E., Mansfield, S., et al., "MPLS TP Network
Management Requirements", September 2010 Management Requirements", September 2010.
[RFC3031] E. Rosen, et al., "Requirements of an MPLS Transport [RFC6371] Busi, I., Allan, D., "Operations, Administration, and
Profile", January 2001 Maintenance Framework for MPLS-Based Transport Networks",
September 2011.
[RFC6372] Sprecher, N., Farrel, A., "MPLS Transport Profile (MPLS-
TP) Survivability Framework", September 2011.
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
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
functional architecture of transport networks." functional architecture of transport networks."
[ITU-T_G.806] ITU-T Recommendation G.806 (03/2006), "Characteristics [ITU-T_G.806] ITU-T Recommendation G.806 (03/2006), "Characteristics
of transport equipment - Description methodology and of transport equipment - Description methodology and
generic functionality." generic functionality."
[ITU-T_G.872] ITU-T Recommendation G.872 (11/2001), "Architecture of [ITU-T_G.872] ITU-T Recommendation G.872 (11/2001), "Architecture of
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_G.8101] ITU-T Recommendation G.8101/Y.1355 (12/2006), "Terms
and definitions for transport MPLS."
[ITU-T G.8110.1] ITU-T Recommendation G.8110.1/Y.1370.1 (12/2011),
"Architecture of the Multi-Protocol Label Switching
transport profile layer network."
[ITU-T G.8113.1] ITU-T Recommendation G.8113.1/Y.1372.1 (11/2012),
"Operations, Administration and Maintenance mechanism
for MPLS-TP in Packet Transport Network (PTN)."
[ITU-T G.8113.2] ITU-T Recommendation G.8113.2/Y.1372.2 (11/2012),
"Operations, administration and maintenance mechanisms
for MPLS-TP networks using the tools defined for
MPLS."
[ITU-T Y.2611] ITU-T Recommendation Y.2611 (12/2006), "High-level
architecture of future packet-based networks." architecture of future packet-based networks."
9.2. Informative References 9.2. Informative References
[RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", October 2004.
[RFC4397] I. Bryskin, A. Farrel, "A Lexicography for the [RFC4397] I. Bryskin, A. Farrel, "A Lexicography for the
Interpretation of Generalized Multiprotocol Label Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within the Context of the Switching (GMPLS) Terminology within the Context of the
ITU-T's Automatically Switched Optical Network (ASON) ITU-T's Automatically Switched Optical Network (ASON)
Architecture", February 2006 Architecture", February 2006.
[RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching [SECURITY] L. Fang, B. Niven-Jenkins, S. Mansfield, R. Graveman,
(GMPLS) Architecture", October 2004 "MPLS-TP Security Framework", draft-ietf-mpls-tp-security-
framework (work in progress).
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 Email: Huub.van.Helvoort@huawei.com
Loa Andersson (Editor) Loa Andersson (Editor)
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
Email: loa@mail01.huawei.com Email: loa@mail01.huawei.com
 End of changes. 115 change blocks. 
351 lines changed or deleted 436 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/