GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7087

Internet Engineering Task Force (IETF) H. van Helvoort, Ed. Request for Comments: 7087 L. Andersson, Ed. Category: Informational Huawei Technologies ISSN: 2070-1721 N. Sprecher, Ed.

                                          Nokia Solutions and Networks
                                                         December 2013
       A Thesaurus for the Interpretation of Terminology Used
    in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs
  in the Context of the ITU-T's Transport Network Recommendations

Abstract

 The MPLS Transport Profile (MPLS-TP) is based on a profile of the
 MPLS and Pseudowire (PW) procedures as specified in the MPLS Traffic
 Engineering (MPLS-TE), PW, and Multi-Segment Pseudowire (MS-PW)
 architectures developed by the Internet Engineering Task Force
 (IETF).  The International Telecommunication Union Telecommunication
 Standardization Sector (ITU-T) has specified a Transport Network
 architecture.
 This document provides a thesaurus for the interpretation of MPLS-TP
 terminology within the context of the ITU-T Transport Network
 Recommendations.
 It is important to note that MPLS-TP is applicable in a wider set of
 contexts than just Transport Networks.  The definitions presented in
 this document do not provide exclusive or complete interpretations of
 MPLS-TP concepts.  This document simply allows the MPLS-TP terms to
 be applied within the Transport Network context.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7087.

van Helvoort, et al. Informational [Page 1] RFC 7087 MPLS-TP Rosetta Stone December 2013

Copyright Notice

 Copyright (c) 2013 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Introduction ....................................................4
    1.1. Abbreviations ..............................................4
 2. Terminology .....................................................5
    2.1. MPLS-TP Terminology Sources ................................5
    2.2. ITU-T Transport Network Terminology Sources ................6
    2.3. Common Terminology Sources .................................6
 3. Thesaurus .......................................................6
    3.1. Associated Bidirectional Path ..............................6
    3.2. Bidirectional Path .........................................6
    3.3. Client-Layer Network .......................................6
    3.4. Communication Channel ......................................7
    3.5. Concatenated Segment .......................................7
    3.6. Control Plane ..............................................7
    3.7. Co-Routed Bidirectional Path ...............................7
    3.8. Data Communication Network (DCN) ...........................7
    3.9. Defect .....................................................8
    3.10. Domain ....................................................8
    3.11. Embedded Communication Channel (ECC) ......................8
    3.12. Equipment Management Function (EMF) .......................8
    3.13. Failure ...................................................8
    3.14. Fault .....................................................8
    3.15. Layer Network .............................................9
    3.16. Link ......................................................9
    3.17. Maintenance Entity (ME) ...................................9
    3.18. Maintenance Entity Group (MEG) ...........................10
    3.19. Maintenance Entity Group End Point (MEP) .................10
    3.20. Maintenance Entity Group Intermediate Point (MIP) ........11
    3.21. Management Communication Channel (MCC) ...................11
    3.22. Management Communication Network (MCN) ...................11

van Helvoort, et al. Informational [Page 2] RFC 7087 MPLS-TP Rosetta Stone December 2013

    3.23. Monitoring ...............................................11
         3.23.1. Path Segment Tunnel (PST) .........................11
         3.23.2. Sub-Path Maintenance Element (SPME) ...............12
         3.23.3. Tandem Connection .................................12
    3.24. MPLS Section .............................................12
    3.25. MPLS Transport Profile (MPLS-TP) .........................12
    3.26. MPLS-TP NE ...............................................13
    3.27. MPLS-TP Network ..........................................13
    3.28. MPLS-TP Recovery .........................................13
         3.28.1. End-to-End Recovery ...............................13
         3.28.2. Link Recovery .....................................13
         3.28.3. Segment Recovery ..................................13
    3.29. MPLS-TP Ring Topology ....................................13
         3.29.1. MPLS-TP Logical Ring ..............................14
         3.29.2. MPLS-TP Physical Ring .............................14
    3.30. OAM Flow .................................................14
    3.31. Operations Support System (OSS) ..........................14
    3.32. Path .....................................................14
    3.33. Protection Priority ......................................14
    3.34. Section-Layer Network ....................................14
    3.35. Segment ..................................................15
    3.36. Server Layer .............................................15
    3.37. Server MEPs ..............................................15
    3.38. Signaling Communication Channel (SCC) ....................16
    3.39. Signaling Communication Network (SCN) ....................16
    3.40. Span .....................................................16
    3.41. Sublayer .................................................16
    3.42. Transport Entity .........................................16
         3.42.1. Working Entity ....................................16
         3.42.2. Protection Entity .................................16
         3.42.3. Recovery Entity ...................................16
    3.43. Transmission Media Layer .................................17
    3.44. Transport Network ........................................17
    3.45. Transport Path ...........................................17
    3.46. Transport-Path Layer .....................................17
    3.47. Transport-Service Layer ..................................17
    3.48. Unidirectional Path ......................................17
 4. Guidance on the Application of This Thesaurus ..................18
 5. Management Considerations ......................................18
 6. Security Considerations ........................................18
 7. Acknowledgments ................................................18
 8. Contributors ...................................................18
 9. References .....................................................19
    9.1. Normative References ......................................19
    9.2. Informative References ....................................20

van Helvoort, et al. Informational [Page 3] RFC 7087 MPLS-TP Rosetta Stone December 2013

1. Introduction

 The MPLS Transport Profile (MPLS-TP) has been developed by the IETF
 to facilitate the Operations, Administration, and Maintenance (OAM)
 of Label Switched Paths (LSPs) to be used in a Transport Network
 environment as defined by the ITU-T.
 The ITU-T has specified a Transport Network architecture for the
 transfer of signals from different technologies.  This architecture
 forms the basis of many Recommendations within the ITU-T.
 Because of the difference in historic background of MPLS, and
 inherently MPLS-TP (the Internet) and the Transport Network (ITU
 Telecommunication Sector), the terminology used is different.
 This document provides a thesaurus (the analogy to the Rosetta Stone
 has been used within the working groups) for the interpretation of
 MPLS-TP terminology within the context of the ITU-T Transport Network
 Recommendations.  This allows MPLS-TP documents to be generally
 understood by those familiar with MPLS RFCs.  The definitions
 presented in this document do not provide exclusive or complete
 interpretations of the ITU-T Transport Network concepts.

1.1. Abbreviations

 CE       Customer Edge
 DCC      Data Communication Channel
 DCN      Data Communication Network
 ECC      Embedded Communication Channel
 EMF      Equipment Management Function
 EMS      Element Management System
 GAL      Generic Associated Channel Label
 LER      Label Edge Router
 LSR      Label Switching Router
 MCC      Management Communication Channel
 MCN      Management Communication Network
 ME       Maintenance Entity

van Helvoort, et al. Informational [Page 4] RFC 7087 MPLS-TP Rosetta Stone December 2013

 MEG      Maintenance Entity Group
 MEP      Maintenance Entity Group End Point
 MIP      Maintenance Entity Group Intermediate Point
 MPLS     Multiprotocol Label Switching
 MPLS-TP  MPLS Transport Profile
 MS-PW    Multi-Segment Pseudowire
 NE       Network Element
 NEF      Network Element Function
 OAM      Operations, Administration, and Maintenance
 OSS      Operations Support System
 PM       Performance Monitoring
 PST      Path Segment Tunnel
 PW       Pseudowire
 S-PE     Switching Provider Edge
 SCC      Signaling Communication Channel
 SCN      Signaling Communication Network
 SPME     Sub-Path Maintenance Element
 T-PE     Terminating Provider Edge
 TCM      Tandem Connection Monitoring

2. Terminology

 This section provides an overview regarding terminology used in this
 document.

2.1. MPLS-TP Terminology Sources

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

van Helvoort, et al. Informational [Page 5] RFC 7087 MPLS-TP Rosetta Stone December 2013

2.2. ITU-T Transport Network Terminology Sources

 The ITU-T Transport Network is specified in a number of
 Recommendations: generic functional architectures and requirements
 are specified in [ITU-T_G.805], [ITU-T_G.806], and [ITU-T_G.872].
 ITU-T Recommendation G.8101/Y.1355 [ITU-T_G.8101] contains an
 overview of the terms and definitions for transport MPLS.

2.3. Common Terminology Sources

 The work in this document builds on the shared view of MPLS
 requirements.  It is intended to provide a source for common MPLS-TP
 terminology.  In general, the original terminology is used.
 The following sources are used:
 o  IETF framework and requirements RFCs: [RFC6371], [RFC6372],
    [RFC5654], [RFC5921], [RFC5860], [RFC5951], [RFC3031], and
    [RFC4397].
 o  ITU-T architecture and requirements Recommendations:
    [ITU-T_G.8101], [ITU-T_G.805], [ITU-T_G.806], [ITU-T_G.872],
    [ITU-T_G.7710], and [ITU-T_Y.2611].

3. Thesaurus

3.1. Associated Bidirectional Path

 An associated bidirectional path is a path that supports traffic flow
 in both directions but that is constructed from a pair of
 unidirectional paths (one for each direction) that are associated
 with one another at the path's ingress/egress points.  An associated
 bidirectional path need not be a single management and operational
 entity.  The forward and backward directions are set up, monitored,
 and protected independently.  As a consequence, they may or may not
 follow the same route (links and nodes) across the network.

3.2. Bidirectional Path

 A bidirectional path refers to a path that supports traffic flow in
 two opposite directions, i.e., the forward and backward direction.

3.3. Client-Layer Network

 In a client/server relationship (see [ITU-T_G.805]), the client-layer
 network receives a (transport) service from the lower server-layer
 network (usually the layer network under consideration).

van Helvoort, et al. Informational [Page 6] RFC 7087 MPLS-TP Rosetta Stone December 2013

3.4. Communication Channel

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

3.5. Concatenated Segment

 A concatenated segment is a serial-compound link connection as
 defined in [ITU-T_G.805].  A concatenated segment is a contiguous
 part of an LSP or MS-PW that comprises a set of segments and their
 interconnecting nodes in sequence.  See also "Segment"
 (Section 3.35).

3.6. Control Plane

 Within the scope of [RFC5654], the control plane performs transport
 path control functions.  Through signaling, the control plane sets
 up, modifies, and releases transport paths and may recover a
 transport path in case of a failure.  The control plane also performs
 other functions in support of transport path control, such as routing
 information dissemination.  It is possible to operate an MPLS-TP
 network without using a control plane.

3.7. Co-Routed Bidirectional Path

 A co-routed bidirectional path is a path where the forward and
 backward directions follow the same route (links and nodes) across
 the network.  A co-routed bidirectional path is managed and operated
 as a single entity.  Both directions are set up, monitored, and
 protected as a single entity.  A Transport Network path is typically
 co-routed.

3.8. Data Communication Network (DCN)

 A DCN is a network that supports Layer 1 (physical layer), Layer 2
 (data-link layer), and Layer 3 (network layer) functionality for
 distributed management communications related to the management
 plane, for distributed routing and signaling communications related
 to the control plane, and for other operations communications (e.g.,
 order-wire/voice communications, software downloads, etc.).

van Helvoort, et al. Informational [Page 7] RFC 7087 MPLS-TP Rosetta Stone December 2013

3.9. Defect

 "Defect" refers to the situation for which the density of anomalies
 has reached a level where the ability to perform a required function
 has been interrupted.  Defects are used as input for Performance
 Monitoring (PM), the control of consequent actions, and the
 determination of fault cause.  See also [ITU-T_G.806].

3.10. Domain

 A domain represents a collection of entities (for example, network
 elements) that are grouped for a particular purpose, examples of
 which are administrative and/or managerial responsibilities, trust
 relationships, addressing schemes, infrastructure capabilities,
 aggregation, survivability techniques, distributions of control
 functionality, etc.  Examples of such domains include IGP areas and
 Autonomous Systems.

3.11. Embedded Communication Channel (ECC)

 An ECC is a logical operations channel between network elements (NEs)
 that can be utilized by multiple applications (e.g., management-plane
 applications, control-plane applications, etc.).  The physical
 channel supporting the ECC is technology specific.  An example of a
 physical channel supporting the ECC is a Data Communication Channel
 (DCC) within the Synchronous Digital Hierarchy (SDH).

3.12. Equipment Management Function (EMF)

 The equipment management function (EMF) provides the means through
 which an element management system (EMS) and other managing entities
 manage the network element function (NEF).  See [ITU-T_G.7710].

3.13. Failure

 A failure is a detected fault.  A failure will be declared when the
 fault cause persisted long enough to consider that a required
 transport function cannot be performed.  The item may be considered
 as failed; a fault has now been detected.  See also [ITU-T_G.806].  A
 failure can be used as a trigger for corrective actions.

3.14. Fault

 A fault is the inability of a transport function to perform a
 required action.  This does not include an inability due to
 preventive maintenance, lack of external resources, or planned
 actions.  See also [ITU-T_G.806].

van Helvoort, et al. Informational [Page 8] RFC 7087 MPLS-TP Rosetta Stone December 2013

3.15. Layer Network

 "Layer network" is defined in [ITU-T_G.805].  A layer network
 provides for the transfer of client information and independent
 operation of the client OAM.  A layer network may be described in a
 service context as follows: one layer network may provide a
 (transport) service to a higher client-layer network and may, in
 turn, be a client to a lower-layer network.  A layer network is a
 logical construction somewhat independent of arrangement or
 composition of physical network elements.  A particular physical
 network element may topologically belong to more than one layer
 network, depending on the actions it takes on the encapsulation
 associated with the logical layers (e.g., the label stack) and thus
 could be modeled as multiple logical elements.  A layer network may
 consist of one or more sublayers.  For additional explanation of how
 layer networks relate to the OSI concept of layering, see Appendix I
 of [ITU-T_Y.2611].

3.16. Link

 A link as discussed in this document refers to a physical or logical
 connection between a pair of Label Switching Routers (LSRs) that are
 adjacent at the (sub)layer network under consideration.  A link may
 carry zero, one, or more LSPs or PWs.  A packet entering a link will
 emerge with the same label-stack entry values.
 A link as defined in [ITU-T_G.805] is used to describe a fixed
 relationship between two ports.

3.17. Maintenance Entity (ME)

 A Maintenance Entity (ME) can be viewed as the association of two (or
 more) Maintenance Entity Group End Points (MEPs) that should be
 configured and managed in order to bound the OAM responsibilities of
 an OAM flow across a network or sub-network, i.e., a transport path
 or segment in the specific layer network that is being monitored and
 managed.  See also Section 3.1 of [RFC6371] and Clause 6.1 of
 [ITU-T_G.8113.1] and [ITU-T_G.8113.2].
 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 an MPLS-TP LSP ME or PW ME, Label Edge
 Routers (LERs) and PW Terminating Provider Edges (T-PEs) can be MEPs,
 while LSRs and PW Switching Provider Edges (S-PEs) can be MIPs.  In
 the case of an ME for a tandem connection, LSRs and S-PEs can be
 either MEPs or MIPs.

van Helvoort, et al. Informational [Page 9] RFC 7087 MPLS-TP Rosetta Stone December 2013

 The following properties apply to all MPLS-TP MEs:
  1. OAM entities can be nested but not overlapped.
  1. Each OAM flow is associated with a unique Maintenance Entity.
  1. OAM packets are subject to the same forwarding treatment as the

data traffic, but they are distinct from the data traffic by the

    Generic Associated Channel Label (GAL).

3.18. Maintenance Entity Group (MEG)

 A Maintenance Entity Group is defined, for the purpose of connection
 monitoring, between a set of connection points within a connection.
 This set of connection points may be located at the boundary of one
 administrative domain or a protection domain or the boundaries of two
 adjacent administrative domains.  The MEG may consist of one or more
 Maintenance Entities (MEs).  See also Section 3.1 of [RFC6371] and
 Clause 6.2 of [ITU-T_G.8113.1] and [ITU-T_G.8113.2].
 In an MPLS-TP layer network, a MEG consists of only one ME.

3.19. Maintenance Entity Group End Point (MEP)

 Maintenance Entity Group End Points (MEPs) are the end points of a
 pre-configured (through the management or control planes) ME.  MEPs
 are responsible for activating and controlling all of the OAM
 functionality for the ME.  A source MEP may initiate an OAM packet to
 be transferred to its corresponding peer MEP (called the sink MEP) or
 to an intermediate MIP that is part of the ME.  See also Section 3.3
 of [RFC6371] and Clause 6.3 of [ITU-T_G.8113.1] and [ITU-T_G.8113.2].
 A sink MEP terminates all the OAM packets that it receives
 corresponding to its ME and does not forward them further along the
 path.
 All OAM packets coming into a source MEP are tunneled via label
 stacking and are not processed within the ME as they belong either to
 the client network layers or to a higher Tandem Connection Monitoring
 (TCM) level.
 A MEP in a tandem connection is not coincident with the termination
 of the MPLS-TP transport path (LSP or PW), though it can monitor its
 connectivity (e.g., counts packets).  A MEP of an MPLS-TP network
 transport path is coincident with transport path termination and
 monitors its connectivity (e.g., counts packets).

van Helvoort, et al. Informational [Page 10] RFC 7087 MPLS-TP Rosetta Stone December 2013

 An MPLS-TP sink MEP can notify a fault condition to its MPLS-TP
 client-layer network.

3.20. Maintenance Entity Group Intermediate Point (MIP)

 A Maintenance Entity Group Intermediate Point (MIP) is a point
 between the two MEPs in an ME and is capable of responding to some
 OAM packets and forwarding all OAM packets while ensuring fate
 sharing with data-plane packets.  A MIP responds only to OAM packets
 that are sent on the ME it belongs to and that are addressed to the
 MIP; it does not initiate OAM messages.  See also Section 3.4 of
 [RFC6371] and Clause 6.4 of [ITU-T_G.8113.1] and [ITU-T_G.8113.2].

3.21. Management Communication Channel (MCC)

 A Communication Channel dedicated to management-plane communications
 is referred to as a Management Communication Channel (MCC).

3.22. Management Communication Network (MCN)

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

3.23. Monitoring

 Monitoring is applying OAM functionality to verify and to maintain
 the performance and the quality guarantees of a transport path.
 There is a need to not only monitor the whole transport path (e.g.,
 LSP or MS-PW), but also arbitrary parts of transport paths.  The
 connection between any two arbitrary points along a transport path is
 described in one of three ways:
  1. as a Path Segment Tunnel,
  1. as a Sub-Path Maintenance Element, or
  1. as a Tandem Connection.

3.23.1. Path Segment Tunnel (PST)

 A path segment is either a segment or a concatenated segment.  Path
 Segment Tunnels (PSTs) are instantiated to provide monitoring of a
 portion of a set of co-routed transport paths (LSPs or MS-PWs).  PSTs
 can also be employed to meet the requirement to provide Tandem
 Connection Monitoring.  See "Tandem Connection" (Section 3.23.3).

van Helvoort, et al. Informational [Page 11] RFC 7087 MPLS-TP Rosetta Stone December 2013

3.23.2. Sub-Path Maintenance Element (SPME)

 To monitor, protect, and manage a portion (i.e., segment or
 concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be
 instantiated.  A hierarchical LSP instantiated for this purpose is
 called a Sub-Path Maintenance Element (SPME).  Note that by
 definition, an SPME does not carry user traffic as a direct client.
 An SPME is defined between the edges of the portion of the LSP that
 needs to be monitored, protected, or managed.  The SPME forms an
 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 an SPME.  In this mode, it is an LER for the SPME.

3.23.3. Tandem Connection

 A tandem connection is an arbitrary part of a transport path that can
 be monitored (via OAM) independently from the end-to-end monitoring
 (OAM).  It may be a monitored segment, a monitored concatenated
 segment, or any other monitored ordered sequence of contiguous hops
 and/or segments (and their interconnecting nodes) of a transport
 path.
 Tandem Connection Monitoring (TCM) for a given path segment of a
 transport path is implemented by creating a Path Segment Tunnel that
 has a 1:1 association with the path segment of the transport path
 that is to be uniquely monitored.  This means that the PST used to
 provide TCM can carry one and only one transport path, thus allowing
 direct correlation between all fault-management and performance-
 monitoring information gathered for the PST and the monitored path
 segment of the end-to-end transport path.  The PST is monitored using
 normal LSP monitoring.  See also Section 3.2 of [RFC6371] and
 Clause 6.2.1 of [ITU-T_G.8113.1] and [ITU-T_G.8113.2].

3.24. MPLS Section

 An MPLS Section is a network segment between two LSRs that are
 immediately adjacent at the MPLS layer.

3.25. MPLS Transport Profile (MPLS-TP)

 An MPLS Transport Profile refers to the set of MPLS functions used to
 support packet transport services and network operations.

van Helvoort, et al. Informational [Page 12] RFC 7087 MPLS-TP Rosetta Stone December 2013

3.26. MPLS-TP NE

 A network element (NE) that supports MPLS-TP functions is referred to
 as an MPLS-TP NE.

3.27. MPLS-TP Network

 An MPLS-TP network is a network in which MPLS-TP NEs are deployed.

3.28. MPLS-TP Recovery

3.28.1. End-to-End Recovery

 MPLS-TP end-to-end recovery refers to the recovery of an entire LSP,
 from its ingress to its egress node.

3.28.2. Link Recovery

 MPLS-TP link recovery refers to the recovery of an individual link
 (and hence all or a subset of the LSPs routed over the link) between
 two MPLS-TP nodes.  For example, link recovery may be provided by
 server-layer recovery.

3.28.3. Segment Recovery

 MPLS-TP segment recovery refers to the recovery of an LSP segment
 (i.e., segment and concatenated segment) between two nodes and is
 used to recover from the failure of one or more links or nodes.
 An LSP segment comprises one or more contiguous hops on the path of
 the LSP.  [RFC5654] defines two terms: a "segment" is a single hop
 along the path of an LSP, while a "concatenated segment" is more than
 one hop along the path of an LSP.

3.29. MPLS-TP Ring Topology

 In an MPLS-TP ring topology, each LSR is connected to exactly two
 other LSRs, each via a single point-to-point bidirectional MPLS-TP
 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.

van Helvoort, et al. Informational [Page 13] RFC 7087 MPLS-TP Rosetta Stone December 2013

3.29.1. MPLS-TP Logical Ring

 An MPLS-TP logical ring is constructed from a set of LSRs and logical
 data links (such as MPLS-TP LSP tunnels or MPLS-TP pseudowires) and
 physical data links that form a ring topology.

3.29.2. MPLS-TP Physical Ring

 An MPLS-TP physical ring is constructed from a set of LSRs and
 physical data links that form a ring topology.

3.30. OAM Flow

 An OAM flow is the set of all OAM packets originating with a specific
 source MEP that measure the performance of one direction of a MEG (or
 possibly both in the special case of data-plane loopback).

3.31. Operations Support System (OSS)

 An OSS is a system that performs the functions that support
 processing of information related to Operations, Administration,
 Maintenance, and Provisioning (OAM&P) for the networks, including
 surveillance and testing functions to support customer access
 maintenance.

3.32. Path

 See "Transport Path" (Section 3.45).

3.33. Protection Priority

 Fault conditions (e.g., signal failed), external commands (e.g,
 forced switch, manual switch), and protection states (e.g., no
 request) are defined to have a relative priority with respect to each
 other.  Priority is applied to these conditions/command/states
 locally at each end point and between the two end points.

3.34. Section-Layer Network

 A section layer is a server layer (which may be MPLS-TP or a
 different technology) that provides for the transfer of the section-
 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.

van Helvoort, et al. Informational [Page 14] RFC 7087 MPLS-TP Rosetta Stone December 2013

 Section-layer networks are concerned with all the functions that
 provide for the transfer of information between locations in path-
 layer networks.
 Physical-media-layer networks are concerned with the actual fibers,
 metallic wires, or radio frequency channels that support a section-
 layer network.

3.35. Segment

 A segment is a link connection as defined in [ITU-T_G.805].  A
 segment is the part of an LSP that traverses a single link or the
 part of a PW that traverses a single link (i.e., that connects a pair
 of adjacent S-PEs and/or T-PEs).  See also "Concatenated Segment"
 (Section 3.5).

3.36. Server Layer

 A server layer is a layer network in which transport paths are used
 to carry a customer's (individual or bundled) service (may be point-
 to-point, point-to-multipoint, or multipoint-to-multipoint services).
 In a client/server relationship (see [ITU-T_G.805]), the server-layer
 network provides a (transport) service to the higher client-layer
 network (usually the layer network under consideration).

3.37. Server MEPs

 A server MEP is a MEP of an ME that is defined in a layer network
 below the MPLS-TP layer network being referenced.  A server MEP
 coincides with either a MIP or a MEP in the client-layer (MPLS-TP)
 network.  See also Section 3.5 of [RFC6371] and Clause 6.5 of
 [ITU-T_G.8113.1].
 For example, a server MEP can be one of the following:
 o  A termination point of a physical link (e.g., IEEE 802.3), an SDH
    Virtual Circuit (VC), or OTN Optical Data Unit (ODU) for the
    MPLS-TP Section layer network, defined in [RFC6371], Section 4.1;
 o  An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [RFC6371],
    Section 4.2;
 o  An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [RFC6371],
    Section 4.3; or
 o  An MPLS-TP TCM MEP for higher-level TCMs, defined in [RFC6371],
    Section 3.2.

van Helvoort, et al. Informational [Page 15] RFC 7087 MPLS-TP Rosetta Stone December 2013

 The server MEP can run appropriate OAM functions for fault detection
 and notifies a fault indication to the MPLS-TP layer network.

3.38. Signaling Communication Channel (SCC)

 A Signaling Communication Channel is a Communication Channel
 dedicated to control-plane communications.  The SCC may be used for
 GMPLS / Automatically Switched Optical Network (ASON) signaling
 and/or other control-plane messages (e.g., routing messages).

3.39. Signaling Communication Network (SCN)

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

3.40. Span

 A span is synonymous with a link.

3.41. Sublayer

 "Sublayer" is defined in [ITU-T_G.805].  The distinction between a
 layer network and a sublayer is that a sublayer is not directly
 accessible to clients outside of its encapsulating layer network and
 offers no direct transport service for a higher-layer (client)
 network.

3.42. Transport Entity

 A transport entity is a node, link, transport path segment,
 concatenated transport path segment, or entire transport path.

3.42.1. Working Entity

 A working entity is a transport entity that carries traffic during
 normal network operation.

3.42.2. Protection Entity

 A protection entity is a transport entity that is pre-allocated and
 used to protect and transport traffic when the working entity fails.

3.42.3. Recovery Entity

 A recovery entity is a transport entity that is used to recover and
 transport traffic when the working entity fails.

van Helvoort, et al. Informational [Page 16] RFC 7087 MPLS-TP Rosetta Stone December 2013

3.43. Transmission Media Layer

 A transmission media layer is a layer network, consisting of a
 section-layer network and a physical-layer network as defined in
 [ITU-T_G.805], that provides sections (two-port point-to-point
 connections) to carry the aggregate of network-transport path or
 network-service layers on various physical media.

3.44. Transport Network

 A Transport Network provides transmission of traffic between attached
 client devices by establishing and maintaining point-to-point or
 point-to-multipoint connections between such devices.  A Transport
 Network is independent of any higher-layer network that may exist
 between clients, except to the extent required to supply this
 transmission service.  In addition to client traffic, a Transport
 Network may carry traffic to facilitate its own operation, such as
 that required to support connection control, network management, and
 OAM functions.

3.45. Transport Path

 A transport path is a network connection as defined in [ITU-T_G.805].
 In an MPLS-TP environment, a transport path corresponds to an LSP or
 a PW.

3.46. Transport-Path Layer

 A transport-path layer is 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.47. Transport-Service Layer

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

3.48. Unidirectional Path

 A unidirectional path is a path that supports traffic flow in only
 one direction.

van Helvoort, et al. Informational [Page 17] RFC 7087 MPLS-TP Rosetta Stone December 2013

4. Guidance on the Application of This Thesaurus

 As discussed in the introduction to this document, this thesaurus is
 intended to bring the concepts and terms associated with MPLS-TP into
 the context of the ITU-T's Transport Network architecture.  Thus, it
 should help those familiar with MPLS to see how they may use the
 features and functions of the Transport Network in order to meet the
 requirements of MPLS-TP.

5. Management Considerations

 Networks based on MPLS-TP require management.  The MPLS-TP
 specifications described in [RFC5654], [RFC5860], [RFC5921],
 [RFC5951], [RFC6371], [RFC6372], [ITU-T_G.8110.1], and [ITU-T_G.7710]
 include considerable efforts to provide operator control and
 monitoring as well as OAM functionality.
 These concepts are, however, out of the scope of this document.

6. Security Considerations

 Security is a significant requirement of MPLS-TP.  See [RFC6941] for
 more information.
 However, this informational document is intended only to provide a
 lexicography, and the security concerns are, therefore, out of the
 scope of this document.

7. Acknowledgments

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

8. Contributors

 The following individuals contributed to this document: Italo Busi,
 Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven Levrau, Dinesh
 Mohan, Stewart Bryant, Dan Frost, Matthew Bocci, Vincenzo Sestito,
 Martin Vigoureux, and Yaacov Weingarten.

van Helvoort, et al. Informational [Page 18] RFC 7087 MPLS-TP Rosetta Stone December 2013

9. References

9.1. Normative References

 [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
            Label Switching Architecture", RFC 3031, January 2001.
 [RFC5654]  Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
            Sprecher, N., and S. Ueno, "Requirements of an MPLS
            Transport Profile", RFC 5654, September 2009.
 [RFC5860]  Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
            "Requirements for Operations, Administration, and
            Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
            May 2010.
 [RFC5921]  Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
            L., and L. Berger, "A Framework for MPLS in Transport
            Networks", RFC 5921, July 2010.
 [RFC5951]  Lam, K., Mansfield, S., and E. Gray, "Network Management
            Requirements for MPLS-based Transport Networks", RFC 5951,
            September 2010.
 [RFC6371]  Busi, I., Ed., and D. Allan, Ed., "Operations,
            Administration, and Maintenance Framework for MPLS-Based
            Transport Networks", RFC 6371, September 2011.
 [RFC6372]  Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport
            Profile (MPLS-TP) Survivability Framework", RFC 6372,
            September 2011.
 [ITU-T_G.805]
            ITU-T Recommendation G.805, "Generic functional
            architecture of transport networks", March 2000,
            <http://www.itu.int/rec/T-REC/>.
 [ITU-T_G.806]
            ITU-T Recommendation G.806, "Characteristics of transport
            equipment - Description methodology and generic
            functionality", March 2006,
            <http://www.itu.int/rec/T-REC/>.
 [ITU-T_G.872]
            ITU-T Recommendation G.872, "Architecture of optical
            transport networks", November 2001,
            <http://www.itu.int/rec/T-REC/>.

van Helvoort, et al. Informational [Page 19] RFC 7087 MPLS-TP Rosetta Stone December 2013

 [ITU-T_G.7710]
            ITU-T Recommendation G.7710, "Common equipment management
            function requirements", July 2007,
            <http://www.itu.int/rec/T-REC/>.
 [ITU-T_G.8101]
            ITU-T Recommendation G.8101/Y.1355, "Terms and definitions
            for MPLS Transport Profile", September 2013,
            <http://www.itu.int/rec/T-REC/>.
 [ITU-T_G.8110.1]
            ITU-T Recommendation G.8110.1/Y.1370.1, "Architecture of
            the Multi-Protocol Label Switching transport profile layer
            network", December 2011, <http://www.itu.int/rec/T-REC/>.
 [ITU-T_G.8113.1]
            ITU-T Recommendation G.8113.1/Y.1372.1, "Operations,
            administration and maintenance mechanism for MPLS-TP in
            packet transport network (PTN)", November 2012,
            <http://www.itu.int/rec/T-REC/>.
 [ITU-T_G.8113.2]
            ITU-T Recommendation G.8113.2/Y.1372.2, "Operations,
            administration and maintenance mechanisms for MPLS-TP
            networks using the tools defined for MPLS", November 2012,
            <http://www.itu.int/rec/T-REC/>.
 [ITU-T_Y.2611]
            ITU-T Recommendation Y.2611, "High-level architecture of
            future packet-based networks", December 2006,
            <http://www.itu.int/rec/T-REC/>.

9.2. Informative References

 [RFC4397]  Bryskin, I. and 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", RFC 4397, February 2006.
 [RFC6941]  Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed.,
            and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP)
            Security Framework", RFC 6941, April 2013.

van Helvoort, et al. Informational [Page 20] RFC 7087 MPLS-TP Rosetta Stone December 2013

Authors' Addresses

 Huub van Helvoort (editor)
 Huawei Technologies Co., Ltd.
 EMail: Huub.van.Helvoort@huawei.com
 Loa Andersson (editor)
 Huawei Technologies Co., Ltd.
 EMail: loa@mail01.huawei.com
 Nurit Sprecher (editor)
 Nokia Solutions and Networks
 EMail: nurit.sprecher@nsn.com

van Helvoort, et al. Informational [Page 21]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7087.txt · Last modified: 2013/12/16 23:30 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki