Internet Draft Document Vasile Radoaca, Layer-2 VPN Working Group Dave Allan draft-radoaca-l2vpn-bfd-inband-oam-00.txt Nortel Networks Ron Insler RAD Communication Simon Delord France Telecom Expires: December 2004 June 2004 BFD Extensions for PW Exchange of Fault Notifications draft-radoaca-l2vpn-bfd-inband-oam-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 BFD mechanism [BFD] was original designed to detect failures in communication with a forwarding plane next hop. BFD operates on top of any data protocol being forwarded between two systems. This document describes how to use the BFD mechanism for exchanging OAM Notifications (e.g. AC and PWs Notifications) between OAM domains, for P2P PWs (Single Hop PW, or Multiple Hop PW). This proposal is presented as an alternative to the LDP Status Mechanism described in [PW-CNTL]. Radoaca et al. June 2004 [Page 1] Internet Draft draft-radoaca-l2vpn-bfd-inband-oam-00.txt However, the LDP Status mechanism should be used when the data plane failed, or as an optimization, when for example, the whole interface of a PE is down û in this case one LDP Status message can be used for this interface. This method, called ôBFD In band Notificationö (BFD-N), is designed to work in parallel with any fault detection mechanism that can be employed in the network. As such, the BFD mechanism can be used for both fault detection and AC/PW notification. The proposed solution covers both like-to-like and heterogeneous PW types. In addition it can be applied for more complex services, like VPLS. The BFD mechanism is described in [BFD] and the usage of BFD in the PW context is described in [VCCV]. The proposed extensions for BFD do not change the overall scope of BFD as a lightweight detection protocol: both the BFD Control packet format and the BFD state machine remain the same as described in [BFD] draft. 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 http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-l2-framework- 03.txt http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-requirements- 01.txt http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-mgt-fwk-01.txt http://www.ietf.org/internet-drafts/draft-sajassi-mohan-l2vpn-vpls- fm-00.txt http://www.ietf.org/internet-drafts/draft-mohan-sajassi-l2vpn-vpls- pm-00.txt http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-map- 04.txt WHERE DOES THIS FIT IN THE PICTURE OF THE ROUTING WORK L2VPN WHY IS IT TARGETED AT THIS WG Radoaca et al. June 2004 [Page 2] Internet Draft draft-radoaca-l2vpn-bfd-inband-oam-00.txt This draft describes requirements and framework for Layer 2 VPN OAM. JUSTIFICATION The charter of L2VPN WG includes L2VPN specific OAM extensions, where the extensions apply to existing OAM solutions for VPLS, VPWS, and IP-only L2VPNs. Table of Contents 1. Status of this Memo.............................................1 2. Abstract........................................................1 3. Conventions.....................................................2 4. Overview........................................................3 4.1. What problem we want to solve.................................4 5. General description.............................................5 5.1. PW OAM Domain.................................................6 5.2. OAM PE IWF function...........................................7 6. BFD Negotiation Procedures......................................7 6.1. BFD Negotiation Parameter.....................................7 6.2. BFD Negotiation and VCCV......................................8 7. OAM IWF and BFD Notification procedures.........................9 7.1. BFD Session setup for Notification............................9 7.2. Error codes...................................................9 7.3. Error Notification...........................................10 7.3.1. BFD on Demand Mode.........................................10 7.3.2. BFD on Async Mode..........................................11 8. BFD with Splice PW model [Multi Hop PW]........................11 9. BFD for ACs....................................................12 10. OAM Procedures................................................12 10.1. PW Core OAM Domain..........................................12 10.2. L2N1 OAM Domain.............................................12 10.3. L2N2 OAM Domain.............................................12 11. Acknowledgment................................................13 12. Security Considerations.......................................13 13. Intellectual Property Considerations..........................13 14. Full Copyright Statement......................................13 15. References....................................................14 16. Authors' Addresses............................................15 4. Overview This document describes how to use the BFD mechanism [BFD] for exchanging the status of Attachment Circuits (ACs) and PWs across an MPLS core, between PE devices for P2P PW( Single Hop, and Multi-Hop Radoaca et al. June 2004 [Page 3] Internet Draft draft-radoaca-l2vpn-bfd-inband-oam-00.txt PW or Splice PWs). This method, called ôBFD In band Notificationö, is designed to work in parallel with any fault detection mechanism that can be employed in the network. As such, the BFD mechanism can be used for both fault detection (VCCV-BFD) and AC/PW notification. The solution covers both like-to-like and heterogeneous PW types. In addition various operational procedures are proposed. The proposed extensions for BFD do not change the overall scope of BFD as a light detection protocol: both the BFD Control packet format and the BFD state machine remain the same as described in [BFD] draft The BFD mechanism used for fault detection in the PW context is described in [VCCV]. 4.1. What problem we want to solve The problem that we want to solve is to develop a capability of exchanging OAM domain notifications, across the MPLS core. Such capability should be ôin bandö, following the data plane. Currently, there are other drafts that are looking to solve the same problem. [PWE-CNTL] draft, proposes to extend the LDP Mapping/Notification Message in order to transfer AC status from one PE to another PE. [OAM-MSG-MAP] draft proposed to standardize the behavior of PEs with respect to failures on PWs and ACs. The problem is decomposed at two levels: errors mapping between various OAM layers, and OAM domains, and the tools that can be used for fault detection. In section 4.3 [OAM-MSG-MAP] is stated that both the LDP Status and VCCV-BFD Control messages can be used for PW failures/notification. However, the VCCV-BFD status can be used only for specific cases, as explained in 4.6. [VPWS-IW-OAM] defines the OAM procedures for the heterogeneous PW case, where AC types and PW types are different. This document proposes to use only one mechanism, BFD, as ôin bandö notification mechanism for all ACs and PWs type of errors and notifications. The BFD extensions for this proposal are minimal. However, the LDP Status mechanism should be used when the data plane failed or as an optimization, when for example, the whole interface of a PE is down, and the PW is starting and terminating in the same boxes, one LDP Status message can be used for this interface. Support for both BFD and LDP Status is negotiable, if both are supported, BFD is the preferred method. Radoaca et al. June 2004 [Page 4] Internet Draft draft-radoaca-l2vpn-bfd-inband-oam-00.txt Why we need this work? The LDP Status TLV mechanism uses the control plane; as such there are some issues with this model: - Carrier grade: in most failure conditions the data path is more resilient that the control plan - Static mapped labels û in this case, the control plane doesnÆt exist because the VC labels are provisioned - Scalability: the l2 vpn requirements, suggest that the number of PWs can grow up to 10,000 per PE. - The Control path may be different from data path, so the notification errors may arrive too late; for the GE traffic this implies a lot of traffic sent unnecessary. - Dataplane notifications are relatively lightweight, will be more timely as they are not serialized through the control plane, and have the potential to be more scalable as processing can be delegated to the interfaces. 5. General description Figure 1 illustrates a VPWS network model with an indication of the possible defect locations and the potential fault segments: AC1, PW, AC2. This model will be referenced in the remainder of this document for describing the OAM procedures. ACs PSN tunnel ACs +----+ +----+ +----+ | PE1|==================| PE2| +----+ | |---a------|b..c........PW1...d.....c..f|-----e----| | | CE1| (L2N1) |IWF | |IWF | (L2N2) |CE2 | | |----------|............PW2.............|----------| | +----+ | |==================| | +----+ ^ +----+ +----+ ^ | Provider Edge 1 Provider Edge 2 | | | |<-------------- Emulated Service ---------------->| Customer Customer Edge 1 Edge 2 Figure 1: VPWS reference model Radoaca et al. June 2004 [Page 5] Internet Draft draft-radoaca-l2vpn-bfd-inband-oam-00.txt 5.1. PW OAM Domain [L2VPN-OAM-FRW] describes the OAM framework for L2 VPN, based on the domain concept. In [L2-VPN-OAM-FRW] an OAM domain is defined as a network region over which OAM frames operate unobstructed. However, at the edge of the domain, the Maintenance Entity Point (MEP), like PE devices, can filter, block or map the OAM messages. 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. Following this methodology, we define three PW OAM Domains: Attachment OAM (L2N1), PW Core OAM, and Attachment OAM (L2N2). The Maintenance Entity Points (MEP) are modeled using the PE IWF, which resides at the edge between two different domains. Note: In the case of Multi Hop PWs model, the number of OAM domains can be arbitrary, based on the number of AS/SPs, and the number of Single Hop PWs that compose a Multi-Hop PW. From hierarchical point of view, these three domains are defined as the outermost level. Based on the rules defined in [L2VPN-OAM-FRW] any error that occur a low level domain (L1, ATM, Ethernet, and so on) should be filtered, blocked or mapped by the PW OAM domains. In each OAM domain there are the following error types, and notifications: - Error in the AC or PW interfaces [physical or logical] at lower layers or PW OAM layer - Error in the OAM domains, and sent to the AC/PW interfaces as OAM Notifications - Error in the OAM domains but not sent to the AC/PW interfaces - OAM Notifications sent by various Maintenance Intermediate Points (MIP) in the domains and forwarded to the AC/PW interfaces as PW OAM Notifications For example, on a specific PE interface, the following errors or notifications can be detected (Errors detected by that interface): - Physical/logical interface down - Loss of signal/framing - Remote fault indication/alarm inhibit signal The [OAM-MSG-MAP] and [ITU-T 1710] describe in details various type of errors that can occur in the AC domain and the PW domain and the tools that can be used for their detection. [ITU-T Y-GINA] suggests some useful high level design principles for the interworking of fault notifications. Radoaca et al. June 2004 [Page 6] Internet Draft draft-radoaca-l2vpn-bfd-inband-oam-00.txt 5.2. OAM PE IWF function The OAM IWF, depicted in Figure 1, mediates between various PW OAM domains, and as such has the following functions: - Filter, block or map the errors received from lower OAM layers to the PW OAM level - The OAM IWF rely the OAM information from AC/NSP to the PW and vice-versa - Invokes the BFD mechanism Once an error or notification was detected at IWF level, then it should be propagated across the MPLS core to the other end, where various OAM procedures can be applied. The OAM IWF can be seen as an application on top of BFD that uses the BFD variable context and the BFD state machine notifications, in order to map the AC notifications to/from PW. 6. BFD Negotiation Procedures In [PW-CNTL], LDP is used to setup the PW and to negotiate the PW parameters: Control Word, LDP Status, and the VCCV capability. In order to use this feature both PE devices should negotiate their own capabilities (in the same way as the LDP Status is negotiated). Once the PE devices agreed on using the BFD Notification mechanism, then various mechanisms can be used to bootstrap the BFD session. For example, the OAM IWF can be used to bootstrap the BFD session. 6.1. BFD Negotiation Parameter [PW-CNTL] defines a VC FEC TLV for LDP. We propose to have an optional parameters to indicate the desire to use BFD as ôinbandö notification mechanism. (editors note: Can we just assume use of inband if BFD is supported?) The TLV field structure is defined in [PW-CNTL] as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter ID | Length | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Value | | " | Radoaca et al. June 2004 [Page 7] Internet Draft draft-radoaca-l2vpn-bfd-inband-oam-00.txt +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The BFD parameter ID is defined as follows: Parameter ID Length Description 0x0X 8 BFD in Band The format of the BFD parameter TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0X | 0x08 |CC Type| CV Type Indicators | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | my discriminator [optional] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where CC Type has the following values: 0x01 û uses VCCV encapsulation 0x02 û uses MPLS router Alert label 0x03 û uses UDP encapsulation The CV type indicators has the following values: 0x01 - BFD on Demand mode 0X02 - BFD on Async mode The BFD packets can be encapsulated using the VCCV control channel, MPLS router Alert label, or UDP packets [MPLS-BFD]. There are two BFD modes that can be used: On Demand and Asynchronous. On Demand mode can be applied when the performance is a concern or if PW fault detection is performed via another mechanism. The Asynchronous mode performs PW fault detection and when augmented with this proposal, it performs the notification mechanism to perform fault notification across the MPLS core. The LDP Status can be negotiated separately from VCCV negotiation. When both mechanisms are active, then VCCV/BFD is used as the default mechanism. The LDP Status can be used as the last defense mechanism should the data plane have failed and BFD asynchronous mode not in use. 6.2. BFD Negotiation and VCCV BFD Notification capability and VCCV capability with BFD as Fault detection mechanism can be negotiated at the same time. Radoaca et al. June 2004 [Page 8] Internet Draft draft-radoaca-l2vpn-bfd-inband-oam-00.txt The same BFD session can be shared by both VCCV OAM function and BFD Notification. In this case the default mode for BFD Notification is Async mode. All the BFD Control messages that have H=0 and DIAG !=0 would be treated as per [VCCV]. All the other control messages with H=1 and DIAG != 0, would be treated as per this proposal. The condition in [VCCV] that BFD is provisioning in the Async mode it holds. 7. OAM IWF and BFD Notification procedures 7.1. BFD Session setup for Notification Once the BFD Notification capability has been agreed between PE devices, a BFD session can then be established for each LSP. If the BFD session is already there [established for fault detection], then the session is also re-used for notification, otherwise the IWF creates a new BFD session with the parameters taken from PW Setup procedure. 7.2. Error codes In order to perform the relay function, the types of errors [stored in the DIAG field of the BFD Control message] must be extended in order to cover the AC error cases [Note: AC Type may be encoded together with the Error code type] Currently [BFD] drafts defines 7 Error Codes, but there are used in the VCCV context only three: Control Detection Time Expired, Neighbor Signaled Session Down, and Admin. The PW OAM domain introduces the following error codes: - AC-AIS or Down: This is generated as a result of either an AC PHY failure, or termination of an AC ôdownö or AIS notification at the IWF. - AC-RDI: The is generated on termination of an RDI notification at the IWF. - PW-AIS or Down: This is generated if a VCCV ping has identified a PW forwarding failure at the ingress IWF. - PW-RDI: This is generated in response to a BFD failure or lower layer indication. (editors note: this may simply overlap the function of the absence of ôI hear youö in BFD messages and may be redundant). Radoaca et al. June 2004 [Page 9] Internet Draft draft-radoaca-l2vpn-bfd-inband-oam-00.txt ACs that provide simple down indication (e.g. Frame Relay LMI), have the down indication translated to AC-AIS. Where there are multiple faults present at an IWF, the order of precedence is: PW-AIS AC-AIS PW-RDI AC-RDI Based on [L2VPN-OAM-FRW], all the low layers OAM errors are mapped by the IWF to the PW OAM error codes. When all faults are cleared then the following codes should be used: - PW Forwarding - AC Forwarding 7.3. Error Notification Errors detected by other devices, or other network layers in the networking domains are propagated as OAM domain notifications (e.g. AC notifications or PW notifications). Consider the scenario in Figure 1, with PE1, and PE2 the PE devices, and AC1, AC2 the attachment circuits associated with each PE device. Suppose that a fault was detected on AC1 attached to the PE1. Once an error or an OAM notification is detected in a given PE interface, then IWF function performs the following operations: - store the error code - normalize the errors code regardless of the AC type - notify the BFD state machine about the new context There are two cases that we need to analyze: On Demand and Async mode. 7.3.1. BFD on Demand Mode In this method, a poll sequence is started by the IWF on the PE1, by setting in the BFD Control message, the P bit (P=1), DIAG field = AC error code, and H bit set (H=1). When the PE2 receive the BFD control packet with DIAG != 0, then it stores the error code, and notify the IWF about the new context. The IWF in PE2 interprets the BFD message as ô I hear you but You may have a problemö. Then, the IWF function can query the Local DIAG field of the BFD state machine, normalizes the error code based on the current AC type and finally, it sends a corresponding AC notification on the proper AC (e.g AIS insertion) Radoaca et al. June 2004 [Page 10] Internet Draft draft-radoaca-l2vpn-bfd-inband-oam-00.txt In addition, the IWF clears the P bit and creates a new BFD Control packet with the F bit set(F=1), and H =1, and DIAG != 0. With this set, the new BFD packet is sent back to the PE1. The PE1, interprets the new BFD control packet as ôPE2 hears you but, I may have a problemö. On the PE1, the IWF can re-send the BFD control packet with the same AC notification after a specific interval time, till the AC1 error is cleared. 7.3.2. BFD on Async Mode Using the above scenario, the PE1 completes the BFD control packet with DIAG = AC Error and the H bit = 1. The IWF in PE2 interprets the BFD message as ô I hear you but You do have a problemö. In this case, the IWF in PE2 reply back to the PE1, and forward the corresponding AC notification on AC2. The P and F bits can be used in the same manner like in the On Demand Mode. A poll sequence is started in order to propagate the AC1 notification. When the poll sequence is cleared then the async mode will continue as a detection tool. Note û A pool sequence is activated when one of the BFD timers is changed; then all the BFD packets are sent with P =1. Note û P and F bits are used in ASYNC mode for negotiation and ACK mechanism that the remote PE has received the request changes from the originator PE. More general if the DIAG field is changed and H bit = 1 then P and F bits are used for the same reason 8. BFD with Splice PW model [Multi Hop PW] The Splice PW Model is defined in [LDP-PROV] and in [SP-PW]. A Multi-hop PW (MH-PW) is a concatenation of a set of single hop PWs (SH-PW) that traverse multiple AS/SPs domains. From an OAM prospective a MH-PW should appear as a single logical PW with the same OAM procedures like SH-PW. In this respect a single logical Notification channel [for example a VCCV channel] will signal end-to-end. LetÆs suppose the following scenario: a SP is decomposed in various domains (for example AS), and between domains there are PE devices capable to stitch PWs together (called S-PE). LetÆs call First and Last PE the Ultimate PE devices, between which the MH-PWs are provisioned. Radoaca et al. June 2004 [Page 11] Internet Draft draft-radoaca-l2vpn-bfd-inband-oam-00.txt The PE-IWF is working as defined above. The S-PE IWF function should forward the BFD Error/Notification message from an access SH-PW to an intra-domain BFD SH-PW. Between the S-PEs, the only PW errors that are relevant are: PW-Down-rx, and PW-Down-tx. 9. BFD for ACs BFD is independent of the layer 2 technologies, so the BFD sessions can be established for each AC in the access networks. The above procedures apply as well to this case. 10. OAM Procedures The figure 1 describes potential faults in various domains: Access L2N1, PW Core, L2N2. 10.1. PW Core OAM Domain Possible failures are described in [ITU-T Y.1710] and [VCCV]. Based on the [L2VPN-OAM-FRW] all the errors from lower domains would be normalized at the PW Core OAM using the error types from section 7.2(PW-AIS, PW-RDI). When a PE detects a PW failure (e.g on the receiver interface), then the IWF should inform its peer about the failure, using the BFD mechanism. In this example, the BFD Control packet that is sent to the peer PE, has: H= 0, DIAG = PW-rx down (editors note: this may overlap the ôI hear youö mechanisms already in BFD). If the BFD is also used for Fault Detection, then both notification and detection mechanisms should overlap. At the remote PE the IWF should map the error to the specific AC OAM domain, using the Error types defined in section 7.2. When the error is clear up, then the PE would send a BFD message with (H = 1, DIAG = PW Forwarding) 10.2. L2N1 OAM Domain This section will be completed for the next revision of the document. 10.3. L2N2 OAM Domain This section will be completed for the next revision of the document. Radoaca et al. June 2004 [Page 12] Internet Draft draft-radoaca-l2vpn-bfd-inband-oam-00.txt 11. Acknowledgment This work was supported by various people, and we would like to thank them for their contributions: Phillippe Nigel from France Telecom, Liz Hache, Mike Loomis, Mohan Dinesh from Nortel Networks, and Steven Wright from Bell South. 12. Security Considerations Fault notifications from ACs such as AIS and RDI are assumed to come from trusted (or at least accountable) entities and will not be exploited for denial of service attacks. If the PW transits an un-trusted subnetwork, the BFD mechanisms may be spoofed in order to disrupt operations. Other vulnerabilities with mechanisms shared with other aspects of PW setup are discussed in [VCCV] and [RFC3036]. Any other security vulnerabilities are as per the PSN network. 13. Intellectual Property Considerations This document is being submitted for use in IETF standards discussions. 14. 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 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Radoaca et al. June 2004 [Page 13] Internet Draft draft-radoaca-l2vpn-bfd-inband-oam-00.txt HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 15. References [BFD] draft-katz-ward-bfd-02.txt [ITU-T 1710] ITU-T Recommendation Y.1710 (2002), "Requirements for OAM Functionality In MPLS Networks" [ITU-T Y-GINA] ITU-T Draft Recommendation Y.gina ôGeneral Interworking Architectureö (June 2004), Temporary Document TD24 Rev. 1, (WP2/13), June 2004 [LDP-PROV] draft-ietf-l2vpn-signaling-01.txt [L2VPN-FRWK] "L2VPN Framework", draft-ietf-ppvpn-l2-framework-03, Work in Progress, February 2003. [L2VPN-OAM-FRW] draft-mohan-sajassi-l2vpn-oam-req-frmk-00.txt [OAM-MSG] draft-nadeau-pwe3-oam-msg-map-4.txt [MPLSF-FIW] ôFault Management for Multiservice Interworking Baseline Textö, MPLS Forum Draft Implementation Agreement, July 2004 [PWE3-CNTL] draft-ietf-pwe3-control-protocol-06.txt [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. [S-PW] draft-radoaca-l2vpn-p2p-multidomains-00.txt [VCCV] draft-ietf-pwe3-vccv-03.txt [VPLS-REQ] "Requirements for Virtual Private LAN Services (VPLS)", draft-ietf-ppvpn-vpls-requirements-01.txt, Work in progress, October 2002. [VPWS-IW-OAM] draft-aissaoui-l2vpn-vpws-iw-oam-00.txt [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 Radoaca et al. June 2004 [Page 14] Internet Draft draft-radoaca-l2vpn-bfd-inband-oam-00.txt 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. [802.1ad] ôIEEE standard for Provider Bridges, Work in Progress, December 2002ö 16. Authors' Addresses Vasile Radoaca Nortel Networks 600 Technology Park Billerica, MA 01821 Email: vasile@nortelnetworks.com Dave Allan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA Email: dallan@nortelnetworks.com Simon Dellord France Telecom, Lannion, France Email: simon.delord@francetelecom.com Ron Insler RAD Communications, Israel, Email: ron-i@rad.com Radoaca et al. June 2004 [Page 15]