Internet Draft Document Dinesh Mohan (Editor) Internet Draft Nortel Networks Expires: April 2005 Ali Sajassi (Editor) Cisco Systems October 2004 VPLS OAM Requirements and Framework draft-ietf-l2vpn-oam-req-frmk-01.txt Status of this Memo By submitting this Internet-Draft, we represent that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we are aware have been or will be disclosed, and any of which we become aware will be disclosed in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with Sections 5 and 6 of RFC 3667 and Section 5 of RFC 3668. 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. Abstract This draft provides framework and requirements for Virtual Private LAN Service (VPLS) Operation, Administration and Maintenance (OAM). 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 Mohan and Sajassi Expires: April 2005 [Page 1] Internet Draft draft-ietf-l2vpn-oam-req-frmk-01.txt Oct 2004 RELATED DOCUMENTS http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-l2-framework- 03.txt http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-requirements- 03.txt Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Conventions........................................................1 1. Introduction....................................................2 2. L2VPN Services & Networks.......................................4 3. OAM Layering....................................................5 3.1. OAM Domains...................................................6 3.2. MEPs & MIPs...................................................7 3.3. MEP and MIP Identifiers.......................................8 4. VPLS OAM Requirements...........................................9 4.1. Discovery.....................................................9 4.2. Connectivity Fault Management.................................9 4.2.1. Connectivity Fault Detection................................9 4.2.2. Connectivity Fault Verification.............................9 4.2.3. Connectivity Fault Localization............................10 4.2.4. Connectivity Fault Alarm...................................10 4.3. Frame Loss...................................................10 4.4. Frame Delay..................................................10 4.5. Frame Delay Variation........................................11 4.6. Data Path Execution..........................................11 4.7. Scalability..................................................11 4.8. Extensibility................................................12 4.9. Security.....................................................12 4.10. Transport Independence......................................12 4.11. Application Independence....................................13 4.12. Backward Compatibility......................................13 4.13. Availability................................................13 5. Acknowledgments................................................13 6. Security Considerations........................................14 7. Intellectual Property Considerations...........................14 8. Full Copyright Statement.......................................14 9. IPR Notice.....................................................14 10. Normative References..........................................15 11. Informative References........................................15 12. Authors' Addresses............................................16 1. Introduction Mohan and Sajassi Expires: April 2005 [Page 2] Internet Draft draft-ietf-l2vpn-oam-req-frmk-01.txt Oct 2004 This draft provides framework and requirements for Virtual Private LAN Service (VPLS) Operation, Administration and Maintenance (OAM). The scope of OAM for any service and/or transport/network infrastructure technologies can be very broad in nature. OSI has defined the following five generic functional areas for network management, commonly abbreviated as "FCAPS" [NM-Standards]: a) Fault Management, b) Performance Management, c) Configuration Management, d) Accounting Management, and e) Security Management. This draft focuses on the Fault and Performance Management aspects. Other functional aspects of FCAPS are for further study. [L2VPN-FRWK] specified three different types of Layer 2 VPN (i.e. services). These are VPWS, VPLS and IPLS. The framework and requirements presented in this draft applies to VPLS. Fault Management can typically be viewed in terms of 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 device 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 device or link. 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 devices of a fault. For example, when there is a client/server relationship between two layered networks, Fault Detection at the server layer will require the following Fault Notification: - sending a forward Fault Notification into the client layer network(s) using the Fault Notification format appropriate to the client layer - sending a backward Fault Notification, if applicable, in the reverse direction in the server layer network Finally, Fault Recovery deals with recovering from the detected failure by switching to an alternate available device or link (e.g., device redundancy or link redundancy). Mohan and Sajassi Expires: April 2005 [Page 3] Internet Draft draft-ietf-l2vpn-oam-req-frmk-01.txt Oct 2004 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 metric objectives/specifications. Performance Management typically consists of measurement of Performance Parameters e.g. Frame Loss, Frame Delay, Frame Delay Variation (aka Jitter) etc across managed entities when the managed entity are in available state. Performance Management is suspended across unavailable managed entities. This draft introduces some of these performance parameters. 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. This proposal is aligned with the current discussions in other standard bodies and groups such as ITU-T Q.3/13, IEEE 802.1, and MEF which are addressing Ethernet network and service OAM. 2. L2VPN Services & Networks As described in [L2VPN-REQ], following Figure 1 shows a L2VPN reference model. L2VPN A represents a point-to-point service while L2VPN B represents a bridged service. +-----+ +-----+ + CE1 +--+ +--| CE2 | +-----+ | ..................... | +-----+ L2VPN A | +----+ +----+ | L2VPN A +--| PE |-- Service --| PE |--+ +----+ Provider +----+ / . Backbone . \ --------_ +-----+ / . | . \ / \ +-----+ + CE4 +--+ . | . +-\ Access \--| CE5 | +-----+ . +----+ . | Network | +-----+ L2VPN B ........| PE |....... \ / L2VPN B +----+ ^ ------- | | logical | | switching +-----+ | instance | CE3 | +-----+ L2VPN B Figure 1: L2VPN Reference Model [L2VPN-FRWK] specifies VPWS, VPLS and IPLS services. VPWS is a point-to-point service where CEs are presented with point-to-point Mohan and Sajassi Expires: April 2005 [Page 4] Internet Draft draft-ietf-l2vpn-oam-req-frmk-01.txt Oct 2004 virtual circuits. VPLS is a bridged LAN service provided to a set of CEs that are members of a VPN. CEs that are member of the same service instance communicate with each other as if they are connected via a bridged LAN. IPLS is a special VPLS which is used to carry only IP service packets. The point-to-point or 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 L2VPN 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. [L2VPN-REQ] assumes the availability of runtime monitoring protocols while defining requirements for management interfaces. This draft specifies the requirements and framework for operations, administration and maintenance (OAM) protocols between network devices. When discussing the OAM mechanisms for VPLS, it is important to consider that the end-to-end service can span across different types of L2VPN 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]. 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 [VPLS-BGP], and distributed VPLS as described in [ROSEN-SIG]. Therefore, it is important that the OAM 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 L2VPNs. Therefore, for L2VPN OAM, it is important to ensure that the OAM mechanisms are independent of the underlying transport mechanisms and solely rely on layer 2 services, e.g. for VPLS service, the transparency of OAM mechanisms must be ensured over underlying transport technologies such as MPLS, IP, etc. 3. OAM Layering Figure 2 shows an example of a VPLS service (with two CE belonging to customer A) across a service provider network marked by UPE and NPE devices. More CE devices belonging to the same Customer A can be connected across customer's different sites. Service provider network is segmented into core network and two types of access Mohan and Sajassi Expires: April 2005 [Page 5] Internet Draft draft-ietf-l2vpn-oam-req-frmk-01.txt Oct 2004 network. Figure 2(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 2(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 2: Service specific device view As shown in Figure 2(B), only the devices with Ethernet functionality are visible to OAM mechanisms operating at Ethernet MAC layer and the P devices are invisible. Therefore, the OAM along the path of P devices (e.g., between two PEs) is covered by transport layer and it is outside the scope of this document. 3.1. OAM Domains As described in the previous section, a VPLS service for a given customer can span across one or more service providers and network operators. Therefore, when discussing OAM tools for VPLS 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. OAM domains can be nested but not overlapped. In other words, if there is a hierarchy of the OAM domains, the OAM messages of a higher-level domain pass transparently through the lower-level domains but the OAM messages of a lower-level domain get blocked/filtered at the edge of that domain. In order to facilitate the processing of OAM messages, each domain can be associated with a level at which it operates. Domains with larger level numbers can contain domain with smaller level numbers but the converse is not true. Mohan and Sajassi Expires: April 2005 [Page 6] Internet Draft draft-ietf-l2vpn-oam-req-frmk-01.txt Oct 2004 A PE can be part of several domains with each interface belonging to same or different domains. A PE shall block outgoing OAM 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 3 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 3: OAM Domains 3.2. MEPs & MIPs Maintenance End Points (MEPs) are responsible for origination and termination of OAM messages. MEPs are located at the edge of their corresponding OAM domains. Maintenance Intermediate Points (MIPs) are located within their corresponding domains and they normally pass OAM messages but never initiate them. Since MEPs 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 entering the domain. MEPs and MIPs correspond to a PE or more specifically to an interface of a PE. For example, an OAM message can be said to originate from an ingress PE or more specifically an ingress interface of that PE. Since OAM domains are hierarchical as described above, the MEPs and MIPs associated with the OAM domains become hierarchical as well. A MEP of a higher-level domain is always a MEP of a lower-level domain but the converse is not always true since the MEP of lower-level domain can either be MIP or a MEP of a higher-level domain. Furthermore, the MIPs of a lower-level domain are always transparent Mohan and Sajassi Expires: April 2005 [Page 7] Internet Draft draft-ietf-l2vpn-oam-req-frmk-01.txt Oct 2004 to the higher-level domain (e.g., OAM messages of a higher-level domain are not seen by MIPs 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) MEP---MIP--------------------------------MIP---MEP Customer Domain (D) MEP--------MIP-----------MIP-------MEP Provider domain (E) MEP-MIP-MIP-MEP----------MEP-------MEP Operator Operator Operator domain domain domain (F) MEP--MIP-MIP-MEP--MIP--MEP MPLS MPLS domain domain Figure 4: OAM Domains, MEPs & MIPs As shown in Figure 4, (C) represents those MEPs and MIPs that are visible within the customer domain. (D) represents the MEPs and MIPs visible within the service provider domain, while (E) represents the MEPs and MIPs visible within each operator domain. Further, (F) represents the MEPs and MIPs corresponding to the MPLS layer and may apply MPLS based mechanisms. The MPLS layer shown in Figure 4 is just an example and specific OAM mechanisms are outside the scope of this document. 3.3. MEP and MIP Identifiers As mentioned previously, L2VPN OAM should be independent of underlying transport layer and only be dependent on service layer, e.g. Ethernet MAC layer in case of VPLS service. As an example, for Ethernet MAC layer, the MEPs and MIPs should be identified with their Ethernet MAC addresses. As described in [VPLS-LDP], VPLS instance can be identified in an Ethernet domain (e.g., 8021.d domain) using VLAN tag (service tag) while in an MPLS/IP network, Mohan and Sajassi Expires: April 2005 [Page 8] Internet Draft draft-ietf-l2vpn-oam-req-frmk-01.txt Oct 2004 PW-ids are used. Both PW-ids and VLAN tags for a given VPLS instance are associated with a Service Identifier (e.g., VPN identifier). MEPs and MIPs Identifiers, i.e. MEP Ids and MIP Ids must be unique within their corresponding Service Identifiers within the OAM domains. For Ethernet services e.g. VPLS, Ethernet frames are used for OAM messages and the source MAC address of the OAM frames represent the source MEP in that domain. For unicast Ethernet OAM frames, the destination MAC address represents the destination MEP in that domain. For multicast Ethernet OAM frames, the destination MAC addresses corresponds to all MEPs in that domain. 4. VPLS OAM Requirements 4.1. Discovery Discovery allows a service aware device to learn about other devices that support the same service instance within a given domain. Discovery also allows a service aware device to learn sufficient information (e.g. IP addresses, MAC addressed etc.) from other service aware devices such that OAM messages can be exchanged among the service aware devices. (R1) OAM MUST allow a service aware device to discover other devices that share the same service instance(s) within a given OAM domain. 4.2. Connectivity Fault Management Service is realized by exchanging service frames/packets between devices that support the service instance. To allow the exchange of service frames, connectivity between these service aware devices is required. 4.2.1. Connectivity Fault Detection To ensure service, pro-active connectivity monitoring is required. Connectivity monitoring facilitates connectivity fault detection. (R2a) OAM MUST allow pro-active connectivity monitoring between two service aware devices that support the same service instance within a given OAM domain. 4.2.2. Connectivity Fault Verification Once a connectivity fault is detected, connectivity fault verification may be performed. Mohan and Sajassi Expires: April 2005 [Page 9] Internet Draft draft-ietf-l2vpn-oam-req-frmk-01.txt Oct 2004 (R2b) OAM MUST allow connectivity fault verification between two service aware devices that support the same service instance within a given OAM domain. 4.2.3. Connectivity Fault Localization Further, localization of connectivity fault may be carried out. (R2c) OAM MUST allow connectivity fault localization between two service aware devices that support the same service instance within a given OAM domain. 4.2.4. Connectivity Fault Alarm Typically, when connectivity fault is detected and optionally verified, service device may notify the EMS/NMS (Element Management System/Network Management System). However, a single transport/network fault may cause multiple services to fail causing multiple connectivity faults. Therefore, OAM must allow alarm notification to allow suppression of service connectivity fault notifications. (R2d) OAM MUST allow forwarding of transport/network fault indications to those service aware devices that support service instance affected by the fault. 4.3. Frame Loss A service may be considered degraded if it is sensitive to service frames/packets loss during transit between the service aware devices. To determine if a service is degraded due to frame/packet loss, measurement of frame/packet loss is required. (R3) OAM MUST support measurement of per-service frame/packet loss between two service aware devices that support the same service instance within a given OAM domain. 4.4. Frame Delay A service may be sensitive to delay experienced by the service frames/packets during transit between the service aware devices. To determine if a service is degraded due to frame/packet delay, measurement of frame/packet delay is required. Frame/packet delay measurement can be of two types: One-way delay One-way delay is used to characterize certain applications like multicast and broadcast applications. The measurement for one-way Mohan and Sajassi Expires: April 2005 [Page 10] Internet Draft draft-ietf-l2vpn-oam-req-frmk-01.txt Oct 2004 delay usually requires clock synchronization between two devices in question. Two-way delay Two-way delay or round-trip delay does not require clock synchronization between two devices involved in measurement and is usually sufficient to determine the frame/packet delay being experienced. (R4a) OAM MUST support measurement of per-service two-way frame/packet delay between two service aware devices that support the same service instance within a given OAM domain. (R4b) OAM SHOULD support measurement of per-service one-way frame/packet delay between two service aware devices that support the same service instance within a given OAM domain. 4.5. Frame Delay Variation A service may be sensitive to delay variation experienced by the service frames/packets during transit between the service aware devices. To determine if a service is degraded due to frame/packet delay variation, measurement of frame/packet delay variation is required. For frame/packet delay variation measurements, one-way mechanisms are considered to be sufficient. (R5) OAM MUST support measurement of per-service frame/packet delay variation between two service aware devices that support the same service instance within a given OAM domain. 4.6. Data Path Execution If the OAM frames flow across a different path than the one used by service frames/packets, accurate measurement and/or determination of service state may not be made. Therefore data path, i.e. the one being taken by service frames/packets, must be used for the service OAM. (R6) OAM frames MUST be forwarded along the same path as the service/data frames. 4.7. Scalability Mechanisms developed for OAM need to be such that per-service OAM can be supported even though the OAM may only be used for limited services e.g. premium services and may not be used for best effort services. Note: The specific numbers or range of services should align with the [L2VPN-FRWK] Mohan and Sajassi Expires: April 2005 [Page 11] Internet Draft draft-ietf-l2vpn-oam-req-frmk-01.txt Oct 2004 (R7) OAM MUST be scalable such that a service device can support OAM for each service that is supported by the device. 4.8. Extensibility Extensibility is intended to allow introduction of additional functionality in future such that backward compatibility can be maintained i.e. when working with older version devices, service OAM with reduced functionality is still possible. (R8) OAM MUST be extensible such that new functionality and information elements related to this functionality can be introduced in future. 4.9. Security OAM frames belonging to an OAM domain originate and terminate within that OAM domain. Security implies that an OAM domain must be capable of filtering OAM frames. The filtering is such that the OAM frames are prevented from leaking outside their domain. Also, OAM frames from outside the OAM domains should be either discarded (when such OAM frames belong to same or lower-level OAM domain) or transparently passed (when such OAM frames belong to a higher-level OAM domain). (R9a) OAM frames MUST be prevented from leaking outside their OAM domain. (R9b) 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) OAM frames from outside an OAM domain MUST be transported transparently inside the OAM domain when such OAM frames belong to the higher-level OAM domain. 4.10. Transport Independence Service frame/packets delivery is carried out across transport infrastructure, also called network infrastructure. Though specific transport/network technologies may provide their own OAM capabilities, Service OAM must be independently supported as many different transport/network technologies can be used to carry service frame/packets. (R10a) OAM MUST be independent of the underlying transport/network technologies and specific transport/network OAM capabilities. Mohan and Sajassi Expires: April 2005 [Page 12] Internet Draft draft-ietf-l2vpn-oam-req-frmk-01.txt Oct 2004 (R10b) 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 service layer. 4.11. Application Independence Service itself may be used to carry application frame/packets. The application may use its own OAM; service OAM must not be dependent on application OAM. As an example, a VPLS service may be used to carry IP traffic; however, VPLS OAM should not assume IP or rely on the use of IP level OAM functions. (R11a) OAM MUST be independent of the application technologies and specific application OAM capabilities. 4.12. Backward Compatibility Service OAM should be such that non-service aware and/or OAM incapable devices in the middle of the OAM domain should be able to forward the OAM frames similar to the regular service/data frames/packets. (R12) 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 service/data frames/packets. 4.13. Availability A service may be considered unavailable if the service frames/packets do not reach their intended destination (e.g. connectivity is down or frame/packet loss is occurring) or the service is degraded (e.g. frame/packet delay and/or delay variation threshold is exceeded). Entry and exit conditions may be defined for unavailable state. Availability itself may be defined in context of service type. Since availability measurement may be associated with connectivity, frame/packet loss, frame/packet delay and frame/packet delay variation measurements, no additional requirements are specified currently. 5. Acknowledgments The authors would like to thank Shahram Davari, Norm Finn, Vasile Radoaca, Thomas Nadeau, and Monique Morrow for their contributions and review. Mohan and Sajassi Expires: April 2005 [Page 13] Internet Draft draft-ietf-l2vpn-oam-req-frmk-01.txt Oct 2004 The authors would also like to thank Yoav Cohen, Marc Holness, Malcolm Betts, Paul Bottorff, Dave Allan, and Hamid-ould Brahim for their valuable feedback. 6. 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. 7. Intellectual Property Considerations This document is being submitted for use in IETF standards discussions. 8. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 9. IPR Notice 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 Mohan and Sajassi Expires: April 2005 [Page 14] Internet Draft draft-ietf-l2vpn-oam-req-frmk-01.txt Oct 2004 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. 10. Normative References [NM-Standards] "TMN Management Functions", M.3400, February 2000. [RFC3036] "LDP Specification", RFC 3036, January 2001. 11. Informative References [PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap- 08.txt, Work in progress, September 2004. [L2VPN-REQ] "Service Requirements for Layer-2 Provider Provisioned Virtual Private Networks", draft-ietf-l2vpn-requirements-02.txt, Work in progress, September 2004. [L2VPN-FRWK] "Framework for Layer 2 Virtual Private Networks (L2VPNs)", draft-ietf-l2vpn-l2-framework-05.txt, Work in Progress, June 2004. [IEEE 802.1ad] "IEEE standard for Provider Bridges", Work in Progress, September 2004. [ROSEN-SIG] "Provisioning Models and Endpoint Identifiers in L2VPN Signaling", draft-ietf-l2vpn-signaling-02.txt, Work in progress, September 2004. [VPLS-LDP] "Virtual Private LAN Services over MPLS", draft-ietf-l2vpn-vpls-ldp-05.txt, Work in progress, September 2004. [VPLS-BGP] "Virtual Private LAN Service", draft-ietf-l2vpn-vpls-bgp-02.txt, Work in progress, May 2004. Mohan and Sajassi Expires: April 2005 [Page 15] Internet Draft draft-ietf-l2vpn-oam-req-frmk-01.txt Oct 2004 12. Authors' Addresses Dinesh Mohan Nortel Networks 3500 Carling Ave Ottawa, ON K2H8E9 Email: mohand@nortelnetworks.com Ali Sajassi Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Email: sajassi@cisco.com