Internet Working Group A. Sajassi (Ed.) Internet Draft Cisco Category: Standards Track D. Mohan (Ed.) Nortel D. Brungard H. Fowler AT&T P. Niger France Telecom Simon Delord Alcatel-Lucent March 14, 2011 Expires: September 14, 2011 VPLS OAM draft-mohan-l2vpn-vpls-oam-02 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 August 11, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Mohan, et. al. Expires: January 2009 [Page 1] Internet-Draft VPLS OAM July 2008 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document provides a comprehensive end-to-end solution for VPLS Operation, Administration and Maintenance (OAM). This solution is based on the L2VPN OAM framework [L2VPN-OAM-REQ-FRMK] and specifies how to meet the requirements set therein. Conventions 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 Table of Contents Abstract........................................................... 2 1. Introduction.................................................... 3 1.1 Terminology.................................................... 4 2. VPLS OAM Scope.................................................. 4 2.1. VPLS as Bridged LAN Service................................... 6 2.2. VPLS as (V)LAN Emulation...................................... 6 3. VPLS OAM Solution Overview...................................... 6 4. VPLS OAM Solution.............................................. 10 4.1. Discovery.................................................... 10 4.2. Connectivity Fault Management................................ 11 4.2.1. Connectivity Fault Detection............................... 11 4.2.2. Connectivity Fault Verification............................ 12 4.2.3. Connectivity Fault Localization............................ 12 4.2.4. Connectivity Fault Notification............................ 13 4.3. Frame Loss................................................... 13 4.4. Frame Delay.................................................. 14 4.5. Frame Delay Variation........................................ 14 4.6. Availability................................................. 14 Mohan, et. al. Expires: January 2009 [Page 2] Internet-Draft VPLS OAM July 2008 4.7. Data Path Forwarding......................................... 14 6.8. Scalability.................................................. 15 4.9. Extensibility................................................ 15 4.10. Security.................................................... 15 4.11. Transport Independence...................................... 16 4.12. Application Independence.................................... 17 5. VPLS OAM Operational Steps..................................... 17 6. Acknowledgments................................................ 19 7. IANA Considerations............................................ 19 8. Security Considerations........................................ 19 9. Intellectual Property Considerations........................... 19 10. References.................................................... 19 10.1 Normative References......................................... 19 10.2 Informative References....................................... 20 Appendix A: Ethernet and PSN OAM Interworking..................... 20 Authors' Addresses................................................ 20 1. Introduction This document provides a solution for VPLS Operation, Administration and Maintenance (OAM). The solution is based on L2VPN OAM Framework [L2VPN-OAM-REQ-FRMK]. This document focuses on the Fault and Performance Management functionalities in support of the VPLS as a bridged LAN service and VPLS as a (V)LAN Emulation technology. As described in [L2VPN-OAM-REQ-FRMK], only the devices with Ethernet functionality are visible to the VPLS OAM mechanisms. OAM functionality related to the PSN transport (e.g. MPLS, IP) is out of scope though some operational guidance is provided to make use of PSN transport OAM mechanisms for troubleshooting within the PSN transport. [L2VPN-OAM-REQ-FRMK] describes a service OAM approach based on partitioning a network into a set of hierarchical domains to allow managing the end-to-end network infrastructure and services while supporting the business relationships between customers, service providers, and network operators. The solution defined in this document leverages the IEEE 802.1ag and Y.1731 OAM mechanisms to fullfil the requirements of [L2VPN-OAM-REQ-FRMK]. The use of IEEE 802.1ag and Y.1731 in support of VPLS service management is aligned with other Standards bodies (IEEE, MEF, and ITU-T). This solution provides a consistent OAM approach for an operator regardless of the underlying transport network technology (MPLS, SONET, OTN), though it does provide some operational guidance on how to combine VPLS OAM and transport OAM for IP/MPLS PSN to provide a comprehensive end-to- end OAM solution. Mohan, et. al. Expires: January 2009 [Page 3] Internet-Draft VPLS OAM July 2008 This solution document is intended as a checklist of VPLS OAM mechanisms and operational scenarios. Each operator will choose the appropriate approach for their individual needs. By utilizing IEEE 802.1ag and Y.1731, this solution provides a means to support separation of management domains and independent operations for the operator. Each operator can choose what/when/where the mechanisms best fit their business needs. This solution supports an evolutionary rollout of capabilities for an operator(s); it is not necessary to support IEEE 802.1ag/Y.1731 end-to-end for this solution. 1.1 Terminology This document uses the following terms. 1DM One-way Delay Measurement Message, defined in Y.1731 AIS Alarm Indication Signal, defined in Y.1731 CCM Continuity Check Message, defined in 802.1ag and Y.1731 DMM/DMR Delay Measurement Message/Reply, defined in Y.1731 LBM/LBR Loopback Message/Reply, defined in 802.1ag and Y.1731 LTM/LTR Linktrace Message/Reply, defined in 802.1ag and Y.1731 MD Level Maintenance Domain (MD) Level which identifies a value in the range of 0-7 associated with Ethernet OAM frame. MD Level identifies the span of Ethernet OAM frame. MEP Maintenance End Point is responsible for origination and termination of OAM frames for a given Maintenance Association MIP Maintenance Intermediate Point is located between peer MEPs and can process OAM frames and respond to them but does not initiate them OAM Operations, Administration and Maintenance PSN Packet Switched Network RDI Remote Defect Indication VPLS Virtual Private LAN Service U-PE PE facing the User in H-VPLS, also called as Spoke PE N-PE PE facing the Network in H-VPLS, also called as Core PE 2. VPLS OAM Scope Virtual Private LAN Service (VPLS) is used in different contexts, as described in [L2VPN-OAM-REQ-FRMK]. In general, VPLS is used in the following contexts: a) as an end-to-end bridged LAN service over one or more networks, some of which are MPLS/IP, b) as an MPLS/IP network supporting these bridged LAN services, and c) as (V)LAN emulation consisting of a full-mesh of Pseudowires (PWs) and associated forwarders. For the purposes of the VPLS OAM solutions, this document focuses on the following two contexts of the VPLS: - VPLS as an end-to-end Bridges LAN Service Mohan, et. al. Expires: January 2009 [Page 4] Internet-Draft VPLS OAM July 2008 - VPLS as (V)LAN Emulation - This aspect of the solution provides coverage for both b) and c) above. As described in [RFC4664], the second model for VPLS-PE contains a single bridge module supporting all the VPLS instances on that PE where each VPLS instance is represented by a unique VLAN inside that bridge module (also known as Service VLAN or S-VLAN). The bridge module has at least a single "Emulated LAN" interface over which each VPLS instance is represented by a unique S-VLAN tag. Each VPLS instance can consist of a set of PWs and its associated forwarder corresponding to a single Virtual LAN (VLAN) as depicted in the following Figure 1.1. Thus, sometimes it is referred to as V-LAN emulation. +----------------------------------------+ | +---------------+ +------+ | | | | |VPLS-1|------------ | | |==========|Fwdr |------------ PWs -------| Bridge ------------ |------------ | | Module | S-VLAN-1 +------+ | | | (802.1ad | o | | | bridge) | o | -------| | S-VLAN-n +------+ | ^ | | ------------VPLS-n|------------- | | | |==========| Fwdr |------------- PWs | | | | ^ | |------------- | | +---------------+ | +------+ | | +-------------------------|--------------+ | | PE VPLS UNI LAN emulation Interface Figure 1.1: VPLS PE Model Figure 1.2 describes the H-VPLS model, in a manner similar to Figure 1.1. +--------------------+ +---------------------+ | +------+ +----+| | +------+ +----+ | | | | LAN | PW || Spoke | | | LAN |VPLS|------ PWs -----| |-----|Fwdr|----------| |-----|Fwdr|------ | |Bridge| i/f +----+| PW | |Bridge| i/f +----+ | | |Module| | | |Module| | -----| | | | | | | | | | | | | | | | +------+ Spoke PE | | +------+ Core PE | +--------------------+ +---------------------+ Mohan, et. al. Expires: January 2009 [Page 5] Internet-Draft VPLS OAM July 2008 Figure 1.2: H-VPLS PE Model 2.1. VPLS as Bridged LAN Service The most common definition for VPLS is as an end-to-end bridged LAN service over one or more networks, some of which are MPLS/IP networks. The VPLS-capable PEs provide end-to-end virtual LAN service to connecting CEs by performing bridging functions (either full or a subset) as described in the [RFC4664]. To check the end-to-end service integrity, the monitoring points are located at the PE VPLS UNI within a VPLS-capable PE (PE VPLS UNI is shown in Figure 1.1). Since the service offered is Ethernet, Ethernet service level OAM mechanisms are needed. This solution proposes these Ethernet mechanisms to be based on IEEE standards and ITU-T standards as described in [802.1ag] and [Y.1731] respectively. 2.2. VPLS as (V)LAN Emulation In this context, VPLS only refers to the full mesh of PWs with split horizon and its associated forwarders that emulate a (V)LAN segment over MPLS/IP network for a given service instance, as shown in Figure 1.1 and 1.2. The OAM mechanisms in this context refer primarily to integrity check of the forwarders and full mesh of PWs and the ability to detect partial mesh failure. The recovery from partial mesh failures is based on the PSN specific mechanisms. To check the integrity of (V)LAN emulation, the monitoring points can be located at the LAN emulation interface of the Bridge Module in reference to Figure 1.1 and 1.2. The solution proposed for monitoring the (V)LAN Emulation is Ethernet mechanisms based on [Y.1731] and [802.1ag]. Section 5 also specifies the operational guidance on how to combine VPLS OAM and transport OAM for IP/MPLS PSN to provide a comprehensive end-to-end OAM solution, where PSN transport OAM can be applied to further perform the fault localization within the PSN domain. 3. VPLS OAM Solution Overview End-to-end VPLS service can span across different types of L2VPN networks. These include [IEEE 802.1ad] based bridged networks as described in section 11 of [RFC4762], [IEEE 802.1ah] based bridged network as described in [PBB-VPLS-IWK], or IP/MPLS networks in the core or access. Therefore, it is important that the VPLS OAM solution can be applied across all these network types. It is Mohan, et. al. Expires: January 2009 [Page 6] Internet-Draft VPLS OAM July 2008 important to ensure that the VPLS OAM mechanisms are independent of the underlying transport mechanisms and solely rely on the VPLS service defined in Section 2. Figure 2 shows an example of a VPLS service (with two CEs belonging to customer A) across a service provider network marked by UPE and NPE devices. Figure 2(A) shows all devices involved in the network, including CE, UPE, NPE, P and B devices. P devices are not expected to have any VPLS service visibility, while B devices are bridges in [802.1ad] or [802.1ah] access network with Ethernet service/network awareness. Figure 2(B) shows the service/network view at the Ethernet layer marked by E. Figure 2(B) highlights that only devices with Ethernet functionality are visible to VPLS service layer, and therefore are relevant to VPLS service OAM. --- --- / \ ------ ------- ---- / \ | A CE-- / \ / \ / \ --CE A | \ / \ / \ / \ / \ / \ / --- --UPE NPE NPE UPE-- --- \ / \ / \ / \ / \ / \ / ------ ------- ---- (A) CE----UPE--B-----NPE---P--P---NPE---P----UPE----CE (B) E------E---E------E------------E----------E-----E Figure 2: VPLS specific device view Figure 3 depicts three OAM domains. 3(A) represents customer domain which is among the CEs of a given customer. 3(B) represents service provider domain which is among the edge PEs of the given service provider. 3 (C) represents network operator domain which is among the PEs of a given operator. Of course the roles of Service Provider and Operator may be coincident. However, both end-to-end and segment monitoring may still be required. --- --- / \ ------ ------- ---- / \ | CE-- / \ / \ / \ --CE | \ / \ / \ / \ / \ / \ / --- --UPE NPE NPE UPE-- --- \ / \ / \ / \ / \ / \ / ------ ------- ---- Customer Domain (A) |<----------------------------------------------->| Provider Domain Mohan, et. al. Expires: January 2009 [Page 7] Internet-Draft VPLS OAM July 2008 (B) |<---------------------------------->| Operator Operator Operator (C) |<--------->|<---------->|<-------->| Domain Domain Domain Figure 3: VPLS OAM Domains Figure 4 shows the logical positioning of Ethernet Maintenance End Points (MEPs) and Maintenance Intermediate Points (MIPs) within the PE devices and CE devices corresponding to different OAM domains. As can be noted, for simultaneous monitoring across different domains, more than one MEP or MIP may be present simultaneously on a given device or its interface. When such a requirement exists, Ethernet OAM allows for different Maintenance Domain (MD) Levels, which allows for hierarchical maintenance domains. 4(A) and 4(B) correspond to the device view and Ethernet aware view in the example VPLS. 4(C) represents MEPs and MIPs that are visible within the customer domain. 4(D) represents the MEPs and MIPs visible within the service provider domain. 4(E) represents the MEPs and MIPs visible within each operator domain. --- --- / \ ------ ------- ---- / \ | A CE-- / \ / \ / \ --CE A | \ / \ / \ / \ / \ / \ / --- --UPE NPE NPE UPE-- --- \ / \ / \ / \ / \ / \ / ------ ------- ---- (A) CE----UPE--B-----NPE---P------NPE---P----UPE----CE (B) E------E---E------E------------E----------E-----E Customer Domain (C) MEP---MIP--------------------------------MIP---MEP Provider Domain (D) MEP--------MIP-----------MIP-------MEP (E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP Operator Operator Operator Domain Domain Domain Figure 4: VPLS OAM Domains, MEPs & MIPs When simultaneous MEPs and MIPs are required on the same interface, MD Levels can be used. Within an Ethernet network, 8 different MD Levels are allowed for OAM. These 8 MD Levels are generally Mohan, et. al. Expires: January 2009 [Page 8] Internet-Draft VPLS OAM July 2008 allocated such that 7-5 can be used for Customer OAM flows, while 4- 3 can be used by Service Provider and 2-0 can be used for Operator OAM flows. As a result, in Figure 4, for UPE on left, the customer MIP can be at MD Level 6, Service Provider MEP can be at MD Level 4 and Operator MEP can be at MD Level 2. Of course, not all domains may need to be monitored simultaneously and this is dependent on the business and ownership models. In VPLS OAM, the MEPs and MIPs are identified with their Ethernet MAC addresses. Since a VPLS PE consists of a bridging component and forwarder component, the bridging components are always associated with their unique MAC addresses. When Native Service (NS) OAM is supported across PE forwarder and PWs, (V)LAN Emulation can be monitored via Down MEPs positioned at the LAN emulation interface of Bridge Module in reference to Figure 1.1 and 1.2. Figure 5 indicates the positioning of the MEPs and MIPs for monitoring end-to-end VPLS Service for H-VPLS Spoke and Core PEs. By monitoring this way, fault(s) can be localized between local Spoke PE to local Core PE, or local Core PE to remote Core PE, or remote Core PE to remote Spoke PE. PW OAM (e.g. VCCV using BFD or LSP Ping) can be used to determine if Spoke PW or Core PW are at fault. Finally, if the Spoke PW and Core PWs are functional, then PW forwarder or VPLS forwarder are the suspect locations. +---------------------+ +---------------------+ | +------+ +----+| | +------+ +----+ | | | | LAN | PW || Spoke | | | LAN |VPLS|------ Core ---<>| |-----|Fwdr|----------| |--**-|Fwdr|------ PWs | |Bridge| i/f +----+| PW | |Bridge| i/f +----+ | | |Module| | | |Module| | ---<>| | | | | | | | | | | | | | | | +------+ Spoke PE | | +------+ Core PE | +---------------------+ +---------------------+ <> MEP ** MIP Figure 5: MEPs and MIPs for end-to-end VPLS Service Monitoring Figure 6 indicates the positioning of the MEPs for monitoring (V)LAN Emulation at H-VPLS Core PEs. These MEPs are at a different (lower) MD Level than those used for monitoring End-to-end VPLS Service in Figure 5. By monitoring this way, fault(s) can be localized between local Core PE and remote Core PE. PW OAM (e.g. VCCV using BFD or LSP Ping) can be used to determine if Core PW (s) are at fault. Finally, if Core PWs are functional, then VPLS forwarder is the suspect location. This approach of monitoring (V)LAN Emulation scales much Mohan, et. al. Expires: January 2009 [Page 9] Internet-Draft VPLS OAM July 2008 better when compared to running PW OAM across each PW in a full mesh of PWs per VSI. +---------------------+ +---------------------+ | +------+ +----+| | +------+ +----+ | | | | LAN | PW || Spoke | | | LAN |VPLS|------ Core -----| |-----|Fwdr|----------| |--<>-|Fwdr|------ PWs | |Bridge| i/f +----+| PW | |Bridge| i/f +----+ | | |Module| | | |Module| | -----| | | | | | | | | | | | | | | | +------+ Spoke PE | | +------+ Core PE | +---------------------+ +---------------------+ <> MEP Figure 6: MEPs for (V)LAN Emulation Monitoring The operational steps for monitoring VPLS are further detailed out in Section 5. MEP and MIP MAC addresses are unique within the VPLS OAM domains identified above. Ethernet OAM used for VPLS Service OAM and optionally for VPLS full-mesh PW monitoring can use either Unicast Destination MAC addresses or well-defined Group MAC addresses. CCM frames can use Group MAC addresses defined in [802.1ag] or Unicast MAC addresses. LBM frames can use Unicast MAC address or Group MAC addresses defined in [802.1ag] as their destination address, while LBR messages always use Unicast destination MAC addresses. The Destination Address for AIS messages can also be either Unicast or Group MAC address, as defined in [802.1ag]. LTM frames also support both Unicast and Group MAC address for Destination Address. LTR frames always carry Unicast destination address. [Y.1731] provides a complete list of addressing scheme for different Ethernet OAM frame types. Addressing for OAM frames used in this document will be specified in compliance with [802.1ag] and [Y.1731]. 4. VPLS OAM Solution The OAM solution provided in this document provides solutions to meet the VPLS OAM requirements identified in [L2VPN-OAM-REQ-FRMK]. The OAM mechanisms are based on [Y.1731] and [802.1ag]. 4.1. Discovery Mohan, et. al. Expires: January 2009 [Page 10] Internet-Draft VPLS OAM July 2008 (R1) VPLS OAM MUST allow a VPLS service aware device to discover other devices that share the same VPLS service instance(s) within a given OAM domain. This functionality is used to support discovery of PE devices within the VPLS service instances where monitoring points have been provisioned. For this purpose, multicast Loopback as described in Section 7.2.2 of [Y.1731] should be used. Multicast Loopback is implemented using the LBM and LBR message types described in Section 9.3 and 9.4 of [Y.1731] and Section 21.7 of [802.1ag]. Multicast Loopback is intended to be used between MEPs and does not involve MIPs. Any MEP configured at the end-point of a VPLS OAM domain can use the multicast Loopback to solicit responses from all peer MEPs in that VPLS service instance. CCMs may be used for discovery, though when CCMs are also used for the purposes of fault detection, it is required that MEPs have information about the peer MEP IDs expected in that Service Instance. BGP auto-discovery is used to discover the PEs in a VPLS instance and set up VPLS service instances. VPLS OAM discovery mechanism may be used to validate that all monitoring end-points within the VPLS service are present such that appropriate OAM operations, e.g. fault detection, can be granted. 4.2. Connectivity Fault Management 4.2.1. Connectivity Fault Detection (R2a) VPLS OAM MUST allow pro-active connectivity monitoring between two VPLS service aware devices that support the same VPLS service instance within a given OAM domain. For this purpose, the Continuity Check as described in Section 7.1 of [Y.1731] and Section 20.1 of [802.1ag] should be used. Continuity Check is implemented using the CCM message type described in Section 9.2 of [Y.1731] and Section 21.6 of [802.1ag]. CCM messages are typically intended to be used between MEPs and do not always involve MIPs. CCM messages allow for different periodicity (allowed values are 3.3ms, 10ms, 100ms, 1s, 10s, 1min, and 10min). The CCM transmission period must be the same across all MEPs of a single service instance in an MD, though it can be different for different service instances. The periodicity of CCM frames allows for achieving the desired fault detection targets. Typically, if sub-50ms fault detection is a requirement, then 10ms periodicity of CCMs is desirable. However, if Mohan, et. al. Expires: January 2009 [Page 11] Internet-Draft VPLS OAM July 2008 fault detection target is sub-second, CCMs can be run at 100ms. Therefore, it is expected that for premium VPLS services, which have requirement to offer faster fault detection (e.g. 100ms), allowing for faster restoration actions, CCMs can be run faster. Given that VPLS is typically a multipoint service, using CCMs with the Group MAC destination address allows for optimization of OAM frames transmitted per MEP when compared to using multiple point-to- point associations to realize full multipoint connectivity monitoring. Also, CCMs allow detecting misconnections within a VPLS service instance. Across the VPLS network layer, where the full mesh of PWs realizes the LAN emulation per VPLS instance, an incoming Multicast CCM frame needs to be replicated. However, this replication behavior is no different from replicating a typical multicast data frame and, thus, is completely transparent to the Ethernet OAM process. Therefore, CCMs offer a comprehensive solution for VPLS service level fault detection while imposing no additional overhead across VPLS Network layer. 4.2.2. Connectivity Fault Verification (R2b) VPLS OAM MUST allow connectivity fault verification between two VPLS service aware devices that support the same VPLS service instance within a given OAM domain. For this purpose, Unicast Loopback as described in Section 7.2.1 of [Y.1731] and Section 20.2 of [802.1ag] should be used. Unicast Loopback is implemented using the Unicast LBM and Unicast LBR message types described in Section 9.3 and 9.4 of [Y.1731] and Section 21.7 of [802.1ag]. LBM/LBR frames can be exercised between a MEP and a target MIP or MEP in the same VPLS service instance. LBM/LBR frames also allow for verifying the end-to-end MTU support using an optional Data TLV. 4.2.3. Connectivity Fault Localization (R2c) VPLS OAM MUST allow connectivity fault localization between two VPLS service aware devices that support the same VPLS service instance within a given OAM domain. For this purpose, Linktrace as described in Section 7.3 of [Y.1731] and Section 20.3 of [802.1ag] should be used. Linktrace is implemented using the LTM and LTR message types described in Sections 9.5 and 9.6 of [Y.1731] and Sections 21.8 and 21.9 of [802.1ag]. LTM/LTR frames are exercised between a MEP and any target MAC address which could be a MIP or MEP in the same Maintenance Domain, or a MAC address outside the OAM domain (e.g. customer domain MAC). Mohan, et. al. Expires: January 2009 [Page 12] Internet-Draft VPLS OAM July 2008 However, the LTM or LBM messages do not leak outside the OAM domain bounded by MEPs belonging to that Service Instance. LTM/LTR frames allow the path from a MEP to a target MAC to be traced under normal conditions and in failure scenarios, it allows for the location of the fault to be identified, since the last LTR response indicates the penultimate point before the failure with Ethernet layer awareness. 4.2.4. Connectivity Fault Notification (R2d) VPLS OAM MUST allow forwarding of transport/network fault notification by and to VPLS service aware devices that support VPLS service instances affected by the fault. For this purpose, the Alarm Indication Signal (AIS) as described in Section 7.4 of [Y.1731] may be used. The Alarm Indication Signal is implemented using the AIS message type described in Section 9.7 of [Y.1731]. As an example, the AIS mechanism allows for a failure detected in an Operator Domain to be communicated to a Service Provider Domain or Customer Domain. As fault detection may be faster within the Operator domain than the Service Provider domain, AIS communication provides a more rapid fault sectionalization capability. The use of AIS is only applicable for a limited set of network architectures; the reader should refer to [Y.1731]. This mechanism does not preclude other mechanisms, such as fault sectionalization based on coordinated network management, from also being used. 4.3. Frame Loss (R3) VPLS OAM MUST support measurement of per-service frame/packet loss between two VPLS service aware devices that support the same VPLS service instance within a given OAM domain. For this purpose, statistical sampling based on Unicast Loopback as described in Section 7.2.1 of [Y.1731] and Section 20.2 of [802.1ag] may be used. Unicast Loopback is implemented using the Unicast LBM and Unicast LBR message types described in Section 9.3 and 9.4 of [Y.1731] and Section 21.7 of [802.1ag]. For this purpose, it is expected that such measurements are carried out among the MEPs of a VPLS service instance and do not involve MIPs. The results of the statistical sampling can be communicated via LMM/LMR mechanism specified in Section 8.1.2 of [Y.1731] on a pair-wise basis, to allow single-ended measurement of the sample results. Mohan, et. al. Expires: January 2009 [Page 13] Internet-Draft VPLS OAM July 2008 4.4. Frame Delay (R4a) VPLS OAM MUST support measurement of per-service two-way frame/packet delay between two VPLS service aware devices that support the same VPLS service instance within a given OAM domain. For this purpose, single-ended (aka two way) delay measurement as described in Section 8.2.2 of [Y.1731] should be used. Two-way delay measurement is implemented using the DMM and DMR message types described in Section 9.15 and 9.16 of [Y.1731]. It is expected that such measurements are carried out among the MEPs of a VPLS service instance and do not involve MIPs. (R4b) VPLS OAM SHOULD support measurement of per-service one-way frame/packet delay between two VPLS service aware devices that support the same VPLS service instance within a given OAM domain. For this purpose, the clocks must be synchronized between the two nodes that are interested in performing one-way delay measurements. If the clocks are synchronized, one-way delay measurement as described in Section 8.2.1 of [Y.1731] should be used. One-way delay measurement is implemented using the 1DM message type described in Section 9.14 of [Y.1731]. Again, it is expected that such measurements are carried out among the MEPs of a VPLS service instance and do not involve MIPs. 4.5. Frame Delay Variation (R5) VPLS OAM MUST support measurement of per-service frame/packet delay variation between two VPLS service aware devices that support the same VPLS service instance within a given OAM domain. Frame delay variation can be measured based on different samples of frame delay using the mechanisms described in section 4.4. 4.6. Availability No specific OAM mechanisms are needed for availability besides those already specified for Frame Loss, Frame Delay and Frame Delay Variation. 4.7. Data Path Forwarding (R6) VPLS OAM frames MUST be forwarded along the same path (i.e. links and nodes) as the VPLS service/data frames. Mohan, et. al. Expires: January 2009 [Page 14] Internet-Draft VPLS OAM July 2008 Since Ethernet OAM frames, as described in [Y.1731] and [802.1ag], for VPLS Service instance appear to the VPLS components as regular VPLS service frames, these OAM frames are forwarded in the same manner as VPLS service frames. Therefore, this requirement is easily met by the solution that is based on Ethernet OAM. 6.8. Scalability (R7) VPLS OAM MUST be scalable such that a VPLS service aware device can support OAM for each VPLS service that is supported by the device. Since Ethernet OAM is optimized for multipoint environments, and is not limited to using the point-to-point OAM relationships, typical O(n-square) issues presented by point-to-point based solutions are not encountered. Use of Ethernet OAM therefore allows VPLS OAM to scale for a large number of services. 4.9. Extensibility (R8a) VPLS OAM MUST be extensible such that new functionality and information elements related to this functionality can be introduced in the future. Ethernet OAM mechanisms allow for the following extensible features: - New Opcodes can be defined - Experimental and Vendor Specific Opcodes are already defined in [Y.1731] - Organizationally specific TLVs can be added to most message types As a result, the solution proposed here based on Ethernet OAM is extensible. (R8b) VPLS OAM MUST be defined such that devices not supporting the OAM are able to forward the OAM frames in a similar fashion as the regular VPLS service/data frames/packets. Ethernet OAM has been defined such that it is backward compatible. Devices that do not support Ethernet OAM will continue to forward the OAM frames as they would forward regular data frames. As such, devices that do not support Ethernet OAM do not disrupt the OAM functionality. 4.10. Security Mohan, et. al. Expires: January 2009 [Page 15] Internet-Draft VPLS OAM July 2008 (R9a) VPLS OAM frames MUST be prevented from leaking outside their OAM domain. (R9b) VPLS OAM frames from outside an OAM domain MUST be prevented from entering the OAM domain when such OAM frames belong to the same level or lower-level OAM domain. (R9c) VPLS OAM frames from outside an OAM domain MUST be transported transparently inside the OAM domain when such OAM frames belong to any higher-level OAM domain. All these requirements are met with the Ethernet OAM based solution, since Ethernet OAM allows for MEG Levels as described in Section 5.6 of [Y.1731] and equivalent MD Levels as described in Section 3.27 of [802.1ag]. As a result, OAM domains which are bounded by MEPs having the same MD Level as the OAM domain, behave such that all OAM frames entering or leaving the OAM domain with MD Level higher than configured MEPs are allowed to pass through, while all other OAM frames are filtered. 4.11. Transport Independence (R10a) VPLS OAM MUST be independent of the underlying transport/network technologies and specific transport/network OAM capabilities. Ethernet OAM, when used for VPLS Service Management, is able to operate independent of the underlying transport specifics. The solution defined here for VPLS Service OAM and optionally for PW Mesh monitoring, is independent of the type of PSN layer (e.g. it can be MPLS, MPLS-IP or L2TP). Further, the solution is also independent of the type of access network deployed for the VPLS (e.g. can be 802.1ad, 802.1ah, or MPLS) service. More specifically, the transport layers can be monitored via their native OAM techniques - e.g. [VCCV] for PWs or [LSP-Ping] for MPLS PSN - and the solution can co-exist without any interoperability issues. (R10b) VPLS OAM MAY allow adaptation/interworking with specific transport/network OAM functions. For example, this would be useful to allow Fault Notifications from transport/network layer(s) to be sent to the VPLS service layer. In scenarios where PEs do not support Native Service (NS) OAM over PWs (which in context of VPLS means Ethernet OAM support across the PW Forwarder component), interworking of defect states, as specified in [MPLS-ETH-OAM-IWK], may be applied. Mohan, et. al. Expires: January 2009 [Page 16] Internet-Draft VPLS OAM July 2008 4.12. Application Independence (R11a) VPLS OAM MUST be independent of the client layer application technologies and specific application OAM capabilities. The solution defined in this document is independent of the application technologies and application OAM capabilities. This is possible since Ethernet OAM has well-defined MD Levels that are realized within each Ethernet layer. Therefore, if a customer's service frames ingress the VPLS domain as C-tagged frames and get encapsulated in [802.1ad] access network as S-tagged frames, the customer is able to run 8 MD Levels independently from the access network. As another example, application independence holds true if the customer is running IP layer Ping or Traceroute, which is transparent to the Service Provider domains since customer service frames always appear as Ethernet frames to a VPLS service instance. 5. VPLS OAM Operational Steps This section specifies how the solution defined in this document can be used across a VPLS Service Instance and optionally across a VPLS PW full-mesh, while also working with a VPLS network layer realized via MPLS, MPLS-IP, or L2TP PSNs. --- --- / \ ------ ------- ---- / \ | A CE-- / \ / \ / \ --CE A | \ / \ / \ / \ / \ / \ / --- --UPE NPE NPE UPE-- --- \ / \ / \ / \ / \ / \ / ------ ------- ---- Customer domain (C) MEP---MIP--------------------------------MIP---MEP SP domain (D) MEP--------MIP-----------MIP-------MEP SP domain SP domain SP domain (D1) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP Op domain Op domain Op domain (E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP PSN domain PSN domain (F) MEP--MIP-----MEP--MIP--MEP Mohan, et. al. Expires: January 2009 [Page 17] Internet-Draft VPLS OAM July 2008 Figure 5: VPLS OAM Domains, MEPs & MIPs Referring to Figure 5 above, for VPLS OAM in the Customer OAM domain (5C), [802.1ag] and [Y.1731] Ethernet OAM mechanisms can be applied to meet the requirements identified in Section 4. Similarly, inside the Service Provider (SP) OAM domain (5D), [802.1ag] and [Y.1731] Ethernet OAM mechanisms can be applied to meet functional requirements identified in Section 4. Inside the Operator (Op) OAM domain (5E), [802.1ag] and [Y.1731] Ethernet OAM mechanisms can also be applied to meet functional requirements identified in Section 4. In addition, the network operator could decide to use native OAM mechanisms e.g. [VCCV] across Figure 5(F) MAs for additional monitoring or as an alternative to monitoring across Figure 5(E). It maybe noted that unlike Ethernet OAM though, other OAM techniques do not always support both end-point and intermediate monitoring points. Therefore, the recommended operational steps include the following: - Manage the VPLS Service Monitoring via Ethernet OAM as explained above in different VPLS Service OAM domains (i.e. Customer, SP, and Operator) - When NS OAM capability is supported across PWs, also monitor the (V)LAN emulation (i.e. forwarders and full-mesh of PWs realized for VPLS service instance) via Ethernet OAM. This is achieved via using Down MEPs associated with the Bridging component on PE devices, and representing each VPLS forwarder component on every PE device in the VPLS instance. When PW full-mesh monitoring is used via Ethernet OAM, the rate of detection of failures in full- mesh should be faster than the rate of failure detection for VPLS service. This would allow the PW partial mesh failures to be detected and hopefully restored before the VPLS service layer detects and reports connectivity issues. - When VPLS Service related problems are detected, attempt to verify and/or localize the defect. This is done via LBM/LBR and/or LTM/LTR. - After the defect segment has been isolated, launch diagnostic tools natively available across the PSN layer. For example, the defect may show up in a VPLS-emulated LAN network (i.e., the VPLS network layer implemented using a PSN such as MPLS, MPLS-IP, or L2TP). This allows for limiting the use of PSN OAM tools when the fault detection is done using Ethernet OAM. This, in turn, addresses scalability and computational concerns associated with some CPU intensive tools such as [LSP-Ping], since those would be used only when required. This also avoids constantly running [VCCV] with [BFD] payload. [VCCV] with [BFD] scales better than [LSP-Ping], but still requires [LSP-Ping] for bootstrapping and other OAM functionality. Mohan, et. al. Expires: January 2009 [Page 18] Internet-Draft VPLS OAM July 2008 Refer to Appendix A for the case when the PE does not support NS OAM capability across PWs. 6. Acknowledgments The authors would like to thank Samer Salam for his valuable contributions. 7. IANA Considerations This document has no actions for IANA. 8. Security Considerations This document does not impose any security concerns since it makes use of existing OAM mechanisms and mapping of these messages does not change inherent security features. 9. Intellectual Property Considerations This document is being submitted for use in IETF standards discussions. 10. References 10.1 Normative References [Y.1731] "OAM Functions and mechanisms for Ethernet based networks", ITU-T Y.1731, February 2008 [RFC4762] "Virtual Private LAN Service (VPLS) using Label Distribution Protocol (LDP)", RFC 4762, Jan 2007 [802.1ad] "Provider Bridges", IEEE 802.1ad, Dec 2005 [802.1ag] "Connectivity Fault Management", IEEE 802.1ag, Nov 2007 [LSP-Ping] "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, Feb 2006 [VCCV] "Pseudowire Virtual Circuit Connectivity Verification", RFC 5085, Dec 2007 Mohan, et. al. Expires: January 2009 [Page 19] Internet-Draft VPLS OAM July 2008 10.2 Informative References [RFC4664] "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, Sep 2006 [L2VPN-OAM-REQ-FRMK] "L2VPN OAM Requirements and Framework", draft- ietf-l2vpn-oam-req-frmk-11.txt, Work in progress, Oct 2010 [PBB-VPLS-IWK] "VPLS Interoperability with Provider Backbone Bridges", draft-ietf-l2vpn-pbb-vpls-interop-00.txt, Work in progress, Jan 2010 [MPLS-ETH-OAM-IWK] "MPLS and Ethernet OAM Interworking", draft- mohan-pwe3-mpls-eth-oam-iwk-01.txt, Work in progress, Jul 2008 [802.1ah] "Provider Backbone Bridges", IEEE 802.1ah, Apr 2008 [BFD] "Bidirectional Forwarding Detection", draft-ietf-bfd-base- 08.txt, Work in progress, Mar 2008 Appendix A: Ethernet and PSN OAM Interworking As noted in Section 5, when [802.1ag] and [Y.1731] capabilities are not available across all PE devices, the management option introduced in [L2VPN-OAM-REQ-FRMK] can be applied. In this option, the SP can run segment OAM across the Figure 5(D1) MAs. The OAM mechanisms across the Figure 5(D1) MEs can be non-Ethernet; e.g., [VCCV] when network technology is MPLS. The SP can monitor each sub- network segment MA using the native technology OAM and by performing interworking across the segment MEs; e.g., [MPLS-ETH-OAM-IWK]. However, such mechanisms do not fully utilize the data plane forwarding as experienced by native (i.e. Ethernet) service PDUs, and therefore monitoring is severely limited in the sense that monitoring at Figure 5(D1) and interworking across them could lead to an indication that the MA between VPLS end-points is functional, while the customer may be experiencing end-to-end connectivity issues in the data plane. Authors' Addresses Dinesh Mohan Nortel Email: dinmohan@hotmail.com Ali Sajassi Cisco 170 West Tasman Drive San Jose, CA 95134 Email: sajassi@cisco.com Mohan, et. al. Expires: January 2009 [Page 20] Internet-Draft VPLS OAM July 2008 Deborah Brungard AT&T Rm. D1-3C22-200 S. Laurel Ave. Middletown, NJ 07748, USA Email: dbrungard@att.com Henry Fowler AT&T Email: hf9857@att.com Simon Delord Alcatel-Lucent Building 3, 388 Ningqiao Road, Jinqiao, Pudong Shanghai, 201206, P.R. China Email: simon.delor@alcatel-lucent.com Philippe Niger France Telecom 2 av. Pierre Marzin 22300 LANNION, France E-mail: philippe.niger@francetelecom.com Mohan, et. al. Expires: January 2009 [Page 21]