Internet Draft Document Ali Sajassi Layer-2 VPN Working Group Cisco Systems draft-sajassi-mohan-l2vpn-vpls-fm-00.txt Dinesh Mohan Nortel Networks Norm Finn Shahram Davari Thomas Nadeau PMC Sierra Monique Morrow Cisco Systems Vasile Radoaca Nortel Networks Expires: November 2004 March 2004 Fault Management for Virtual Private LAN Services draft-sajassi-mohan-l2vpn-vpls-fm-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 2. Abstract 3. 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 Placement of this Memo in Internet Area RELATED DOCUMENTS Sajassi, Mohan et al. [Page 1] Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004 http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls- requirements-00.txt http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-l2-framework- 03.txt http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-01.txt WHERE DOES THIS FIT IN THE PICTURE OF THE Internet WORK L2VPN WHY IS IT TARGETED AT THIS WG This draft describes Fault Management mechanisms/procedures for VPLS which is a Layer-2 VPN. JUSTIFICATION This draft describes Fault Management mechanisms/procedures for VPLS which is a Layer-2 VPN. Table of Contents 1. Status of this Memo.............................................1 2. Abstract........................................................1 3. Conventions.....................................................1 4. Overview........................................................3 5. Layering........................................................4 5.1. OAM Domains...................................................5 5.2. Maintenance & Intermediate Points.............................6 5.2.1. Maintenance and Intermediate Points IDs.....................8 6. Fault Management Mechanisms.....................................8 6.1. Fault Detection...............................................8 6.2. Fault Verification...........................................10 6.3. Fault Isolation..............................................10 7. Fault Management Messages......................................11 7.1. Generic Ethernet OAM Frame - Header Information..............11 7.2. Generic Ethernet OAM Frame û OAM Body Information............12 7.3. Continuity Check.............................................12 7.4. Loopback.....................................................13 7.5. TraceRoute...................................................13 7.5.1. TraceRoute Request Format..................................13 7.5.2. TraceRoute Reply Format....................................13 8. Acknowledgments................................................14 9. Security Considerations........................................14 Sajassi, Mohan et al. [Page 2] Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004 10. Intellectual Property Considerations..........................14 11. Full Copyright Statement......................................14 12. References....................................................15 13. Authors' Addresses............................................15 4. Overview The Scope of network management functionality (aka OAM&P: Operation, Administration, Maintenance, and Provisioning) for any network technology is very broad in nature OSI has defined the following five generic functional areas for network management, commonly abbreviated as ôFCAPSö [NM-Standards]: Fault Management (FM), Performance Management, Configuration Management, Accounting Management, and Security Management. This draft only deals with Fault Management aspects of OAM&P for VPLS and defines mechanisms and procedures for it. Performance management aspects of OAM&P for VPLS are addressed in a companion draft [PM- MOHAN-SAJASSI]. Fault Management can further be sub-divided into the following categories: - Fault Detection - Fault Verification - Fault Isolation - Fault Notification - Fault Recovery Fault Detection deals with mechanism(s) that can detect both hard failures, such as link and node failures, and soft failures, such as software failure, memory corruption, mis-configuration, etc. Typically a lightweight protocol is desirable to detect the fault and thus it would be prudent to verify the fault via Fault Verification mechanism before taking additional steps in isolating the fault. After verifying that a fault has occurred along the data path, it is important to be able to isolate the fault to a given node or link (e.g., diagnose the fault). Therefore, a Fault Isolation mechanism is needed in Fault Management. Fault Notification mechanism can be used in conjunction with Fault Detection mechanism to notify the upstream and downstream nodes of a fault. Finally, Fault Recovery deals with recovering from the detected failure by switching to an alternate available node or link (e.g., node redundancy or link redundancy). The scope of this draft is limited to the first three aspects of the Fault Management, i.e. Fault Detection, Fault Verification and Fault Isolation, in the context of provider networks. Sajassi, Mohan et al. [Page 3] Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004 This document first starts off with a description and a reference model for OAM layering and furthermore emphasizes the importance of proper independent layering in design and development of OAM functionality. Next it describes mechanisms and procedures for fault detection, verification, and isolation for VPLS. This proposal is aligned with the current discussions in other standard bodies such as ITU-T Q3/13, IEEE 802.1, and MEF which are addressing OAM for both Ethernet-based services and Ethernet-based networks. 5. Layering As defined in [L2-FRWK], Virtual Private LAN Service is a bridged LAN service provided to a set of CEs that are members of a VPN. The CEs that are member of the same VPN (e.g., the same VPLS instance) communicate with each other as if they are connected via a bridged LAN. The bridged LAN functionality is emulated by a network of PEs to which the CEs are connected. This network of PEs can belong to a single network operator or can span across multiple network operators. Furthermore, it can belong to a single service provider or can span across multiple service providers. A service provider is responsible for providing VPLS services to its customers; whereas, a network operator (aka facility provider) provides the necessary facilities to the service provider(s) in support of their services. A network operator and a service provider can be the same entity or they can be different administrative organizations. When discussing the fault management mechanisms for VPLS, it is important to consider that the end-to-end service can span across different types of VPLS networks. As an example, in case of [VPLS- LDP], the access network on one side can be bridged network e.g. [IEEE 802.1ad], as described in section 11 of [VPLS-LDP]; whereas, the access network on other side can be MPLS based as described in section 10 of [VPLS-LDP]; and the core network connecting them can be IP, MPLS, ATM, or SONET. Similarly, the VPLS service instance can span across distributed VPLS as described in [VPLS-ROSEN]. Therefore, it is important that the fault management mechanisms can be applied to all these network types. Each such network may be associated with a separate administrative domain and also multiple such networks may be associated with a single administrative domain. Different types of pseudo wires may be in use to support end-to-end VPLS. Therefore, for VPLS fault management, it is important to ensure that the fault management mechanisms for VPLS are independent Sajassi, Mohan et al. [Page 4] Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004 of the underlying transport mechanisms (e.g., 802.3, MPLS, IP, ATM, SONET, etc.) and solely rely on Ethernet MAC layer. As shown in Figure 1, an example of VPLS service is shown across a service provider network marked by UPE and NPE devices. The customer A is represented by CE devices across its different sites. The service provider network is segmented into core network and two types of access network. Figure 1(A) shows the bridged access network represented by its bridge components marked ôBö, and the MPLS access and core network represented by MPLS components marked ôPö. Figure 1(B) shows the service/network view at the Ethernet MAC layer marked by ôEö. --- --- / \ ------ ------- ---- / \ | A CE-- / \ / \ / \ --CE A | \ / \ / \ / \ / \ / \ / --- --UPE NPE NPE UPE-- --- \ / \ / \ / \ / \ / \ / ------ ------- ---- (A) CE----UPE--B--B--NPE---P--P---NPE---P----UPE----CE (B) E------E---E--E---E------------E----------E-----E Figure 1 As shown in Figure 1(B), only the nodes with Ethernet functionality are visible to Fault Management mechanisms operating at Ethernet MAC layer and the P nodes are invisible. Therefore, the fault management along the path of P nodes (e.g., between two PEs) is covered by transport layer FM (e.g., MPLS FM) and it is outside the scope of this document. 5.1. OAM Domains As described in the previous section, a VPLS instance for a given customer can span across one or more service providers and network operators. Therefore, when discussing OAM tools for VPLS, e.g. fault management, it is important to provide OAM capabilities and functionality over each domain that a service provider or a network operator is responsible for. For these reasons, it is also important that OAM messages are not allowed to enter/exit other domains. We define an OAM domain as a network region over which OAM messages operate unobstructed as explained below. At the edge of an OAM domain, filtering constructs should prevent OAM messages from exiting and entering that domain. FM domains can Sajassi, Mohan et al. [Page 5] Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004 be nested but not overlapped. In other words, if there is a hierarchy of the FM domains, the FM messages of a higher-level domain pass transparently through the lower-level domains but the FM messages of a lower-level domain get blocked/filtered at the edge of that domain. In order to facilitate the processing of FM messages, we associate each domain with a one-octet level at which it operates. Domains with larger level numbers can contain domain with smaller level numbers but the converse is not true. A PE can be part of several domains with each interface belonging to same or different domains. A PE shall block outgoing FM messages and filter out incoming messages whose domain level is lower or equal to the one configured on that interface and pass through the messages whose domain level is greater than the one configured on that interface. Figure 2 depicts three domains: (A) customer domain which is among the CEs of a given customer, (B) service provider domain which is among the edge PEs of the given service provider, and (C) network operator domain which is among the PEs of a given operator. --- --- / \ ------ ------- ---- / \ | CE-- / \ / \ / \ --CE | \ / \ / \ / \ / \ / \ / --- --UPE NPE NPE UPE-- --- \ / \ / \ / \ / \ / \ / ------ ------- ---- (A) |<----------------------------------------------->| customer (B) |<---------------------------------->| provider (C) |<--------->|<----------->|<-------->| operator operator operator Figure 2 5.2. Maintenance & Intermediate Points Maintenance points are responsible for origination and termination of OAM/FM messages. Maintenance points are located at the edge of their corresponding domains. Intermediate points are located within their corresponding domains and they can process and respond to OAM Sajassi, Mohan et al. [Page 6] Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004 messages but they never initiate them. Since Maintenance points are located at the edge of their domains, they are responsible for filtering outbound OAM messages from leaving the domain or inbound OAM messages from entering the domain. Maintenance and intermediate points correspond to a PE or more specifically to an interface of a PE. For example, an OAM/FM message can be said to originate from an ingress PE or more specifically an ingress interface of that PE. Since domains are hierarchical as described above, the maintenance and intermediate points that are associated with the domains become hierarchical as well. A maintenance point of a higher-level domain is always a maintenance point of a lower-level domain but the converse is not always true since the maintenance point of lower- level domain can either be intermediate point or a maintenance point of a higher-level domain. Furthermore, the intermediate points of a lower-level domain are always transparent to the higher-level domain (e.g., OAM/FM messages of a higher-level domain are not seen by intermediate points of a lower-level domain and get passed through them transparently). --- --- / \ ------ ------- ---- / \ | A CE-- / \ / \ / \ --CE A | \ / \ / \ / \ / \ / \ / --- --UPE NPE NPE UPE-- --- \ / \ / \ / \ / \ / \ / ------ ------- ---- (A) CE----UPE--B--B--NPE---P--P---NPE---P----UPE----CE (B) E------E---E--E---E------------E----------E-----E (C) MP----IP----------------------------------IP---MP Customer Domain (D) MP---------IP-----------IP-------MP Provider domain (E) MP--IP--IP--MP----------MP-------MP operator operator operator domain domain domain (F) MP--IP--IP--MP--IP---MP MPLS MPLS domain domain Figure 3 Sajassi, Mohan et al. [Page 7] Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004 As shown in Figure 3, (C) represents that maintenance points and intermediate points that are visible within the customer domain. (D) represents the maintenance points and intermediate points visible within the service provider domain, while (E) represents the maintenance points and intermediate points visible within each operator domain. Further, (F) represents the maintenance points and intermediate points corresponding to the MPLS layer and may apply MPLS based mechanisms like [LSP-PING], [VCCV] etc. The MPLS layer shown in this Figure, is just an example and is outside the scope of this document. 5.2.1. Maintenance and Intermediate Points IDs As mentioned previously, VPLS OAM/FM should be independent of underlying transport layer and should dependent on Ethernet MAC layer. Therefore, at Ethernet MAC layer, the Maintenance points and Intermediate points should be identified with their Ethernet MAC addresses. As described in [VPLS-LDP], VPLS instance is identified in an Ethernet domain (e.g., 8021.d domain) using VLAN tag (service tag) while in an MPLS/IP network, PW-ids are used. Both PW-ids and VLAN tags for a given VPLS instance are associated with a globally unique service instance identifier (e.g., VPN identifier). Maintenance and Intermediate Points ID shall be unique within their corresponding domain. Ethernet frames are used for OAM/FM messages and the source MAC address of the OAM/FM frames represent the source maintenance or intermediate point in that domain. For Unicast OAM/FM frames, the destination MAC address represents the destination maintenance or intermediate point in that domain. For multicast OAM/FM frames, the destination MAC addresses correspond to all maintenance and optionally to all intermediate points in that domain. 6. Fault Management Mechanisms 6.1. Fault Detection Ethernet Continuity Check (CC) provides a means to detect both hard failures and soft failures such as software failure, memory corruption, or mis-configuration. The failure detection is achieved by each maintenance point (e.g., each edge PE) transmitting a heartbeat message periodically for each VPLS (service) instance. Therefore, each edge PE receives a set of heartbeat messages periodically from other edge PEs of that service instance. Once the local PE stops receiving the periodic heartbeats from the remote PE, it assumes that either the remote PE has failed or an unrecoverable failure on the path has happened. The PE can subsequently notify the Sajassi, Mohan et al. [Page 8] Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004 operator of the failure, using mechanisms that are out of scope of this draft, and initiate the failure verification and isolation steps either automatically or through operator command. If a PE is put out of commission, then in order to avoid triggering false failure detection, the out-of-commissioned PE shall indicate its soon to be out-of-state status to other member PEs for each service instance that it participates through a flag in the CC message. The other member PEs of the service instance, upon receiving this indication, would deactivate the corresponding timer for the heartbeat of that PE. Once PE devices have received and processed the CC messages, each PE will have a view of all active PEs for a given VPLS instance (service instance). Upon receiving CC messages, at the receiving maintenance point, a CC validity timer is started which is used to determine the loss of CC messages. A CC loss is assumed when the next CC message is not received within the timeout of this validity timer. If n consecutive CC messages are lost, a fault for that remote maintenance point is detected. Subsequent fault verification and isolation procedures can be exercised. Fault notification mechanisms, which may also follow the fault detection, are out of scope for this document. The fault may correspond to a hard failure or a soft failure within the network. Also a hard failure may result in network isolation which leads to loss of CC messages for many service instances. If the hard failure can be detected and reported to the Management entity, additional notifications by each maintenance point may not be needed û e.g., it is desirable to have an alarm suppression mechanism for notifications that get generated as the result of CC timeouts. Since this message is sent periodically, in order to facilitate the processing and filtering of this message, both the message type and domain level is embedded in the multicast MAC address. It may be noted, that the associated Multicast MAC address will be specified in IEEE 802.1. A CC messages does not require a response and requires only O (n) message transmission within its member group. In other words, if a service instance has N member PEs, only N CC messages need to be transmitted periodically û one from each PE. However, if this was to be done by point-to-point Ping messages, then O (N**2) messages would have been required. The maintenance points shall allow the filtering of CC messages from either entering or exiting its OAM domain. Sajassi, Mohan et al. [Page 9] Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004 6.2. Fault Verification This non-intrusive unicast loopback is a mechanism similar to IP Ping function that sends a request message from a source bridge to another bridge and expects a response from that bridge. To verify the connectivity between maintenance/intermediate points, the request message is initiated by a maintenance point with a DA MAC address set to the MAC address of either a intermediate point or the peer maintenance point. The maintenance points shall allow the filtering of fault verification messages from either entering or exiting its OAM domain. 6.3. Fault Isolation TraceRoute function is used to isolate faults visible at Ethernet MAC layer. TraceRoute can be used to isolate a fault associated with a given VPLS service instance. It should be noted that fault isolation in a connection-less (multi-point) environment is more challenging than a connection-oriented (point-to-point) environment. In case of Ethernet, fault isolation can be even more challenging since the MAC address of a target node can age out in several minutes (e.g. typically 5 min) when the fault results in isolating the target node. As a result of this age-out, the occurrence of a network-isolating fault results in erasure of information leading to the location of the fault! The TraceRoute function uses OAM message with a well-defined multicast MAC address. The TraceRoute Request gets initiated by a maintenance point and traverses hop-by-hop and each intermediate point along the path intercepts the TraceRoute Request and forwards it onto the next hop only after processing it. The processing includes looking at the target MAC address contained in the TraceRoute message. The originating maintenance point expects a response to its TraceRoute request. It should be noted that the source maintenance point sends a single request message to the next hop along the trace path; however, it can receive many responses from different intermediate points (and the peer maintenance point) along the trace path as the result of the message traversing hop by hop. Similar to CC messages, TraceRoute multicast MAC address will be specified by IEEE 802.1. Given that an end-to-end TraceRoute flow is different from that of a user data flow (TraceRoute goes through the control plane of each hop; whereas, user data flow doesnÆt), there can exist rare Sajassi, Mohan et al. [Page 10] Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004 situation in which the fault can not be detected by the TraceRoute flow. Given that the TraceRoute flow can identify all the points along the traced path (based on responses received at the source maintenance point) one can run multiple Loopback messages between the source maintenance point and different intermediate points (and the peer maintenance point) to further isolate the data-plane fault/corruption in such rare situations. As mentioned previously, the age-out of MAC address entries can lead to erasure of information at intermediate nodes, which is used for the TraceRoute mechanism. Possible ways to address this behavior include: - Launching TraceRoute mechanism following fault detection/isolation such that it gets exercised within the window of age-out. - Maintaining information about the destination maintenance point at the intermediate points along the path (Note: this can be facilitated by the CC messages.) - Maintaining visibility of path at the source maintenance points through periodic TraceRoute messages (Note: this periodicity should be larger than the CC periodicity) 7. Fault Management Messages Since OAM/FM mechanisms for VPLS solely dependent on Ethernet MAC layer, the corresponding messages are based on Ethernet frames. A generic format can be defined for all Ethernet OAM messages. The information carried in the Ethernet OAM messages is described next for the purpose of discussion. Since these discussions are still on-going in ITU-T Q3/13, IEEE 802.1 and MEF, a specific frame format is not presented here. 7.1. Generic Ethernet OAM Frame - Header Information - OAM Destination MAC Address: This MAC address can either be the unicast address of a maintenance/intermediate point, or it can be a well-defined multicast address. - OAM Source MAC Address: This MAC address corresponds to the maintenance or intermediate point. - VLAN Ether Type and Tag: This optional VLAN tag represents the service instance within an Ethernet Access domain. Note: Different Ethernet Access domains can use different VLAN tags corresponding to the same service instance. However, each Sajassi, Mohan et al. [Page 11] Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004 S-VLAN tag is unique within an access domain and corresponds to a single service instance. - OAM Ethernet Type: It identifies that message is of type OAM. - OAM Version: The Version field identifies the OAM version number. - Opcode: The Opcode identifies the type of OAM frame. The OAM frame types that may be defined are: . Continuty Check (0x00) . TraceRoute Request (0x02) . TraceRoute Reply (0x03) . Loopback Request (0x04) . Loopback Reply (0x05) . Vendor Specific (0xFF). The vendor specific op-code is provided to allow vendors or other organizations to extend OAM functions in proprietary ways. . Other op-codes may be defined in the future. - Domain Level: This identifies the hierarchy of OAM domain associated with the OAM message. 7.2. Generic Ethernet OAM Frame û OAM Body Information - Service ID TLV: Identifies the VPLS/Service instance across the entire VPLS network and relates to the VPLS Service identifiers within each sub-network (e.g. VLAN tags within bridged access domains etc). - Transaction ID: Supplied by the originator of the FM message and returned in the reply message (Loopback or TraceRoute). - OAM Data: This is a data field associated with the corresponding OAM opcode and information contained is dependent on the type of OAM message. The OAM frame including OAM data portion should result in an Ethernet frame with valid length. Therefore, if necessary the OAM frame may be padded with zeros for a minimum size frame. 7.3. Continuity Check OAM data field for CC Messages may include the following TLVs: Sajassi, Mohan et al. [Page 12] Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004 - Lifetime TLV: Specifies the number of seconds, after the receipt of CC message, that the information related to CC message may be discarded by the recipient. - Maintenance Point State TLV: Identifies the state of the maintenance point and/or ports associated with it. - Device Management Address TLV: May identify the Layer 3 address required to access the source Maintenance PointÆs control MIB. 7.4. Loopback Specific OAM data field information is FFS. 7.5. TraceRoute 7.5.1. TraceRoute Request Format The OAM data field of a TraceRoute Request may contain the following TLVs: - Source Maintenance Point MAC TLV: Specifies the MAC address of the maintenance point that originated the TraceRoute request. It may be different from the source MAC address of a TraceRoute request, because each bridge along the path puts its own MAC address in the source MAC address field, while retaining the Source Maintenance Point MAC TLV. - Target Maintenance Point MAC TLV: Specifies the MAC address of the peer maintenance point. This TLV is passed on to the next hop. - Hop Count TLV: Hop Count TLV is the hop count of the intermediate/maintenance point(s) from where the response is expected by source maintenance point. 7.5.2. TraceRoute Reply Format The OAM data field of a TraceRoute Reply contains the following TLVs: - Hop Count TLV: It is the number of hops between the responding intermediate/maintenance point and the source maintenance point. - Ingress Device Management Address TLV: The TLV specifies the Layer 3 address required to access the control MIB for the Sajassi, Mohan et al. [Page 13] Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004 Maintenance Point or Intermediate Point on which the TraceRoute Request was received. 8. Acknowledgments We wish to thank Marc Holness, Tim Mancour, and Paul Bottorff for their valuable feedback. 9. Security Considerations Security issues resulting from this draft will be discussed in greater depth at a later point. It is recommended in [RFC3036] that LDP security (authentication) methods be applied. This would prevent unauthorized participation by a PE in a VPLS. Traffic separation for a VPLS is effected by using VC labels. However, for additional levels of security, the customer MAY deploy end-to-end security, which is out of the scope of this draft. In addition, the L2FRAME] document describes security issues in greater depth. 10. Intellectual Property Considerations This document is being submitted for use in IETF standards discussions. 11. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING Sajassi, Mohan et al. [Page 14] Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004 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. 12. References [PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap- 01.txt, Work in progress, November 2002. [802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D- 1993 "MAC Bridges". [802.1D-REV] 802.1D - "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998. [802.1Q] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", July 1998. [VPLS-REQ] "Requirements for Virtual Private LAN Services (VPLS)", draft-ietf-ppvpn-vpls-requirements-01.txt, Work in progress, October 2002. [L2FRAME] "L2VPN Framework", draft-ietf-ppvpn-l2-framework-03, Work in Progress, February 2003. [802.1ad] ôIEEE standard for Provider Bridges, Work in Progress, December 2002ö 13. Authors' Addresses Ali Sajassi Dinesh Mohan Cisco Systems, Inc. Nortel Networks 170 West Tasman Drive 3500 Carling Ave. San Jose, CA 95134 Ottawa, ON K2H 8E9 Email: sajassi@cisco.com Email: mohand@nortelnetworks.com Norm Finn Vasile Radoaca Cisco Systems, Inc. Nortel Networks 170 West Tasman Drive 600 Technology Park San Jose, CA 95134 Billerica, MA 01821 Email: nfinn@cisco.com Email: vasile@nortelnetworks.com Thomas D. Nadeau Shahram Davari Sajassi, Mohan et al. [Page 15] Internet Draft draft-sajassi-mohan-l2vpn-vpls-fm-00.txt March 2004 Cisco Systems, Inc. PMC Sierra 300 Beaver Brook Road 411 Legget Drive Boxborough, MA 01719 Ottawa, ON K2K 3C9 Email: tnadeau@cisco.com Email: shahram_davari@pmc- sierra.com Monique Morrow Cisco Systems, Inc. Glatt-com CH-8301 Glattzentrum Switzerland Email: mmorrow@cisco.com Sajassi, Mohan et al. [Page 16]