MPLS Working Group H. van Helvoort (Ed) Internet Draft Huawei Technologies Intended status: Informational Expires: July 2012July L. Andersson (Ed) Ericsson N. Sprecher (Ed) Nokia Siemens Networks January 17, 2012 A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations. draft-ietf-mpls-tp-rosetta-stone-05 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 2012. Copyright Notice Copyright (c) 2010 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 van Helvoort et al. Expires July 2012 [Page 1] Internet-Draft MPLS-TP Rosetta Stone January 2012 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. Abstract MPLS-TP is based on a profile of the MPLS and PW procedures as specified in the MPLS-TE and (MS-)PW architectures developed by the IETF. The ITU-T has specified a Transport Network architecture. This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network recommendations. It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive nor complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context. Table of Contents 1. Introduction 3 1.1. Contributing Authors 4 1.2. Abbreviations 4 SCC Signaling Communication Channel 5 2. Terminology 5 2.1. MPLS-TP Terminology Sources 5 2.2. ITU-T Transport Network Terminology Sources 5 2.3. Common Terminology Sources 5 3. Thesaurus 5 3.1. Associated bidirectional path: 6 3.2. Bidirectional path: 6 3.3. Client layer network: 6 3.4. Concatenated Segment: 6 3.5. Control Plane: 6 3.6. Co-routed bidirectional path: 6 3.7. Domain: 6 3.8. Layer network: 7 3.9. Link: 7 3.10. MPLS-TP Logical Ring: 7 3.11. MPLS-TP Physical Ring: 7 3.12. MPLS-TP Ring Topology: 8 3.13. Path: 8 3.14. Section Layer Network: 8 van Helvoort et al. Expires July 2012 [Page 2] Internet-Draft MPLS-TP Rosetta Stone January 2012 3.15. Segment: 8 3.16. Server layer: 8 3.17. Span: 9 3.18. Sublayer: 9 3.19. Tandem Connection: 9 3.20. Transport Network: 9 3.21. Transport path: 9 3.22. Transport path layer: 10 3.23. Transport service layer: 10 3.24. Transmission media layer: 10 3.25. Unidirectional path: 10 3.26. Failure: 10 3.27. Fault: 10 3.28. Defect: 10 3.29. MPLS Transport Profile (MPLS-TP): 11 3.30. MPLS Section: 11 3.31. MPLS-TP NE: 11 3.32. MPLS-TP network: 11 3.33. Equipment Management Function (EMF): 11 3.34. Data Communication Network (DCN): 11 3.35. Communication Channel (CC): 11 3.36. Embedded Communication Channel (ECC): 11 3.37. Management Communication Channel (MCC): 12 3.38. Management Communication Network (MCN): 12 3.39. Signaling Communication Channel (SCC): 12 3.40. Signaling Communication Network (SCN): 12 3.41. Operations System (OS): 12 3.42. Maintenance Entity 12 3.43. Maintenance End Points (MEPs) 13 3.44. Maintenance Intermediate Points (MIPs) 13 3.45. Server MEPs 14 4. Guidance on the Application of this Thesaurus 18 5. Management Considerations 18 6. Security Considerations 18 7. IANA Considerations 18 8. Acknowledgments 19 9. References 19 9.1. Normative References 19 9.2. Informative References 19 1. Introduction Multiprotocol Label Switching - Transport Profile (MPLS-TP) has been developed by the IETF to facilitate the Operation, Administration and Management of Label Switched Paths (LSPs) in a Transport Network environment as defined by the ITU-T. van Helvoort et al. Expires July 2012 [Page 3] Internet-Draft MPLS-TP Rosetta Stone January 2012 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 for the interpretation of ITU-T Transport Network terminology within the context of the MPLS-TP. This allows MPLS-TP documents to be generally understood by those familiar with MPLS RFCs. The definitions presented in this document do not provide exclusive or complete interpretations of the ITU-T Transport Network concepts. 1.1. Contributing Authors Italo Busi, Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven Levrau, Dinesh Mohan, Stuart Bryant, Dan Frost, Matthew Bocci, Vincenzo Sestito, Vigoureux, Yaacov Weingarten 1.2. Abbreviations CC Communications Channel DCN Data Communication Network ECC Embedded Communication Channel EMF Equipment Management Function MCC Management Communication Channel MCN Management Communication Network ME Maintenance Entity MEG ME Group MEP MEG End Point MIP MEG Intermediate Point MPLS Multiprotocol Label Switching MPLS-TP MPLS Transport Profile van Helvoort et al. Expires July 2012 [Page 4] Internet-Draft MPLS-TP Rosetta Stone January 2012 NE Network Element OAM Operations, Administration and Maintenance O&M OAM and Management SCC Signaling Communication Channel SCN Signaling Communication Network 2. Terminology Throughout this document, angle brackets ("<" and ">") are used to indicate that the term is used by both IETF and ITU-T but has a different definition. The bracketed term is the IETF term. [editor: check all terms used that this applies to, TBD] 2.1. MPLS-TP Terminology Sources MPLS-TP terminology is principally defined in [RFC3031]. Other documents provide further key definitions including [RFC4397], and [RFC....]. 2.2. ITU-T Transport Network Terminology Sources The ITU-T Transport Network is specified in a number of recommendations: generic functional architectures and requirements are specified in [ITU-T_G.805], [ITU-T_G.806], and [ITU-T_G.872]. [ITU-T_G.8101] contains an overview of the Terms and Definitions for transport MPLS. 2.3. Common Terminology Sources The work in this document builds on the shared view of MPLS requirements. 3. Thesaurus [editor: from [RFC5654] mpls-tp-requirements == complete] van Helvoort et al. Expires July 2012 [Page 5] Internet-Draft MPLS-TP Rosetta Stone January 2012 3.1. Associated bidirectional path: 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. The forward and backward directions are setup, monitored, and protected independently. As a consequence, they may or may not follow the same route (links and nodes) across the network. 3.2. Bidirectional path: A path that supports traffic flow in two opposite directions, i.e. the forward and backward direction. 3.3. Client layer network: In a client/server relationship (see [ITU-T_G.805]), the client layer network receives a (transport) service from the lower server layer network (usually the layer network under consideration). 3.4. Concatenated Segment: A serial-compound link connection as defined in [ITU-T_G.805]. A concatenated segment is a contiguous part of an LSP or multi-segment PW that comprises a set of segments and their interconnecting nodes in sequence. See also "Segment". 3.5. Control Plane: Within the scope of [RFC5654], the control plane performs transport path control functions. Through signalling, the control plane sets up, modifies and releases transport paths, and may recover a transport path in case of a failure. The control plane also performs other functions in support of transport path control, such as routing information dissemination. 3.6. Co-routed bidirectional path: A path where the forward and backward directions follow the same route (links and nodes) across the network. Both directions are setup, monitored and protected as a single entity. A transport network path is typically co-routed. van Helvoort et al. Expires July 2012 [Page 6] Internet-Draft MPLS-TP Rosetta Stone January 2012 3.7. Domain: A domain represents a collection of entities (for example network elements) that are grouped for a particular purpose, examples of which are administrative and/or managerial responsibilities, trust relationships, addressing schemes, infrastructure capabilities, aggregation, survivability techniques, distributions of control functionality, etc. Examples of such domains include IGP areas and Autonomous Systems. 3.8. Layer network: Layer network is defined in [ITU-T_G.805]. A layer network provides for the transfer of client information and independent operation of the client OAM. A layer network 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.9. Link: A physical or logical connection between a pair of LSRs that are adjacent at the (sub)layer network under consideration. A link may carry zero, one or more LSPs or PWs. A packet entering a link will emerge with the same label stack entry values. A link as defined in [ITU-T_G.805] is used to describe a fixed relationship between two ports. 3.10. MPLS-TP Logical Ring: An MPLS-TP logical ring is constructed from a set of LSRs and logical data links (such as MPLS-TP LSP tunnels or MSPL-TP pseudowires) and physical data links that form a ring topology. van Helvoort et al. Expires July 2012 [Page 7] Internet-Draft MPLS-TP Rosetta Stone January 2012 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. 3.14. Section Layer Network: A section layer is a server layer (which may be MPLS-TP or a different technology) that provides for the transfer of the section- layer client information between adjacent nodes in the transport- path layer or transport-service layer. A section layer may provide for aggregation of multiple MPLS-TP clients. Note that [ITU- T_G.805] defines the section layer as one of the two layer networks in a transmission-media layer network. The other layer network is the physical-media layer network. Section layer networks are concerned with all the functions which provide for the transfer of information between locations in path layer networks. Physical media layer networks are concerned with the actual fibres, metallic wires or radio frequency channels which support a section layer network. 3.15. Segment: A link connection as defined in [ITU-T_G.805]. A segment is the part of an LSP that traverses a single link or the part of a PW that traverses a single link (i.e., that connects a pair of adjacent {Switching|Terminating} Provider Edges). See also "Concatenated Segment". van Helvoort et al. Expires July 2012 [Page 8] Internet-Draft MPLS-TP Rosetta Stone January 2012 3.16. Server layer: A layer network in which transport paths are used to carry a customer's (individual or bundled) service (may be point-to-point, point-to-multipoint or multipoint-to-multipoint services). In a client/server relationship (see [ITU-T_G.805]). the server layer network provides a (transport) service to the higher client layer network (usually the layer network under consideration). 3.17. Span: A span is synonymous with a link. 3.18. Sublayer: Sublayer is defined in [ITU-T_G.805]. The distinction between a layer network and a sublayer is that a sublayer is not directly accessible to clients outside of its encapsulating layer network and offers no direct transport service for a higher layer (client) network. 3.19. Tandem Connection: A tandem connection is an arbitrary part of a transport path that can be monitored (via OAM) independently from the end-to-end monitoring (OAM). It may be a monitored segment, a monitored concatenated segment or any other monitored ordered sequence of contiguous hops and/or segments (and their interconnecting nodes) of a transport path. [editor: this is not in [RFC5654] but added for completeness] 3.20. Transport Network: A Transport Network provides transmission of traffic between attached client devices by establishing and maintaining point-to- point or point-to-multipoint connections between such devices. A Transport Network is independent of any higher-layer network that may exist between clients, except to the extent required to supply this transmission service. In addition to client traffic, a Transport Network may carry traffic to facilitate its own operation, such as that required to support connection control, network management, and Operations, Administration and Maintenance (OAM) functions. van Helvoort et al. Expires July 2012 [Page 9] Internet-Draft MPLS-TP Rosetta Stone January 2012 3.21. Transport path: A network connection as defined in [ITU-T_G.805]. In an MPLS-TP environment a transport path corresponds to an LSP or a PW. 3.22. 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.23. Transport service layer: A layer network in which transport paths are used to carry a customer's (individual or bundled) service (may be point-to-point, point-to-multipoint or multipoint-to-multipoint services). 3.24. Transmission media layer: A layer network, consisting of a section layer network 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.25. Unidirectional path: A path that supports traffic flow in only one direction. [editor: from: [RFC5860] == complete] 3.26. Failure: [editor: this is not in [RFC5860] but added for completeness] The fault cause persisted long enough to consider the ability of an item to perform a required function to be terminated. The item may be considered as failed; a fault has now been detected. See also [ITU-T_G.806]. 3.27. Fault: The inability of a function to perform a required action. This does not include an inability due to preventive maintenance, lack of external resources, or planned actions. See also [ITU-T_G.806]. van Helvoort et al. Expires July 2012 [Page 10] Internet-Draft MPLS-TP Rosetta Stone January 2012 3.28. Defect: The situation for which 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.29. MPLS Transport Profile (MPLS-TP): The set of MPLS functions used to support packet transport services and network operations. 3.30. MPLS Section: A network segment between two LSRs that are immediately adjacent at the MPLS layer. [editor: from: [RFC5921] and [RFC5951] == complete] 3.31. MPLS-TP NE: A network element (NE) that supports MPLS-TP functions. 3.32. MPLS-TP network: A network in which MPLS-TP NEs are deployed 3.33. Equipment Management Function (EMF): The management functions within an NE. See [ITU-T G.7710]. 3.34. Data Communication Network (DCN): A network that supports Layer 1 (physical layer), Layer 2 (data-link layer), and Layer 3 (network layer) functionality for distributed management communications related to the management plane, for distributed signaling communications related to the control plane, and other operations communications (e.g., order-wire/voice communications, software downloads, etc.). 3.35. Communication Channel (CC): A logical channel between network elements (NEs) that can be used - e.g. - for management plane application or control plane applications. The physical channel supporting the CC is technology specific. See [RFC5951] APPENDIX A van Helvoort et al. Expires July 2012 [Page 11] Internet-Draft MPLS-TP Rosetta Stone January 2012 3.36. Embedded Communication Channel (ECC): A logical operations channel between network elements (NEs) that can be utilized by multiple applications (e.g., management plane applications, control plane applications, etc.). The physical channel supporting the ECC is technology specific. An example of physical channels supporting the ECC is a DCC channel within SDH. 3.37. Management Communication Channel (MCC): A CC dedicated for management plane communications. 3.38. Management Communication Network (MCN): A DCN supporting management plane communication is referred to as a Management Communication Network (MCN). 3.39. Signaling Communication Channel (SCC): A CC dedicated for control plane communications. The SCC may be used for GMPLS/ASON signaling and/or other control plane messages (e.g., routing messages). 3.40. Signaling Communication Network (SCN): A DCN supporting control plane communication is referred to as a Signaling Communication Network (SCN). 3.41. Operations System (OS): A system that performs the functions that support processing of information related to operations, administration, maintenance, and provisioning (OAM&P) for the networks, including surveillance and testing functions to support customer access maintenance. [editor: from: OAM Framework RFC [RFC6371] == complete] 3.42. OAM flow: 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 A Maintenance Entity can be viewed as the association of two (or more) Maintenance End Points (MEPs), that should be configured and van Helvoort et al. Expires July 2012 [Page 12] Internet-Draft MPLS-TP Rosetta Stone January 2012 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. [editor: should the following be included?] Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity (defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can be MIPs. In the case of Tandem Connection Maintenance Entity (defined below), LSRs and S-PEs can be either MEPs or MIPs. The following properties apply to all MPLS-TP MEs: o OAM entities can be nested but not overlapped. o Each OAM flow is associated to a unique Maintenance Entity. o OAM packets are subject to the same forwarding treatment as the data traffic, but they are distinct from the data traffic. 3.44. Maintenance End Points (MEPs) Maintenance End Points (MEPs) are the end points of a pre-configured (through the management or control planes) ME. MEPs are responsible for activating and controlling all of the OAM functionality for the ME. A MEP may initiate an OAM packet to be transferred to its corresponding MEP, or to an intermediate MIP that is part of the ME. A MEP terminates all the OAM packets that it receives corresponding to its ME and does not forward them further along the path. All OAM packets coming to a MEP source are tunnelled via label stacking and are not processed within the ME as they belong either to the client network layers or to an higher TCM level. A MEP in a tandem connection is not coincident with the termination of the MPLS-TP transport path (LSP or PW), though it can monitor its connectivity (e.g. count packets). A MEP of an MPLS-TP network transport path is coincident with transport path termination and monitors its connectivity (e.g. count packets). MPLS-TP MEP notifies a fault indication to the MPLS-TP client layer network. van Helvoort et al. Expires July 2012 [Page 13] Internet-Draft MPLS-TP Rosetta Stone January 2012 3.45. Maintenance Intermediate Points (MIPs) A Maintenance Intermediate Point (MIP) is a point between the two MEPs in an ME and is capable of responding to some OAM packets and forwarding all OAM packets while ensuring fate sharing with data plane packets. A MIP responds only to OAM packets that are sent on the ME it belongs to and that are addressed to the MIP, it does not initiate OAM messages. 3.46. Server MEPs A server MEP is a MEP of an ME that is defined in a layer network below the MPLS-TP layer network being referenced. A server MEP coincides with either a MIP or a MEP in the client (MPLS-TP) layer network. For example, a server MEP can be either: . A termination point of a physical link (e.g. 802.3), an SDH VC or OTH ODU for the MPLS-TP Section layer network, defined in [5] section 3.1.; . An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [5] section 3.2.; . An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [5] section 3.4.; . An MPLS-TP TCM MEP for higher-level TCMs, defined in [5] sections 3.3. and 3.5. The server MEP can run appropriate OAM functions for fault detection, and notifies a fault indication to the MPLS-TP layer network. [editor: check definitions in [RFC6372] ] o 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. o Segment recovery refers to the recovery of an LSP segment (i.e., segment and concatenated segment in the language of [RFC5654]) between two nodes and is used to recover from the failure of one or more links or nodes. van Helvoort et al. Expires July 2012 [Page 14] Internet-Draft MPLS-TP Rosetta Stone January 2012 o End-to-end recovery refers to the recovery of an entire LSP, from its ingress to its egress node. o A "Transport Entity" is a node, link, transport path segment, concatenated transport path segment, or entire transport path. o A "Working Entity" is a transport entity that carries traffic during normal network operation. o A "Protection Entity" is a transport entity that is pre-allocated and used to protect and transport traffic when the working entity fails. o A "Recovery Entity" is a transport entity that is used to recover and transport traffic when the working entity fails. [editor: the following are definitions from G.8101 which should be defined only if they will cause misunderstanding. It is not usefull to define them if the definition is the same in IETF and ITU-T, TBD] ===== [ITU-T_G.8101] ===== 3.1 access point 3.2 adapted information 3.3 characteristic information 3.4 client/server relationship 3.5 connection 3.6 connection point 3.9 forward direction 3.12 link connection 3.13 matrix 3.14 network 3.15 network connection 3.16 network operator 3.17 port van Helvoort et al. Expires July 2012 [Page 15] Internet-Draft MPLS-TP Rosetta Stone January 2012 3.18 reference point 3.19 service provider 3.20 subnetwork 3.21 subnetwork connection 3.22 termination connection point 3.23 trail 3.24 trail termination 3.25 trail termination point 3.26 transport 3.27 transport entity 3.28 transport processing function 3.29 unidirectional connection 3.30 unidirectional trail 3.31 Z layer Transport MPLS (MPLS-TP) Recommendations uses the following terms defined in ITU-T Rec. G.809: 3.34 adaptation 3.37 client/server relationship (relationship between layer networks) 3.56 traffic unit Transport MPLS (MPLS-TP) Recommendations uses the following term defined in ITU-T Rec. G.8010/Y.1306: 3.59 point-to-point Ethernet connection Transport MPLS (MPLS-TP) Recommendations uses the following terms defined in [ITU-T_Y.1711]: 3.60 backward direction van Helvoort et al. Expires July 2012 [Page 16] Internet-Draft MPLS-TP Rosetta Stone January 2012 3.65 user-plane Transport MPLS (MPLS-TP) Recommendations uses the following terms defined in [ITU-T_Y.1720]: 3.66 1+1 protection 3.67 1:1 protection 3.68 bidirectional protection switching 3.69 bridge 3.71 extra traffic 3.72 failure 3.73 forced switch for working LSP 3.74 hold-off time 3.75 manual switch 3.76 MPLS protection domain 3.77 non-revertive protection switching 3.78 no request 3.79 packet 1+1 protection 3.80 path switch LSR 3.81 path merge LSR 3.82 protection LSP 3.83 protection switching 3.84 rerouting 3.85 revertive protection switching 3.86 selector 3.87 shared mesh protection van Helvoort et al. Expires July 2012 [Page 17] Internet-Draft MPLS-TP Rosetta Stone January 2012 3.88 Shared Risk Group (SRG) 3.89 sink of the protection domain 3.90 source of the protection domain 3.91 unidirectional protection switching 3.92 wait to restore 3.93 wait to restore timer 3.94 working LSP Transport MPLS (MPLS-TP) Recommendations uses the following terms defined in [ITU-T_Y.1731]: 3.95 in-service OAM ===== end of [ITU-T_G.8101] ===== 4. Guidance on the Application of this Thesaurus As discussed in the introduction to this document, this thesaurus is intended to bring the concepts and terms associated with MPLS-TP into the context of the ITU-T's Transport Network architecture. Thus, it should help those familiar with MPLS to see how they may use the features and functions of the Transport Network in order to meet the requirements of MPLS-TP. This lexicography should not be used in order to obtain or derive definitive definitions of GMPLS terms. To obtain definitions of GMPLS terms that are applicable across all GMPLS architectural models, the reader should refer to the RFCs listed in the references sections of this document. [RFC3945] provides an overview of the GMPLS architecture and should be read first. 5. Management Considerations The MPLS-TP based network requires management. The MPLS-TP specifications include considerable efforts to provide operator control and monitoring, as well as Operations and Management (OAM) functionality. These concepts are, however, out of scope of this document. van Helvoort et al. Expires July 2012 [Page 18] Internet-Draft MPLS-TP Rosetta Stone January 2012 6. Security Considerations Security is also a significant requirement of MPLS-TP. However, this informational document is intended only to provide a lexicography, and the security concerns are, therefore, out of scope. 7. IANA Considerations To be incorporated in a future revision of this document <> 8. Acknowledgments The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF and the MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and specification of MPLS Transport Profile. 9. References 9.1. Normative References [RFC6371] Busi, I., Allan, D., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", 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 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 in MPLS Transport Networks", May 2010 [RFC5951] Gray, E., Mansfield, S., et al., "MPLS TP Network Management Requirements", September 2010 [RFC3031] E. Rosen, etal., "Requirements of an MPLS Transport Profile", january 2001 van Helvoort et al. Expires July 2012 [Page 19] Internet-Draft MPLS-TP Rosetta Stone January 2012 [RFC4397] I. Bryskin, A. Farrel, "A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture", february 2006 9.2. Informative References For information on the availability of the following documents, 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 functional architecture of transport networks. [ITU-T_G.806] ITU-T Recommendation G.806 (03/2006), Characteristics of transport equipment - Description methodology and generic functionality. [ITU-T_Y.1711] ITU-T Recommendation Y.1711 (10/2005) Operation & Maintenance mechanism for MPLS networks. [ITU-T_Y.1720] ITU-T Recommendation Y.1720 (02/2008), Protection switching for MPLS networks. [ITU-T_Y.1731] ITU-T Recommendation Y.1731 (02/2008), OAM functions and mechanisms for Ethernet based networks. [ITU-T_G.872] ITU-T Recommendation G.872 (11/2001), Architecture of optical transport networks. [ITU-T G.7710] ITU-T Recommendation G.7710 (07/2007), Common equipment management function requirements [ITU-T Y.2611] ITU-T Recommendation Y.2611 (12/2006), High-level architecture of future packet-based networks van Helvoort et al. Expires July 2012 [Page 20] Internet-Draft MPLS-TP Rosetta Stone January 2012 Authors' Addresses Huub van Helvoort (Editor) Huawei Technologies Co., Ltd. Email: Huub.van.Helvoort@huawei.com Loa Andersson (Editor) Ericsson Email: loa.andersson@ericsson.com Nurit Sprecher (Editor) Nokia Siemens Networks Email: nurit.sprecher@nsn.com Contributing Authors' Addresses van Helvoort et al. Expires July 2012 [Page 21]