Internet-Draft D. Mohan, Nortel L2VPN Working Group A. Sajassi, Cisco Intended status: Standards Track D. Brungard, H. Fowler, AT&T Expires: May 2008 P. Niger, France Telecom S. Delord, Uecomm November 2007 VPLS OAM draft-mohan-l2vpn-vpls-oam-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 in May 2008. Copyright Notice Copyright (C) The IETF Trust (2007). 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. Mohan, et. al. Expires: May 2008 [Page 1] Internet-Draft VPLS OAM Nov 2007 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. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Conventions used in this document..................................2 1. Introduction....................................................3 1.1 Terminology....................................................3 2. VPLS OAM Scope..................................................4 2.1. VPLS as Bridged LAN Service...................................5 2.2. VPLS as (V)LAN Emulation......................................5 3. VPLS OAM Solution Overview......................................5 4. VPLS OAM Solution...............................................8 4.1. Discovery.....................................................8 4.2. Connectivity Fault Management.................................9 4.2.1. Connectivity Fault Detection................................9 4.2.2. Connectivity Fault Verification............................10 4.2.3. Connectivity Fault Localization............................10 4.2.4. Connectivity Fault Alarm...................................10 4.3. Frame Loss...................................................11 4.4. Frame Delay..................................................11 4.5. Frame Delay Variation........................................12 4.6. Availability.................................................12 4.7. Data Path Forwarding.........................................12 6.8. Scalability..................................................12 4.9. Extensibility................................................13 4.10. Security....................................................13 4.11. Transport Independence......................................14 4.12. Application Independence....................................14 5. VPLS OAM Operational Steps.....................................14 6. Acknowledgments................................................16 7. IANA Considerations............................................16 8. Security Considerations........................................16 9. References.....................................................16 9.1 Normative References..........................................17 9.2 Informative References........................................17 Appendix A: Ethernet and PSN OAM Interworking.....................17 Authors' Addresses................................................18 Full Copyright Statement..........................................18 Intellectual Property.............................................19 Mohan, et. al. Expires: May 2008 [Page 2] Internet-Draft VPLS OAM Nov 2007 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. 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. AIS Alarm Indication Signal MD Level Maintenance Domain (MD) Level which identified 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 Mohan, et. al. Expires: May 2008 [Page 3] Internet-Draft VPLS OAM Nov 2007 and termination of OAM frames for a given MEG MIP Maintenance Intermediate Point is located between peer MEPs and can process OAM frames but does not initiate or terminate them RDI Remote Defect Indication VPLS Virtual Private LAN Service U-PE PE facing the User in H-VPLS N-PE PE facing the Network in H-VPLS 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 full-mesh 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 - 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. Thus, sometimes it is referred to as V-LAN emulation. +----------------------------------------+ | VPLS-capable PE model | | +---------------+ +------+ | | | | |VPLS-1|------------ | | |==========|Fwdr |------------ PWs -------| Bridge ------------ |------------ | | | S-VLAN-1 +------+ | | | Module | o | | | | o | | | (802.1ad | o | | | bridge) | o | | | | o | -------| | S-VLAN-n +------+ | ^ | | ------------VPLS-n|------------- | | | |==========| Fwdr |------------- PWs | | | | ^ | |------------- Mohan, et. al. Expires: May 2008 [Page 4] Internet-Draft VPLS OAM Nov 2007 | | +---------------+ | +------+ | | | | | | +-------------------------|--------------+ | | PE VPLS UNI LAN emulation Interface Figure 1: VPLS-capable 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). 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 [Y.1731] and [802.1ag]. 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. 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. 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 Mohan, et. al. Expires: May 2008 [Page 5] Internet-Draft VPLS OAM Nov 2007 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 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. 2(A) represents customer domain which is among the CEs of a given customer. 2(B) represents service provider domain which is among the edge PEs of the given service provider. 2 (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) |<----------------------------------------------->| Mohan, et. al. Expires: May 2008 [Page 6] Internet-Draft VPLS OAM Nov 2007 Provider Domain (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 (MIP) 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. 3(A) and 3(B) correspond to the device view and Ethernet aware view in the example VPLS. 3(C) represents MEPs and MIPs that are visible within the customer domain. 3(D) represents the MEPs and MIPs visible within the service provider domain. 3(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 layer, 8 different MD Levels are allowed for OAM. These 8 MD Levels are generally allocated such that 7-5 can be used for Customer OAM flows, while 4- Mohan, et. al. Expires: May 2008 [Page 7] Internet-Draft VPLS OAM Nov 2007 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 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. MEP and MIP Identifiers 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 DA. [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 (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]. Mohan, et. al. Expires: May 2008 [Page 8] Internet-Draft VPLS OAM Nov 2007 Multicast Loopback is intended to be used between MEPs and do 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 PE in a VPLS instance and set up VPLS service instances. VPLS OAM discovery mechanism is 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, 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 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 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 realize the LAN emulation per VPLS instance, an incoming Multicast CCM frame needs to be replicated, however, this replication behavior Mohan, et. al. Expires: May 2008 [Page 9] Internet-Draft VPLS OAM Nov 2007 is no different than replicating a typical multicast data frame and thus 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 Section 9.5 and 9.6 of [Y.1731] and Section 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. 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 localized, since the last LTR response indicates the penultimate point within Ethernet layer before the failure. 4.2.4. Connectivity Fault Alarm (R2d) VPLS OAM MUST allow forwarding of transport/network fault indications by and to VPLS service aware devices to VPLS service aware devices that support VPLS service instances affected by the fault. Mohan, et. al. Expires: May 2008 [Page 10] Internet-Draft VPLS OAM Nov 2007 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, 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. 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. Mohan, et. al. Expires: May 2008 [Page 11] Internet-Draft VPLS OAM Nov 2007 (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. Since Ethernet OAM frames, as described in [Y.1731] and [802.1ag], for VPLS Service instance appear no different 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 proposed solution which 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 the Ethernet OAM is optimized for multipoint environments, and is not limited to using the point-to-point OAM relationships, Mohan, et. al. Expires: May 2008 [Page 12] Internet-Draft VPLS OAM Nov 2007 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 the data frames, which allows for the backward compatibility such that devices not supporting Ethernet OAM do not disrupt the regular OAM functionality. 4.10. Security (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 an 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. Mohan, et. al. Expires: May 2008 [Page 13] Internet-Draft VPLS OAM Nov 2007 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 independently. The solution proposed 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 problems. (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. 4.12. Application Independence (R11a) VPLS OAM MUST be independent of the client layer application technologies and specific application OAM capabilities. The solution proposed 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, this is true if the customer is running IP layer Ping or Traceroute, which is invisible 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 proposed in this document can be used across a VPLS Service Instance and optionally across a Mohan, et. al. Expires: May 2008 [Page 14] Internet-Draft VPLS OAM Nov 2007 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 Figure 5: VPLS OAM Domains, MEPs & MIPs Among the different MEs identified in Figure 5, for VPLS OAM in the Customer OAM domain, [802.1ag] and [Y.1731] Ethernet OAM mechanisms can be applied to meet various requirements identified in Section 4. The mechanisms can be applied across Figure 5(C) MAs. Similarly, inside the Service Provider (SP) OAM domain, [802.1ag] and [Y.1731] Ethernet OAM mechanisms can be applied across Figure 5(D) MAs to meet functional requirements identified in Section 4. Inside the Operator (Op) OAM domain, [802.1ag] and [Y.1731] Ethernet OAM mechanisms can also be applied across Figure 5(E) MAs 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) MAs. 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: Mohan, et. al. Expires: May 2008 [Page 15] Internet-Draft VPLS OAM Nov 2007 - 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 limiting the use of PSN OAM tools when the fault detection is done using Ethernet OAM. This also allows for dealing with scalability and computational concerns associated with some CPU intensive tools such as [LSP-Ping], to being 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. Refer to Appendix A for the case when the PE does not support NS OAM capability across PWs. 6. Acknowledgments To be completed later. 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. References Mohan, et. al. Expires: May 2008 [Page 16] Internet-Draft VPLS OAM Nov 2007 9.1 Normative References [Y.1731] "OAM Functions and mechanisms for Ethernet based networks", ITU-T Y.1731, May 2006 [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/D8.1, Aug 2007 [LSP-Ping] "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, Feb 2006 9.2 Informative References [L2VPN-OAM-REQ-FRMK] "L2VPN OAM Requirements and Framework", draft- ietf-l2vpn-oam-req-frmk-09.txt, Work in progress, Sep 2007 [PBB-VPLS-IWK] "VPLS Interoperability with Provider Backbone Bridges", draft-sajassi-l2vpn-vpls-pbb-interop-01.txt, Work in progress, Jul 2007 [MPLS-ETH-OAM-IWK] "MPLS and Ethernet OAM Interworking", draft- mohan-pwe3-mpls-eth-oam-iwk-00.txt, Work in progress, Nov 2007 [802.1ah] "Provider Backbone Bridges", IEEE 802.1ah/D3.8, Oct 2007 [BFD] "Bidirectional Forwarding Detection", draft-ietf-bfd-base- 06.txt, Work in progress, Mar 2007 [RFC4664] "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, Sep 2006 [VCCV] "Pseudowire Virtual Circuit Connectivity Verification", draft-ietf-pwe3-vccv-15.txt, Sep 2007 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, Mohan, et. al. Expires: May 2008 [Page 17] Internet-Draft VPLS OAM Nov 2007 while the customer may be experiencing end-to-end connectivity issues in the data plane. Authors' Addresses Dinesh Mohan Nortel 3500 Carling Ave Ottawa, ON K2H8E9 Email: mohand@nortel.com Ali Sajassi Cisco 170 West Tasman Drive San Jose, CA 95134 Email: sajassi@cisco.com 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 Uecomm 658 Church St Richmond, VIC, 3121, Australia E-mail: sdelord@uecomm.com.au Philippe Niger France Telecom 2 av. Pierre Marzin 22300 LANNION, France E-mail: philippe.niger@francetelecom.com Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL Mohan, et. al. Expires: May 2008 [Page 18] Internet-Draft VPLS OAM Nov 2007 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.