--- 1/draft-ietf-mpls-tp-rosetta-stone-04.txt 2012-01-17 13:13:55.778672876 +0100 +++ 2/draft-ietf-mpls-tp-rosetta-stone-05.txt 2012-01-17 13:13:55.814671073 +0100 @@ -1,25 +1,25 @@ MPLS Working Group H. van Helvoort (Ed) Internet Draft Huawei Technologies Intended status: Informational -Expires: December 2011 L. Andersson (Ed) +Expires: July 2012July L. Andersson (Ed) Ericsson N. Sprecher (Ed) Nokia Siemens Networks - June 2, 2011 + 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-04 + 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. @@ -28,21 +28,21 @@ 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 December 1, 2011. + 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 @@ -78,68 +78,67 @@ 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: 7 + 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: 8 + 3.11. MPLS-TP Physical Ring: 7 3.12. MPLS-TP Ring Topology: 8 3.13. Path: 8 3.14. Section Layer Network: 8 3.15. Segment: 8 - 3.16. Server layer: 9 + 3.16. Server layer: 8 3.17. Span: 9 3.18. Sublayer: 9 3.19. Tandem Connection: 9 - 3.20. Transport path: 10 - 3.21. Transport path layer: 10 - 3.22. Transport service layer: 10 - 3.23. Transmission media layer: 10 - 3.24. Unidirectional path: 10 - 3.25. Failure: 10 - 3.26. Fault: 10 - 3.27. Defect: 11 - 3.28. MPLS Transport Profile (MPLS-TP): 11 - 3.29. MPLS Section: 11 - 3.30. MPLS-TP NE: 11 - 3.31. MPLS-TP network: 11 - 3.32. Equipment Management Function (EMF): 11 - 3.33. Data Communication Network (DCN): 11 - 3.34. Communication Channel (CC): 11 - 3.35. Embedded Communication Channel (ECC): 12 - 3.36. Management Communication Channel (MCC): 12 - 3.37. Management Communication Network (MCN): 12 - 3.38. Signaling Communication Channel (SCC): 12 - 3.39. Signaling Communication Network (SCN): 12 - 3.40. Operations System (OS): 12 - 3.41. Maintenance Entity 12 - 3.42. Maintenance End Points (MEPs) 13 - 3.43. Maintenance Intermediate Points (MIPs) 14 - 3.44. Server MEPs 14 + 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 19 + 7. IANA Considerations 18 8. Acknowledgments 19 9. References 19 9.1. Normative References 19 - 9.2. Informative References 20 - Authors' Addresses 20 - Contributing Authors' Addresses 21 + 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. The ITU-T has specified a Transport Network architecture for the transfer of signals from different technologies. This architecture @@ -178,22 +177,22 @@ ME Maintenance Entity MEG ME Group MEP MEG End Point MIP MEG Intermediate Point MPLS Multiprotocol Label Switching - MPLS-TP MPLS Transport Profile + MPLS-TP MPLS Transport Profile NE Network Element OAM Operations, Administration and Maintenance O&M OAM and Management SCC Signaling Communication Channel SCN Signaling Communication Network @@ -219,21 +218,21 @@ [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] + [editor: from [RFC5654] mpls-tp-requirements == complete] 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. @@ -431,21 +430,21 @@ 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]] + [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]. @@ -466,21 +465,21 @@ 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]] + [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): @@ -531,32 +530,35 @@ 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: draft-busi-mpls-tp-oam-framework-00 [1]] + [editor: from: OAM Framework RFC [RFC6371] == complete] - [editor: OAM flow: to be added in future revision of this document.] +3.42. OAM flow: -3.42. Maintenance Entity + 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 managed in order to bound the OAM responsibilities of an OAM flow - [editor: definition?] across a network or sub-network, i.e. a - transport path or segment, in the specific layer network that is - being monitored and managed. + 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 @@ -564,21 +566,21 @@ 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.43. Maintenance End Points (MEPs) +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. @@ -588,30 +590,30 @@ 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. -3.44. Maintenance Intermediate Points (MIPs) +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.45. Server MEPs +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] @@ -622,21 +624,47 @@ . 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 draft-ietf-mpls-tp-survive-fwk [2]] + [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. + + 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 @@ -682,67 +710,47 @@ 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.33 access point - 3.34 adaptation - 3.35 adapted information - - 3.36 characteristic information - - 3.37 client/server relationship - - 3.50 network - - 3.52 port - - 3.53 reference point + 3.37 client/server relationship (relationship between layer + networks) 3.56 traffic unit - 3.57 transport - - 3.58 transport entity - 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 - - 3.62 client/server (relationship between layer networks) - - 3.63 failure - - 3.64 forward direction - 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 @@ -839,25 +847,26 @@ 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 - [1] Busi, I., Niven-Jenkins, B., et al., "MPLS-TP OAM Framework - and Overview", draft-ietf-mpls-tp-oam-framework-01, july 2009 + [RFC6371] Busi, I., Allan, D., "Operations, Administration, and + Maintenance Framework for MPLS-Based Transport Networks", + September 2011 - [2] Sprecher, N., Farrel, A., "Survivability Framework", draft- - ietf-mpls-tp-survive-fwk-06, June 2010 + [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 @@ -903,20 +912,21 @@ [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 Authors' Addresses Huub van Helvoort (Editor) Huawei Technologies Co., Ltd. - Email: huub.van.helvoort@huawei.com + 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