MPLS Working Group I. Busi (Ed) Internet Draft Alcatel-Lucent Intended status: Informational B. Niven-Jenkins (Ed) BT Expires: September 2009 March 26, 2009 MPLS-TP OAM Framework and Overview draft-ietf-mpls-tp-oam-framework-00.txt 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 Copyright Notice Copyright (c) 2009 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. Busi et al. Expires September 26, 2009 [Page 1] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 Abstract Multi-Protocol Label Switching (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), pseudowire (PW) and multi-segment PW (MS-PW) architectures complemented with additional Operations, Administration and Maintenance (OAM) procedures for fault, performance and protection-switching management for packet transport applications that do not rely on the presence of a control plane. This document provides a framework that supports a comprehensive set of OAM procedures that fulfills the MPLS-TP OAM requirements [11]. Table of Contents 1. Introduction.................................................3 1.1. Contributing Authors....................................3 2. Conventions used in this document............................3 2.1. Terminology.............................................3 2.2. Definitions.............................................4 3. Functional Components........................................5 3.1. Maintenance Entity......................................6 3.2. Maintenance End Points (MEPs)...........................7 3.3. Maintenance Intermediate Points (MIPs)..................8 3.4. Server MEPs.............................................9 4. Reference Model.............................................10 4.1. MPLS-TP Section Monitoring.............................12 4.2. MPLS-TP LSP End-to-End Monitoring......................13 4.3. MPLS-TP LSP Tandem Connection Monitoring...............14 4.4. MPLS-TP PW Monitoring..................................16 4.5. MPLS-TP MS-PW Tandem Connection Monitoring.............16 5. OAM Functions for pro-active monitoring.....................17 5.1. Continuity Check and Connectivity Verification.........17 5.1.1. Applications for proactive CC & CV function.......20 5.2. Remote Defect Indication...............................20 5.2.1. Configuration considerations......................21 5.2.2. Applications for Remote Defect Indication.........21 5.3. Alarm Suppression......................................21 5.4. Lock Indication........................................23 5.5. Packet Loss Measurement................................23 5.6. Client Signal Fail.....................................23 6. OAM Functions for on-demand monitoring......................23 6.1. Continuity Check and Connectivity Verification.........23 6.1.1. Configuration considerations......................24 6.2. Packet Loss Measurement................................24 Busi et al. Expires September 26, 2009 [Page 2] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 6.3. Diagnostic Test........................................24 6.4. Trace routing..........................................24 6.5. Packet Delay Measurement...............................25 7. OAM Protocols Overview......................................25 8. Security Considerations.....................................25 9. IANA Considerations.........................................25 10. Acknowledgments............................................25 11. References.................................................26 11.1. Normative References..................................26 11.2. Informative References................................26 1. Introduction As noted in the MPLS-TP framework [8], the overall architecture of MPLS-TP is based on a profile of the MPLS-TE and (MS-)PW architectures defined in RFC 3031 [2], RFC 3985 [5] and [6] complemented with additional OAM procedures for fault, performance and protection-switching management for packet transport applications that do not rely on the presence of a control plane. In line with [12], existing MPLS OAM mechanisms will be used wherever possible and extensions or new OAM mechanisms will be defined only where existing mechanisms are not sufficient to meet the requirements. The MPLS-TP OAM framework provides a comprehensive set of OAM procedures while satisfying the MPLS-TP OAM requirements [11]. In this regard, it is similar to existing SONET/SDH and OTH OAM mechanisms (e.g. [14]). 1.1. Contributing Authors Italo Busi, Ben Niven-Jenkins, Annamaria Fulignoli, Enrique Hernandez-Valencia, Lieven Levrau, Dinesh Mohan, Vincenzo Sestito, Nurit Sprecher, Huub van Helvoort, Martin Vigoureux, Yaacov Weingarten, Rolf Winter 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 2.1. Terminology DBN Domain Border Node Busi et al. Expires September 26, 2009 [Page 3] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 LME LSP Maintenance Entity LTCME LSP Tandem Connection Maintenance Entity [Editor's note - Difference or similarity between tandem connection monitoring (TCM)_and Path Segment Tunnel (PST) need to be defined and agreed] ME Maintenance Entity [Editor's note - There is a need to define whether to support OAM on p2mp transport path there is a need to introduce the MEG concept] MEP Maintenance End Point MIP Maintenance Intermediate Point PME PW Maintenance Entity PTCME PW Tandem Connection Maintenance Entity SME Section Maintenance Entity 2.2. Definitions Concatenated Segment: see [10] Co-routed bidirectional path: see [10] Domain Border Node: see [13] Layer network: see [10] Section: see [10] OAM domain: A domain, as defined in [10], whose entities are grouped for the purpose of keeping the OAM confined within that domain. Note - within the rest of this document the term "domain" is used to indicate an "OAM domain" OAM flow: An OAM flow is a traffic flow between a pair of MEPs or a MEP and a MIP that is used to monitor a ME [Editor's note - a MEG depending on what we decide for this point]. The OAM flow is associated to a unique ME and contains the OAM monitoring, signalling and notification messages necessary to monitor and maintain that ME. The exact mix of message types in an OAM flow will be dependent on Busi et al. Expires September 26, 2009 [Page 4] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 the technology being monitored and the exact deployment scenario of that technology (e.g. some deployments may proactively monitor the connectivity of all transport paths whereas other deployments may only reactively monitor transport paths) MIP: A MIP terminates and processes OAM messages and generates OAM messages in reaction to received OAM messages. MEP Source: A MEP acts as MEP source for the OAM flow that it originates and inserts into its associated ME. MEP Sink: A MEP acts as a MEP sink for the OAM flow that it terminates and processes from it associated ME. OAM Message: An OAM information element that performs some OAM functionality (e.g. continuity and connectivity verification) OAM Packet: A packet that carries one or more OAM messages (i.e. OAM information elements). Path: See Transport Path Signal Fail: A condition when the data associated with a transport path has failed in the sense that a defect condition (not being a degraded defect) is detected. Segment: see [10] Sublayer: see [10] Tandem Connection: see [10] Transport Path: see [10] Unidirectional path: see [10] 3. Functional Components MPLS defines the use of Label Switched Paths (LSPs) and Pseudowires (PWs)([2], [5] and [7]) that are used to connect service end points. MPLS-TP builds on this framework the need to transport service traffic, based on certain performance and quality measurements. In order to verify and maintain these performance and quality measurements, we need to use the OAM functionality not only on an transport paths (e.g. LSP or MS-PW), but also on arbitrary parts of Busi et al. Expires September 26, 2009 [Page 5] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 transport paths, defined as Tandem Connections in [10], between any two arbitrary points along a path. MPLS-TP OAM operates in the context of Maintenance Entities (MEs). A Maintenance Entity can be viewed as the association of two (or more) Maintenance End Points (MEPs), see below. The MEPs that form an ME are configured and managed to limit the scope of an OAM flow within the ME the MEPs belong to. Each MEP resides at the boundaries of the ME that they are part of. An ME may also include a set of zero or more Maintenance Intermediate Points (MIPs), which reside within the Maintenance Entity, between the MEPs. A MEP is capable of initiating and terminating OAM messages for fault management and performance monitoring. A MIP is capable of terminating OAM messages but it generates OAM messages only in reaction to received OAM messages. This functional model defines the relationships between all OAM entities from a maintenance perspective, to allow each Maintenance Entity to monitor and manage the layer network under its responsibility and easily localize problems. MEPs and MIPs are associated with a particular Maintenance Entity. When a control plane is not present, the management plane configures MEPs and MIPs. Otherwise they can be configured either by the management plane or by the control plane. [Editor's note - Need to align the two paragraphs above with the outcome of the on-going discussion on the mailing list regarding the usage of control plane to configure OAM] 3.1. Maintenance Entity A Maintenance Entity can be viewed as the association of two (or more) Maintenance End Points (MEPs). An example of an ME with more than two MEPs is a point-to-multipoint ME monitoring a point-to- multipoint transport path (or point-to-multipoint tandem connection). The MEPs that form an ME should be configured and managed to limit the OAM responsibilities of an OAM flow within a network or sub- network, or a transport path or segment, in the specific layer network that is being monitored and managed. Any maintenance point in between MEPs is a Maintenance Intermediate Points (MIP). Busi et al. Expires September 26, 2009 [Page 6] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 A Maintenance Entity may be defined to monitor and manage unidirectional point-to-point or point-to-multipoint transport paths or tandem connections, or co-routed bidirectional point-to-point transport paths and tandem connections in an MPLS-TP layer network. MPLS-TP OAM functions are designed to be applied either on an end-to- end basis, e.g., between the LERs of a given LSP or T-PEs of a given PW, or on a per tandem connection basis, e.g., between any LER/LSR of a given LSP or any T-PE/S-PE of a given PW. The end points of a tandem connection are MEPs because the tandem connection is by definition a Maintenance Entity. 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 may 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 They can be nested but not overlapped, e.g. a ME may cover a segment or a concatenated segment of another ME, and may also include the forwarding engine(s) of the node(s) at the edge(s) of the segment or concatenated segment, but all its MEPs and MIPs are no longer part of the encompassing ME. It is possible that MEPs of nested MEs reside on a single node. o Each OAM flow is associated with a single Maintenance Entity. o OAM packets are subject to the same forwarding treatment (e.g. fate share) as the data traffic, but they can be distinguished from the data traffic using the GAL and ACH constructs [9] for LSP and the ACH construct [6] [9] for (MS-)PW. 3.2. Maintenance End Points (MEPs) Maintenance End Points (MEPs) are the end points of a 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. MEPs prevent OAM packets corresponding to a ME from leaking outside that ME: Busi et al. Expires September 26, 2009 [Page 7] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 o A MEP sink terminates all the OAM packets that it receives corresponding to its ME and does not forward them further along the path. If the pro-active CC&CV OAM tool detects an unintended connectivity, all traffic on the path is blocked (i.e. all received packets are dropped, including user-data packets). o A MEP source tunnels all the OAM packets that it receives, upstream from the associated ME, via label stacking. These packets are not processed within the ME as they belong to another ME. [Editor's - Need to rephrase the bullet above to clarify what it actually means] MPLS-TP MEP notifies a fault indication to the MPLS-TP client layer network. A MEP of a tandem connection is not necessarily coincident with the termination of the MPLS-TP transport path (LSP or PW), though it can monitor it for failures or performance degradation (e.g. count packets) within the boundary of the tandem connection. [Editor's note - The MEP of a TCM monitors the transport paths' connectivity within the scope of the TCM. This means that failures or performance degradations within the TCM are detected by the TCM MEP while failures or performance degradations outside the TCM are not detected by the TCM MEP. Is the text above sufficient to explain this concept?] A MEP of an MPLS-TP transport path coincides with transport path termination and monitors it for failures or performance degradation on an end-to-end scope (e.g. count packets). Note that both MEP source and MEP sink coincide with transport paths' source and sink terminations. [Editor's note - Add some text regarding MEP identification as well as about what a MEP should do if it receives an unexpected OAM packet] 3.3. Maintenance Intermediate Points (MIPs) A Maintenance Intermediate Point (MIP) is a point between the two MEPs in an ME that is capable of reacting to some OAM packets and forwarding all the other OAM packets while ensuring fate sharing with data plane packets. A MIP belongs to only one ME. Busi et al. Expires September 26, 2009 [Page 8] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 A MIP does not initiate unsolicited OAM packets, but may be addressed by OAM packets initiated by one of the MEPs of the ME. A MIP can generate OAM packets only in response to OAM packets that are sent on the ME it belongs to. [Editor's note - It is needed to describe about how this is achieved (e.g. TTL expiry). Is this description in the scope of this document?] MIPs are unaware of any OAM flows running between MEPs or between MEPs and other MIPs. MIPs can only receive and process OAM packets addressed to the MIP itself. A MIP takes no action on the MPLS-TP transport path. [Editor's note - Add some text regarding MIP identification as well as about what a MIP should do if it receives an unexpected OAM packet] 3.4. Server MEPs A server MEP is a MEP of an ME that is either: o defined in a layer network below the MPLS-TP layer network being referenced, or o defined in a sub-layer of the MPLS-TP layer network that is below the sub-layer 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: o 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 section 4.1. ; o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section 4.2. ; o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in section 4.4. ; o An MPLS-TP LSP Tandem Connection MEP for higher-level LTCMEs, defined in section 4.3. ; o An MPLS-TP PW Tandem Connection MEP for higher-level PTCMEs, defined in section 0 Busi et al. Expires September 26, 2009 [Page 9] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 The server MEP can run appropriate OAM functions for fault detection within the server (sub-)layer network, and notifies a fault indication to the MPLS-TP layer network. 4. Reference Model The reference model for the MPLS-TP framework builds upon the concept of an ME, and its associated MEPs and MIPs, to support the functional requirements specified in [11]. The following MPLS-TP MEs are specified in this document: o A Section Maintenance Entity (SME), allowing monitoring and management of MPLS-TP Sections (between MPLS LSRs). o A LSP Maintenance Entity (LME), allowing monitoring and management of an end-to-end LSP (between LERs). o A PW Maintenance Entity (PME), allowing monitoring and management of an end-to-end SS/MS-PWs (between T-PEs). o An LSP Tandem Connection Maintenance Entity (LTCME), allowing monitoring and management of an LSP Tandem Connection between any LER/LSR along the LSP. o A MS-PW Tandem Connection Maintenance Entity (PTCME), allows monitoring and management of a SS/MS-PW Tandem Connection between any T-PE/S-PE along the (MS-)PW. The MEs specified in this MPLS-TP framework are compliant with the architecture framework for MPLS MS-PWs [7] and MPLS LSPs [2]. Hierarchical LSPs are also supported. In this case, each LSP Tunnel in the hierarchy is a different sub-layer network that can be monitored, independently from higher and lower level LSP tunnels in the hierarchy, end-to-end (from LER to LER) by an LME. Tandem Connection monitoring via LTCME are applicable on each LSP Tunnel in the hierarchy. Busi et al. Expires September 26, 2009 [Page 10] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 Native |<------------------- MS-PW1Z ------------------->| Native Layer | | Layer Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service (AC1) V V LSP V V LSP V V LSP V V (AC2) +----+ +-+ +----+ +----+ +-+ +----+ +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ | | | |=========| |=========| |=========| | | | | CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 | | | | |=========| |=========| |=========| | | | +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +----+ +-+ +----+ +----+ +-+ +----+ . . . . | | | | |<---- Domain 1 --->| |<---- Domain Z --->| .------------------- PW1Z PME -------------------. .---- PW13 PTCME ---. .---- PWXZ PTCME ---. .---------. .---------. PSN13 LME PSNXZ LME .---. .---. .---------. .---. .---. Sec12 Sec23 Sec3X SecXY SecYZ SME SME SME SME SME TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3 TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z .---. ME . MEP ==== LSP .... PW Figure 1 Reference Model for the MPLS-TP OAM Framework Figure 1 depicts a high-level reference model for the MPLS-TP OAM framework. The figure depicts portions of two MPLS-TP enabled network domains, Domain 1 and Domain Z. In Domain 1, LSR 1 is adjacent to LSR 2 via the MPLS Section Sec12 and LSR2 is adjacent to LSR3 via the MPLS Section Sec23. Similarly, in Domain Z, LSR X is adjacent to LSR Y via the MPLS Section SecXY and LSR Y is adjacent to LSR Z via the MPLS Section SecYZ. In addition, LSR 3 is adjacent to LSR X via the MPLS Section 3X. Figure 1 also shows a bi-directional MS-PW (MS-PW1Z) between AC1 on LSR 1 (TPE1) and AC2 on LSR Z (TPEZ). The MS-PW consists of 3 bi- directional PW Segments: 1) PW Segment 13 (PW13) between LSR 1 (TPE1) and LSR 3 (SPE3) via the bi-directional PSN13 LSP, 2) PW Segment 3X (PW3X) between LSR 3 (SPE3) and LSR X (SPEX), and 3) PW Segment XZ (PWXZ) between LSR X (SPEX) and LSR Z (TPEZ) via the bi-directional PSNXZ LSP. Busi et al. Expires September 26, 2009 [Page 11] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 The MPLS-TP OAM procedures that apply to an instance of a given ME are expected to operate independently from procedures on other instances of the same ME and certainly of other MEs. Yet, this does not preclude that multiple MEs may be affected simultaneously by the same network condition, for example, a fiber cut event. Note that there are no constrains imposed by this OAM framework on the number, or type, of MEs that may be instantiated a particular node. In particular, when looking at Figure 1, it should be possible to configure one or more MEPs from the same node if the same node is the endpoint of one or more MEs. The subsections below define the MEs specified in this MPLS-TP OAM architecture framework document. Unless otherwise stated, all references to domains, LSRs, MPLS Sections, LSP, pseudowires and MEs in this Section are made in relation to those shown in Figure 1. 4.1. MPLS-TP Section Monitoring An MPLS-TP Section ME (SME) is an MPLS-TP maintenance entity intended to monitor the forwarding behaviour of an MPLS Section as defined in [10]. An SME may be configured on any MPLS section. SME OAM packets fate share with the user data packets sent over the monitored MPLS Section. An SME is intended to be deployed for applications where it is preferable to monitor the link between the topologically adjacent (next hop in this layer network) MPLS (and MPLS-TP enabled) LSRs rather than monitoring the individual LSP or PW segments traversing the MPLS Section and the server layer technology does not provide adequate OAM capabilities. Busi et al. Expires September 26, 2009 [Page 12] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 |<------------------- MS-PW1Z ------------------->| | | | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | V V LSP V V LSP V V LSP V V +----+ +-+ +----+ +----+ +-+ +----+ +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ | | AC1 | |=========| |=========| |=========| | AC2 | | | CE1|--------|........PW13.......|...PW3X..|.......PWXZ........|-------|CE2 | | | | |=========| |=========| |=========| | | | +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +----+ +-+ +----+ +----+ +-+ +----+ .--. .--. .--------. .--. .--. Sec12 Sec23 Sec3X SecXY SecYZ SME SME SME SME SME Figure 2 Reference Example of MPLS-TP Section MEs (SME) Figure 2 shows 5 Section MEs configured in the path between AC1 and AC2: 1) Sec12 ME associated with the MPLS Section between LSR 1 and LSR 2, 2) Sec23 ME associated with the MPLS Section between LSR 2 and LSR 3, 3) Sec3X ME associated with the MPLS Section between LSR 3 and LSR X, 4) SecXY ME associated with the MPLS Section between LSR X and LSR Y, and 5) SecYZ ME associated with the MPLS Section between LSR Y and LSR Z. 4.2. MPLS-TP LSP End-to-End Monitoring An MPLS-TP LSP ME (LME) is an MPLS-TP maintenance entity intended to monitor the forwarding behaviour of an end-to-end LSP between two (e.g., a point-to-point LSP) or more (e.g., a point-to-multipoint LSP) LERs. An LME may be configured on any MPLS LSP. LME OAM packets fate share with user data packets sent over the monitored MPLS-TP LSP. An LME is intended to be deployed in scenarios where it is desirable to monitor the forwarding behaviour of an entire LSP between its LERs, rather than, say, monitoring individual PWs. Busi et al. Expires September 26, 2009 [Page 13] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 |<------------------- MS-PW1Z ------------------->| | | | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | V V LSP V V LSP V V LSP V V +----+ +-+ +----+ +----+ +-+ +----+ +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ | | AC1 | |=========| |=========| |=========| | AC2 | | | CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 | | | | |=========| |=========| |=========| | | | +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +----+ +-+ +----+ +----+ +-+ +----+ .---------. .---------. PSN13 LME PSNXZ LME Figure 3 Examples of MPLS-TP LSP MEs (LME) Figure 3 depicts 2 LMEs configured in the path between AC1 and AC2: 1) the PSN13 LME between LER 1 and LER 3, and 2) the PSNXZ LME between LER X and LER Y. Note that the presence of a PSN3X LME in such a configuration is optional, hence, not precluded by this framework. For instance, the SPs may prefer to monitor the MPLS-TP Section between the two LSRs rather than the individual LSPs. 4.3. MPLS-TP LSP Tandem Connection Monitoring An MPLS-TP LSP Tandem Connection Monitoring ME (LTCME) is an MPLS-TP maintenance entity intended to monitor the forwarding behaviour of an arbitrary part of an LSP between a given pair of LSRs independently from the end-to-end monitoring (LME). An LTCME can monitor an LSP segment or concatenated segment and it may also include the forwarding engine(s) of the node(s) at the edge(s) of the segment or concatenated segment. Multiple LTCMEs MAY BE configured on any LSP. The LSRs that terminate the LTCME may or may not be immediately adjacent at the MPLS-TP layer. LTCME OAM packets fate share with the user data packets sent over the monitored LSP segment. A LTCME can be defined between the following entities: o LER and any LSR of a given LSP. o Any two LSRs of a given LSP. An LTCME is intended to be deployed in scenarios where it is preferable to monitor the behaviour of a part of an LSP rather than Busi et al. Expires September 26, 2009 [Page 14] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 the entire LSP itself, for example when there is a need to monitor a part of an LSP that extends beyond the administrative boundaries of an MPLS-TP enabled administrative domain. Note that LTCMEs are equally applicable to hierarchical LSPs. |<--------------------- PW1Z -------------------->| | | | |<--------------PSN1Z LSP-------------->| | | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | V V S-LSP V V S-LSP V V S-LSP V V +----+ +-+ +----+ +----+ +-+ +----+ +----+ | PE1| | | |DBN3| |DBNX| | | | PEZ| +----+ | | AC1 | |=======================================| | AC2 | | | CE1|--------|......................PW1Z.......................|-------|CE2 | | | | |=======================================| | | | +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +----+ +-+ +----+ +----+ +-+ +----+ . . . . | | | | |<---- Domain 1 --->| |<---- Domain Z --->| .---------. .---------. PSN13 LTCME PSNXZ LTCME .---------------------------------------. PSN1Z LME DBN: Domain Border Node Figure 4 MPLS-TP LSP Tandem Connection Monitoring ME (LTCME) Figure 4 depicts a variation of the reference model in Figure 1 where there is an end-to-end PSN LSP (PSN1Z LSP) between PE1 and PEZ. PSN1Z LSP consists of, at least, three stitched LSP Segments: PSN13, PSN3X and PSNXZ. In this scenario there are two separate LTCMEs configured to monitor the forwarding behaviour of the PSN1Z LSP: 1) a LTCME monitoring the PSN13 LSP Segment on Domain 1 (PSN13 LTCME), and 2) a LTCME monitoring the PSNXZ LSP Segment on Domain Z (PSNXZ LTCME). It is worth noticing that LTCMEs can coexist with the LME monitoring the end-to-end LSP and that LTCME MEPs and LME MEPs can be coincident in the same node (e.g. PE1 node supports both the PSN1Z LME MEP and the PSN13 LTCME MEP). Busi et al. Expires September 26, 2009 [Page 15] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 4.4. MPLS-TP PW Monitoring An MPLS-TP PW ME (PME) is an MPLS-TP maintenance entity intended to monitor the end-to-end forwarding behaviour of a SS-PW or MS-PW between a pair of T-PEs. A PME MAY be configured on any SS-PW or MS- PW. PME OAM packets fate share with the user data packets sent over the monitored PW. A PME is intended to be deployed in scenarios where it is desirable to monitor the forwarding behaviour of an entire PW between a pair of MPLS-TP enabled T-PEs rather than monitoring the LSP aggregating multiple PWs between PEs. |<------------------- MS-PW1Z ------------------->| | | | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | V V LSP V V LSP V V LSP V V +----+ +-+ +----+ +----+ +-+ +----+ +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ | | AC1 | |=========| |=========| |=========| | AC2 | | | CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 | | | | |=========| |=========| |=========| | | | +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +----+ +-+ +----+ +----+ +-+ +----+ .---------------------PW1Z PME--------------------. Figure 5 MPLS-TP PW ME (PME) Figure 5 depicts a MS-PW (MS-PW1Z) consisting of three segments: PW13, PW3X and PWXZ and its associated end-to-end PME (PW1Z PME). 4.5. MPLS-TP MS-PW Tandem Connection Monitoring An MPLS-TP MS-PW Tandem Connection Monitoring ME (PTCME) is an MPLS- TP maintenance entity intended to monitor the forwarding behaviour of an arbitrary part of an MS-PW between a given pair of PEs independently from the end-to-end monitoring (PME). An PTCME can monitor a PW segment or concatenated segment and it may alos include the forwarding engine(s) of the node(s) at the edge(s) of the segment or concatenated segment. Multiple PTCMEs MAY be configured on any MS-PW. The PEs may or may not be immediately adjacent at the MS-PW layer. PTCME OAM packets fate share with the user data packets sent over the monitored MS-PW Segment. Busi et al. Expires September 26, 2009 [Page 16] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 A PTCME can be defined between the following entities: o T-PE and any S-PE of a given MS-PW o Any two S-PEs of a given MS-PW. It can span several PW segments. A PTCME is intended to be deployed in scenarios where it is preferable to monitor the behaviour of a part of a MS-PW rather than the entire end-to-end PW itself, for example to monitor an MS-PW Segment within a given network domain of an inter-domain MS-PW. |<------------------- MS-PW1Z ------------------->| | | | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | V V LSP V V LSP V V LSP V V +----+ +-+ +----+ +----+ +-+ +----+ +----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ | | AC1 | |=========| |=========| |=========| | AC2 | | | CE1|--------|........PW13.......|...PW3X..|........PWXZ.......|-------|CE2 | | | | |=========| |=========| |=========| | | | +----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ +----+ +-+ +----+ +----+ +-+ +----+ .---- PW1 PTCME ----. .---- PW5 PTCME ----. .---------------------PW1Z PME--------------------. Figure 6 MPLS-TP MS-PW Tandem Connection Monitoring (PTCME) Figure 6 depicts the same MS-PW (MS-PW1Z) between AC1 and AC2 as in Figure 5. In this scenario there are two separate PTCMEs configured to monitor the forwarding behaviour of MS-PW1Z: 1) a PTCME monitoring the PW13 MS-PW Segment on Domain 1 (PW13 PTCME), and 2) a PTCME monitoring the PWXZ MS-PW Segment on Domain Z with (PWXZ PTCME). It is worth noticing that PTCMEs can coexist with the PME monitoring the end-to-end MS-PW and that PTCME MEPs and PME MEPs can be coincident in the same node (e.g. TPE1 node supports both the PW1Z PME MEP and the PW13 PTCME MEP). 5. OAM Functions for pro-active monitoring 5.1. Continuity Check and Connectivity Verification Proactive Continuity and Connectivity Verification (CC & CV) function is used to detect loss of continuity (LOC), unexpected connectivity between two MEs (e.g. mismerging or misconnection) as well as unexpected connectivity within the ME with an unexpected MEP. Busi et al. Expires September 26, 2009 [Page 17] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 Proactive CC & CV is based upon the generation of OAM pro-active CC/CV packets, carrying a unique ME identifier, at a regular configurable timing rate and the detection of LOC when these packets do not arrive. If the received ME identifier does not match the expected ME identifier, a connectivity defect has occurred. The default CC/CV transmission periods are application dependent (see section 5.1.1. ) Proactive CC & CV packets are transmitted with the "minimum loss probability PHB" within a single network operator. This PHB is configurable on network operator's basis. [Editor's note - Describe the relation between the previous paragraph and the fate sharing requirement. Need to clarify also in the requirement document that for proactive CC&CV the fate sharing is related to the forwarding behavior and not to the QoS behavior] For statically provisioned transport paths, the transmission period and the ME identifier are statically configured at both MEPs. For dynamically established transport paths, the transmission period and the ME identifier are signaled via the control plane. In a bidirectional point-to-point transport path, when a MEP is enabled to generate pro-active CC/CV packets with a configured transmission period, it also expects to receive pro-active CC/CV packets from its peer MEP with the same transmission period. In a unidirectional transport path (point-to-point or point-to- multipoint), only the source MEP is enabled to generate packets with CC/CV information. This MEP does not expect to receive any packets with CC/CV information from its peer MEPs in the ME. MIPs as well as intermediate nodes not supporting MPLS-TP OAM are transparent to the pro-active CC/CV information and forward pro- active CC/CV packets as regular data packets. When CC & CV is enabled, a MEP periodically transmits pro-active CC/CV packets with frequency of the configured transmission period. When CC & CV is enabled, a MEP detects loss of continuity (LOC) defect with a peer MEP when it receives no pro-active CC/CV packets from the peer MEP within the interval equal to 3.5 times the transmission period. When a pro-active CC/CV packet is received, a MEP is able to detect a mis-connectivity defect (e.g. mismerge or misconnection) with another ME when the received packet carries an incorrect ME identifier. Busi et al. Expires September 26, 2009 [Page 18] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 If pro-active CC/CV packets are received with a transmission period different than expected, CC/CV period mis-configuration defect is detected. [Editor's note - Need to add the defect clearing conditions and complete the description of consequent actions] [Editor's note - Transport equipment also performs defect correlation (as defined in G.806) in order to properly report failures to the transport NSM. The current working assumption, to be further investigated, is that defect correlations are outside the scope of this document and to be defined in ITU-T documents.] A receiving MEP notifies the equipment fault management process when it detects the above defect conditions. If a MEP detects an unexpected connectivity it MUST block all the traffic (including also the user data packets) that it receives from the misconnected transport path. It is worth noticing that the OAM requirements document [11] recommends that CC-CV proactive monitoring is enabled on every ME in order to reliably detect connectivity defects. However, CC-CV proactive monitoring can be disabled by an operator on a ME. In this case a LOC defect can be a connectivity problem (e.g. a misconnection with a transport path where CC-CV proactive monitoring is not enabled) and not necessarily a continuity problem, with a consequent wrong traffic delivering. For these reasons, the traffic block consequent action is applied even when a LOC condition occurs. The activation of the traffic block consequent action is configurable (i.e. the operator can enable/disable the consequent action) in case of LOC condition. In order to enable the proactive CC-CV monitoring on a configured ME in a not traffic affecting way, the MEP source function (generating pro-active CC&CV packets) should be enabled before the corresponding MEP sink function (detecting continuity and connectivity defects). Vice versa, when disabling the CC-CV proactive functionality, MEP sink function should be disabled before the corresponding MEP source function. Busi et al. Expires September 26, 2009 [Page 19] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 If it is not possible to synchronize both direction on the peer MEPs, the traffic can be preserved even disabling/re-enabling the traffic block consequent action due to a LOC defect. 5.1.1. Applications for proactive CC & CV function CC & CV is applicable for fault management, performance monitoring, or protection switching applications. o Fault Management: default transmission period is 1s (i.e. transmission rate of 1 packet/second) o Performance Monitoring: default transmission period is 100ms (i.e. transmission rate of 10 packets/second) o Protection Switching: in order to achieve sub-50ms recovery time the default transmission period is 3.33ms (i.e. transmission rate of 300 packets/second) although a transmission period of 10ms can also be used. In some cases, when a slower recovery time is acceptable, it is also possible to relax the transmission period. 5.2. Remote Defect Indication The Remote Defect Indication (RDI) is an indicator that is transmitted by a MEP to communicate to its peer MEPs that a signal fail condition exists. RDI is only used for bidirectional connections and is associated with proactive CC & CV packet generation. A MEP detects a signal fail condition (and thus starts transmitting an RDI indication to its peer MEP) in case of a continuity or connectivity defect or an AIS condition is detected. [Editor's note - Add some forward compatibility information to cover the case where future OAM mechanisms that contributes to the signal fail detection (and RDI generation) are defined.] A sink MEP that has identified a signal fail should report this to the associated source MEP that should include the RDI information in all pro-active CC/CV packets that it generates for the duration of the signal fail condition existence. A MEP that receives the packets with the RDI information should determine that its peer MEP has encountered a defect condition associated with a signal fail. Busi et al. Expires September 26, 2009 [Page 20] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 MIPs as well as intermediate nodes not supporting MPLS-TP OAM are transparent to the RDI indicator and forward pro-active CC/CV packets that include the RDI indicator as regular data packets, i.e. the MIP should not perform any actions nor examine the indicator. When the signal fail defect condition clears, the MEP should clear the RDI indicator from subsequent transmission of pro-active CC/CV packets. A MEP also clears the RDI defect upon reception of a pro-active CC/CV packet from the source MEP with the RDI indicator cleared. 5.2.1. Configuration considerations In order to support RDI indication, the RDI transmission rate and PHB of the MEP should be configured as part of the CC & CV configuration. 5.2.2. Applications for Remote Defect Indication RDI is applicable for the following applications: o Single-ended fault management - A MEP that receives an RDI indication from its peer MEP, can report a far-end defect condition (i.e. the peer MEP has detected a signal fail condition in the traffic direction from the MEP that receives the RDI indication to the peer MEP that has sent the RDI information). o Contribution to far-end performance monitoring - The indication of the far-end defect condition is used as a contribution to the bidirectional performance monitoring process. 5.3. Alarm Suppression Alarm Indication Signal function (AIS) is used to suppress alarms following detection of defect conditions at the server (sub) layer. o A server MEP that detects a signal fail conditions in the server (sub-)layer, can generate packets with AIS information to allow the suppression of secondary alarms at the MEP in the client (sub- )layer. A server MEP is responsible for notifying the MPLS-TP layer network MEP upon fault detection in the server layer network to which the server MEP is associated. Only Server MEPs can issue MPLS-TP packets with AIS information. Upon detection of a signal fail condition the Server MEP can immediately Busi et al. Expires September 26, 2009 [Page 21] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 start transmitting packets with AIS information periodically. A Server MEP continues to transmit periodic packets with AIS information until the signal fail condition is cleared. Upon receiving a packet with AIS information a MEP detects an AIS defect condition and suppresses loss of continuity alarms associated with all its peer MEPs. A MEP resumes loss of continuity alarm generation upon detecting loss of continuity defect conditions in the absence of AIS condition. For example a fiber cut between LSR 1 and LSR 2 in the reference network of Figure 1 can be considered. Assuming that all the MEs described in Figure 1 have pro-active CC&CV enable, a LOC defect is detected by the MEPs of Sec12 SME, PSN13 LME, PW1 PTCME and PW1Z PME, however in transport network only the alarm associate to the fiber cut needs to be reported to NMS while all these secondary alarms should be suppressed (i.e. not reported to the NMS or reported as secondary alarms). If the fiber cut is detected by the MEP in the physical layer (in LSR2), LSR2 can generate the proper alarm in the physical layer and suppress the secondary alarm associated with the LOC defect detected on Sec12 SME. As both MEPs reside within the same node, this process does not involve any external protocol exchange. Otherwise, if the physical layer has not enough OAM capabilities to detect the fiber cut, the MEP of Sec12 SME in LSR2 will report a LOC alarm. In both cases, the MEP of Sec12 SME in LSR 2 generates AIS packets on the PSN13 LME in order to allow its MEP in LSR3 to suppress the LOC alarm. LSR3 can also suppress the secondary alarm on PW1 PTCME because the MEP of PW1 PTCME resides within the same node as the MEP of PSN13 LME. The MEP of PW1 PTCME in LSR3 also generates AIS packets on PW1Z PME in order to allow its MEP in LSRZ to suppress the LOC alarm. The generation of AIS packets for each MEs in the client (sub-)layer is configurable (i.e. the operator can enable/disable the AIS generation). AIS packets are transmitted with the "minimum loss probability PHB" within a single network operator. This PHB is configurable on network operator's basis. Busi et al. Expires September 26, 2009 [Page 22] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 A MIP is transparent to packets with AIS information and therefore does not require any information to support AIS functionality. 5.4. Lock Indication To be incorporated in a future revision of this document 5.5. Packet Loss Measurement To be incorporated in a future revision of this document 5.6. Client Signal Fail To be incorporated in a future revision of this document 6. OAM Functions for on-demand monitoring 6.1. Continuity Check and Connectivity Verification In order to preserve network resources, e.g. bandwidth, processing time at switches, it may be preferable to not use continual pro- active CC & CV. In order to perform fault management functions network management may invoke periodic on-demand bursts of on-demand CC/CV packets. Use of on-demand CC & CV is dependent on the existence of a bi-directional connection ME. An additional use of on-demand CC & CV would be to detect and locate a problem of connectivity when a problem is suspected or known based on other tools. In this case the functionality will be triggered by the network management in response to a status signal or alarm indication. On-demand CC & CV is based upon generation of on-demand CC/CV packets that should uniquely identify the ME that is being checked. The on- demand functionality may be used to check either an entire ME (end- to-end) or between a MEP to a specific MIP. On-demand CC & CV may generate a one-time burst of on-demand CC/CV packets, or be used to invoke periodic, non-continuous, bursts of on- demand CC/CV packets. The number of packets generated in each burst is configurable at the MEPs, and should take into account normal packet-loss conditions. When invoking a periodic check of the ME, the source MEP should issue a burst of on-demand CC/CV packets that uniquely identifies the ME being verified. The number of packets and their transmission rate should be pre-configured and known to both the source MEP and the Busi et al. Expires September 26, 2009 [Page 23] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 target MEP or MIP. The source MEP should use the TTL field to indicate the number of hops necessary, when targeting a MIP and use the default value when performing an end-to-end check [IB => This is quite generic for addressing packets to MIPs and MEPs so it is better to move this text in section 2]. The target MEP/MIP shall return a reply on-demand CC/CV packet for each packet received. If the expected number of on-demand CC/CV reply packets is not received at source MEP, a LOC state is detected. [Editor's note - We need to add some text for the usage of on-demand CC&CV with different packet sizes, e.g. to discover MTU problems.] When a connectivity problem is detected (e.g. via a pro-active CC&CV OAM tool), on demand CC&CV tool can be used to check the path. The series should check CC&CV from MEP to peer MEP on the path, and if a fault is discovered, by lack of response, then additional checks may be performed to each of the intermediate MIP to locate the fault. 6.1.1. Configuration considerations For on-demand CC & CV the MEP should support configuration of number of packets to be transmitted/received in each burst of transmissions and the transmission rate should be either pre-configured or negotiated between the different nodes. In addition, when the CC & CV packet is used to check connectivity toward a target MIP, the number of hops to reach the target MIP should be configured. The PHB of the on-demand CC/CV packets should be configured as well. [Editor's note - We need to be better define the reason for such configuration] 6.2. Packet Loss Measurement To be incorporated in a future revision of this document 6.3. Diagnostic Test To be incorporated in a future revision of this document 6.4. Trace routing To be incorporated in a future revision of this document Busi et al. Expires September 26, 2009 [Page 24] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 6.5. Packet Delay Measurement To be incorporated in a future revision of this document 7. OAM Protocols Overview To be incorporated in a future revision of this document 8. Security Considerations A number of security considerations important in the context of OAM applications. OAM traffic can reveal sensitive information such as passwords, performance data and details about e.g. the network topology. The nature of OAM data therefore suggests to have some form of authentication, authorization and encryption in place. This will prevent unauthorized access to vital equipment and it will prevent third parties from learning about sensitive information about the transport network. Mechanisms that the framework does not specify might be subject to additional security considerations. 9. IANA Considerations No new IANA considerations. 10. 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 T-MPLS Ad Hoc Group in ITU-T) involved in the definition and specification of MPLS Transport Profile. This document was prepared using 2-Word-v2.0.template.dot. Busi et al. Expires September 26, 2009 [Page 25] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001 [3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032, January 2001 [4] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003 [5] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005 [6] Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007 [7] Bocci, M., Bryant, S., "An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw- arch-05 (work in progress), September 2008 [8] Bocci, M., et al., "A Framework for MPLS in Transport Networks", draft-ietf-mpls-tp-framework-00 (work in progress), November 2008 [9] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R., "MPLS Generic Associated Channel ", draft-ietf-mpls-tp-gach- gal-02 (work in progress), February 2009 11.2. Informative References [10] Niven-Jenkins, B., Brungard, D., Betts, M., sprecher, N., Ueno, S., "MPLS-TP Requirements", draft-ietf-mpls-tp-requirements-05 (work in progress), March 2009 [11] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements- 01 (work in progress), March 2009 Busi et al. Expires September 26, 2009 [Page 26] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 [12] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, Y., "MPLS-TP OAM Analysis", draft-sprecher-mpls-tp-oam-analysis-02 (work in progress), September 2008 [13] Farrel, A., Ayyangar, A., Vasseur, JP., "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008 [14] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node interface for the synchronous digital hierarchy (SDH)", 2007 Authors' Addresses Italo Busi (Editor) Alcatel-Lucent Email: Italo.Busi@alcatel-lucent.it Ben Niven-Jenkins (Editor) BT Email: benjamin.niven-jenkins@bt.com Contributing Authors' Addresses Annamaria Fulignoli Ericsson Email: annamaria.fulignoli@ericsson.com Enrique Hernandez-Valencia Alcatel-Lucent Email: enrique@alcatel-lucent.com Lieven Levrau Alcatel-Lucent Email: llevrau@alcatel-lucent.com Busi et al. Expires September 26, 2009 [Page 27] Internet-Draft MPLS-TP OAM Framework and Overview March 2009 Dinesh Mohan Nortel Email: mohand@nortel.com Vincenzo Sestito Alcatel-Lucent Email: vincenzo.sestito@alcatel-lucent.it Nurit Sprecher Nokia Siemens Networks Email: nurit.sprecher@nsn.com Huub van Helvoort Huawei Technologies Email: hhelvoort@huawei.com Martin Vigoureux Alcatel-Lucent Email: martin.vigoureux@alcatel-lucent.fr Yaacov Weingarten Nokia Siemens Networks Email: yaacov.weingarten@nsn.com Rolf Winter NEC Email: Rolf.Winter@nw.neclab.eu Busi et al. Expires September 26, 2009 [Page 28]