Internet Draft Document Dinesh Mohan Layer-2 VPN Working Group Nortel Networks draft-mohan-sajassi-l2vpn-vpls-pm-00.txt Ali Sajassi Cisco Systems Shahram Davari PMC Sierra Vasile Radoaca Nortel networks Expires: November 2004 March 2004 Performance Management for Virtual Private LAN Services draft-mohan-sajassi-l2vpn-vpls-pm-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 Routing Area RELATED DOCUMENTS Mohan, Sajassi et al. [Page 1] Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-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 ROUTING WORK L2VPN WHY IS IT TARGETED AT THIS WG This draft describes Performance Management mechanisms for VPLS which is a Layer-2 VPN. JUSTIFICATION This draft describes Performance Management mechanisms 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. Performance Parameters..........................................8 6.1. Frame Loss (FL)...............................................8 6.2. Frame Delay (FD)..............................................8 6.3. Frame Delay Variation (FDV)...................................8 6.4. Availability..................................................9 6.5. Other Parameters..............................................9 6.5.1. Errored Frame Seconds (FL)..................................9 6.5.2. Frame Throughput............................................9 6.5.3. Frame Tx....................................................9 6.5.4. Frame Rx....................................................9 6.5.5. Frame Drop.................................................10 7. Performance Measurement Mechanisms.............................10 7.1. Performance Management Collection Method.....................11 7.2. Frame Loss Measurement.......................................11 7.2.1. Unsolicited Method.........................................12 Mohan, Sajassi et al. [Page 2] Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004 7.2.2. Solicited Method...........................................12 7.3. Frame Delay Measurement......................................13 7.4. Frame Delay Variation Measurement............................13 7.5. Availability Measurement.....................................14 8. Acknowledgments................................................14 9. Security Considerations........................................14 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 (PM), Configuration Management, Accounting Management, and Security Management. This draft only deals with Performance Management aspects of OAM&P for VPLS and defines mechanisms and procedures for it. Fault management aspects of OAM&P for VPLS are addressed in a companion draft [FM- SAJASSI-MOHAN]. Performance Management deals with mechanism(s) that allow determining and measuring the performance of network/services under consideration and notification of them. Performance Management can be used to verify the compliance to both the service and network level specifications. However, only the service-level aspects of the performance management (corresponding to VPLS instances) are addressed here. Performance Management typically consists of measurement of Performance Parameters e.g. Frame Loss, Frame Delay, Frame Delay Variation aka Jitter etc. This draft focuses on the following performance parameters and measurements: - Frame Loss Measurement - Delay Measurement - Delay Variation Measurement - Availability Measurement Other performance parameters are briefly introduced in this draft and are for FFS. Mohan, Sajassi et al. [Page 3] Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004 This document provides 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 defines the performance parameters and specifies the mechanisms and procedures for performance measurement 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 performance 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 performance 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 performance management, it is important to ensure that the performance management mechanisms for VPLS are independent of the underlying transport mechanisms (e.g., 802.3, MPLS, IP, ATM, SONET, etc.) and solely rely on Ethernet MAC layer. Mohan, Sajassi et al. [Page 4] Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004 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 Performance Management mechanisms operating at Ethernet MAC layer and the P nodes are invisible. Therefore, the Performance management along the path of P nodes (e.g., between two PEs) is covered by transport layer 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. performance 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 frames are not allowed to enter/exit other domains. We define an OAM domain as a network region over which OAM frames operate unobstructed as explained below. At the edge of an OAM domain, filtering constructs should prevent OAM frames from exiting and entering that domain. FM domains can be nested but not overlapped. In other words, if there is a hierarchy of the PM domains, the PM messages of a higher-level domain pass transparently through the lower-level domains but the PM messages of Mohan, Sajassi et al. [Page 5] Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004 a lower-level domain get blocked/filtered at the edge of that domain. In order to facilitate the processing of PM 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 PM 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/PM messages. Maintenance points are located at the edge of their corresponding domains. Intermediate points are located within their corresponding domains and they normally pass OAM/PM messages but never initiate them. Since Maintenance points are located at the edge of their domains, they are responsible for filtering outbound OAM frames from leaving the domain or inbound OAM frames from Mohan, Sajassi et al. [Page 6] Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004 entering the domain. Maintenance and intermediate points correspond to a PE or more specifically to an interface of a PE. For example, an OAM/PM 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/PM 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 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 Mohan, Sajassi et al. [Page 7] Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004 operator domain. Further, (F) represents the maintenance points and intermediate points corresponding to the MPLS layer and may apply MPLS based mechanisms. 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/PM 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/PM messages and the source MAC address of the OAM/PM frames represent the source maintenance point in that domain. For Unicast OAM/PM frames, the destination MAC address represents the destination maintenance point in that domain. For multicast OAM/PM frames, the destination MAC addresses correspond to all maintenance points in that domain. 6. Performance Parameters The following performance parameters are proposed: 6.1. Frame Loss (FL) Difference between the number of data frames sent from source maintenance point and the number of data frames received at destination maintenance point for a given VPLS instance during the measurement interval. 6.2. Frame Delay (FD) Frame delay can be specified in terms of round-trip delay, which is defined as the time elapsed since start of the transmission of the first bit of a frame by the source maintenance point until the reception of the last bit of the loop-backed frame by the same source maintenance point for a given VPLS instance, when the loopback is performed at the destination maintenance point. 6.3. Frame Delay Variation (FDV) Mohan, Sajassi et al. [Page 8] Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004 Frame Delay Variation can be specified in terms of variations in one-way delay. Measurement of the variations in the frame arrival pattern at the destination maintenance point belonging to the same CoS/priority instance compared to the transmission pattern at the source maintenance point for a given VPLS instance. 6.4. Availability Function of time the Maintenance Entity within a VPLS instance (associating pair of maintenance points) is in available state. It is specified as a ratio of: Total Time ME is in Available State / Total Time where, Total Time is number of measurement time intervals and Available State is viewed as interval when network/service meets FL, FD and FDV bounds. Unavailable state is encountered when at least one of the FL, FD or FDV measures exceed their bounds/thresholds during a time interval. These bounds/thresholds are determined by the class of service (CoS). 6.5. Other Parameters These parameters are briefly introduced here and are FFS. 6.5.1. Errored Frame Seconds (FL) Indicates if an error (e.g., frame error due to FCS or 8B/10B coding violation) has occurred within the second. This does not take into consideration errors when frames are received error free but are not delivered. 6.5.2. Frame Throughput Number of frames and/or bytes transmitted at a maintenance point. 6.5.3. Frame Tx Number of frames transmitted out of a maintenance point within the (previous) time interval (e.g. 1 second). 6.5.4. Frame Rx Number of frames received at a maintenance point within the (previous) time interval (e.g. 1 second). Mohan, Sajassi et al. [Page 9] Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004 6.5.5. Frame Drop Number of frames dropped at a maintenance point within the (previous) time interval (e.g. 1 second). 7. Performance Measurement Mechanisms Different measurement mechanisms are possible to perform performance measurements. One significant difference across these mechanisms is the level of accuracy. These mechanisms include: - (A) Statistical Methods Statistical methods use OAM frames to estimate data path behavior. Such methods are least accurate since they apply approximation to emulate data frames. The limitation lies in that the behavior of actual data frames may be quite different due to different addressing, processing, transient congestion conditions etc. Also, error conditions in networks typically happens in bursts thus statistical methods can likely miss those bursts and represent different results. - (B) Date path managed objects using management plane OAM frames use data path managed objects to calculate performance parameters and are inserted and/or extracted via management plane. These methods are fairly accurate since they use data path counters to measure data path performance. The limitation lies in that since the insertion and extraction of these OAM frames is done via management plane, in-flight frames need to be accounted for. In-flight frames refer to data path frames that flow between the time management plane accesses data path managed objects and the time management plane transmits/receives the PM OAM frame. However, this limitation can be addressed by averaging such measurements across multiple time intervals. - (C) Data path managed objects using data plane OAM frames use data path managed objects and are inserted and/or extracted via data plane. This method tends to be most Mohan, Sajassi et al. [Page 10] Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004 accurate since it does not have the limitation associated with the in-flight frames. However, the current data path hardware/chips do not support the implementation of such methods since this requires Ethernet data path capability to include automatic insertion and/or extraction of OAM frames. Moreover, it would also require changes in hardware/chips to allow ingress and egress filtering rules across OAM frames to protect service provider administrative domains from unintended OAM frames. It may be noted that (B) is preferable for cases where many samples are needed such as Frame Loss (FL) but in other cases such as Frame Delay (FD) or Frame Delay Variation (FDV) (A) based approach can be used. Among these methods, it is recommended to use the method (B) for Frame Loss (FL) since this method requires no changes in the existing hardware/chips and requires only software changes for PM OAM. The steps involved in such measurement mechanism include: - Collection of managed objects information - Calculation of performance parameters 7.1. Performance Management Collection Method To collect managed object information, a generic method is used to collect information across different managed objects e.g. using TLVs for information elements. It is possible to use either a solicited or unsolicited collection method, where solicited method requires a reply after a PM OAM request message is sent while unsolicited methods does not require a reply to a PM message. Current examples of solicited and unsolicited methods include Loopback and CC (Continuity Check) respectively, as described in [FM-SAJASSI-MOHAN]. For PM, similar methods can be applied. 7.2. Frame Loss Measurement Mohan, Sajassi et al. [Page 11] Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004 7.2.1. Unsolicited Method PM OAM frame is sent every N seconds (e.g. N=1) with Frames- Transmitted-OK value at source maintenance point. Upon receiving this PM OAM frame, Frames-Transmitted-OK value is compared with Frames-Received-OK value at destination maintenance point. Between two such consecutive PM OAM frames, the FL is measured as: Frame Loss = |CT2-CT1| - |CR2-CR1|, where CT and CR are Frames-Transmitted-OK and Frames-Received-OK counts. Consecutive messages help in reducing error introduced by in-flight frames and lack of timing synchronization between sender and receiver. Within a measurement time interval, the FL count can be averaged to improve the accuracy of measurement. Information elements that can be applied to PM OAM Data include: - Transaction ID - Frames-Transmitted-OK TLV 7.2.2. Solicited Method Requestor sends PM OAM request frame to receiver every N seconds (e.g. N=1) with its managed objects (MOs) information and expects a PM OAM reply frame with receiverÆs MOs information. Requestor sends Frames-Transmitted-OK value at source maintenance point and requests Frames-Received-OK value from destination maintenance point. Upon receiving the PM OAM request frame, receiver compares received MO information with its corresponding MO information and sends a reply PM OAM frame back to requestor with requested MO information. Receiver compares received Frames- Transmitted-OK value with its own Frames-Received-OK value and responds with its Frames-Received-OK value. Upon receiving PM OAM reply frame, requestor compares originally sent value with received values, similar to receiver. It is possible that receiver returns its FL result instead of MO information in response, however, if the MO information is returned, the performance collection method remains generic. Between two such consecutive PM OAM frames, the FL is measured as: Mohan, Sajassi et al. [Page 12] Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004 Frame Loss = |CT2-CT1| - |CR2-CR1|, where CT and CR are Frames-Transmitted-OK and Frames-Received-OK counts. Consecutive PM OAM frames help in reducing error introduced by in-flight frames and lack of timing synchronization between sender and receiver. Within a measurement time interval, the FL count can be averaged to improve the accuracy of this measurement. Information elements that can be applied to PM OAM Data include: - Transaction ID - Frames-Transmitted-OK TLV - Frames-Received-OK TLV 7.3. Frame Delay Measurement This method measures round-trip or two-way frame delay. Requestor sends PM OAM request message with its timestamp to the receiver. Receiver replies copying the requestorÆs timestamp. At the requestor, the difference between the timestamps at the time of receiving the PM OAM reply frame and original timestamp in the PM OAM reply frame measures round trip frame delay. Information elements that can be applied to PM OAM Data include: - Transaction ID - Request TimeStamp TLV 7.4. Frame Delay Variation Measurement This method measures round-trip or two-way frame delay per request and reply frame. Within the period of observation, requestor keeps track of maximum frame delay FD(max) and minimum frame delay FD(min). Frame delay variation is calculated as: Frame Delay Variation = FD(max) û FD(min) Information elements that can be applied to PM OAM Data include: - Transaction ID - Request TimeStamp TLV Mohan, Sajassi et al. [Page 13] Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004 7.5. Availability Measurement Measurement is based on FL, FD and FDV methods. Availability time interval (e.g. 24hr) can be divided into measurement time intervals (e.g. 1 minute). FL, FD and FDV are measured per measurement time interval. If any of the three measures crosses its corresponding thresholds, the measurement time interval is considered to be unavailable else it is considered to be available. Availability = (# of available measurement time intervals)/ (# of total measurement time intervals) 8. Acknowledgments We wish to thank Yoav Cohen, Marc Holness, Malcolm Betts, Paul Bottorff, Norm Finn, and Monique Morrow 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 Mohan, Sajassi et al. [Page 14] Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004 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 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 Dinesh Mohan Ali Sajassi Mohan, Sajassi et al. [Page 15] Internet Draft draft-mohan-sajassi-l2vpn-vpls-pm-00.txt March 2004 Nortel Networks Cisco Systems, Inc. 3500 Carling Ave. 170 West Tasman Drive Ottawa, ON K2H 8E9 San Jose, CA 95134 Email: mohand@nortelnetworks.com Email: sajassi@cisco.com Vasile Radoaca Norm Finn Nortel Networks Cisco Systems, Inc. 600 Technology Park 170 West Tasman Drive Billerica, MA 01821 San Jose, CA 95134 Email: vasile@nortelnetworks.com Email: nfinn@cisco.com Shahram Davari Yoav Cohen PMC Sierra Native Networks 411 Legget Drive Ottawa, ON K2K 3C9 Email: shahram_davari@pmc-sierra.com Mohan, Sajassi et al. [Page 16]