L2VPN Working Group Mustapha Aissaoui Internet Draft Matthew Bocci Expiration Date: August 2004 David Watkinson Alcatel Hamid Ould-Brahim Mike Loomis Himanshu Shah Nortel Ciena Thomas D. Nadeau Paul Doolan Monique Morrow Mangrove Systems Cisco Systems Peter Busschbach John Z. Yu Lucent Technologies Hammerhead Systems February 2004 OAM Procedures for VPWS Interworking draft-aissaoui-l2vpn-vpws-iw-oam-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC 2026. 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 proposes OAM procedures for the Virtual Private Wire Service (VPWS). Aissaoui, et al. Expires August 2004 [Page 1] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt February 2004 Table of Contents Status of this Memo.............................................1 Abstract........................................................1 Table of Contents...............................................2 1 Conventions used in this document.............................2 2 Introduction..................................................2 3 General OAM Procedures........................................3 3.1 Defect Locations...........................................3 3.2 VPWS OAM Interworking Models...............................4 3.3 PW Status..................................................5 3.4 ATM AC Status..............................................5 3.5 FR AC Status...............................................5 3.6 Ethernet AC Status.........................................5 4 OAM Procedures for VPWS with homogeneous ACs..................6 4.1 ATM VPWS...................................................6 4.2 FR VPWS....................................................7 4.3 Ethernet VPWS..............................................7 5 OAM Procedures for VPWS with heterogeneous ACs................8 5.1 FR-ATM Interworking VPWS...................................8 5.1.1 Heterogeneous VPWS OAM Model..........................8 5.1.2 Homogeneous VPWS OAM Model............................9 5.2 Ethernet Interworking VPWS.................................9 5.3 IP Interworking VPWS......................................10 6 Security Considerations......................................11 7 Intellectual Property Disclaimer.............................11 8 References...................................................11 9 Authors' Addresses...........................................12 10 Full Copyright Statement....................................13 1 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2 Introduction This draft proposes OAM procedures for the Virtual Private Wire Service (VPWS). VPWS are defined in the L2 VPN framework [L2VPN-FRMK]. The following VPWS types are covered in this document: 1. VPWS with homogeneous attachment circuits (ACs) of ATM, FR, or Ethernet types. Aissaoui, et al. Expires August 2004 [Page 2] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt February 2004 2. VPWS with heterogeneous ACs of ATM and FR types, and in which the PW type is ATM or FR. In this case, FR-ATM service interworking [FRF8.1] is performed in PE1 (or PE2) and a FR (or ATM) PW is extended to the remote PE. This VPWS type will be referred to as ôFR-ATM Interworking VPWSö. 3. VPWS with heterogeneous ACs of ATM, FR, and Ethernet types, and in which the PW type is Ethernet [L2VPN-Interworking]. This VPWS type will be referred to as ôEthernet Interworking VPWSö. 4. VPWS with heterogeneous ACs of ATM, FR, and Ethernet types, and in which the PW type is IP [ARP-Mediation]. This VPWS type will be referred to as ôIP Interworking VPWSö. The following topics are not covered and may be addressed in a future revision of this document: 1. ATM ILMI Interworking 2. Handling of Loopback and CC OAM cells for ATM [I.610]. 3. The use of an inband PW method to notify the remote PE of the status of the PW. 3 General OAM Procedures 3.1 Defect Locations Figure 1 illustrates a VPWS network model with an indication of the possible defect locations. 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) | | | | (L2N2) |CE2 | | |----------|............PW2.............|----------| | +----+ | |==================| | +----+ ^ +----+ +----+ ^ | Provider Edge 1 Provider Edge 2 | | | |<-------------- Emulated Service ---------------->| Customer Customer Edge 1 Edge 2 Figure 1: VPWS Defect Locations The following is a brief description of the defect locations: Aissaoui, et al. Expires August 2004 [Page 3] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt February 2004 (a) Defect in the first L2 network (L2N1). This covers any defect in the L2N1 which impacts all or a subset of ACs terminating in PE1. The defect is conveyed to PE1 and to the remote L2 network (L2N2) using a L2 specific OAM defect indication. (b) Defect on a PE1 AC interface. (c) Defect on a PE PSN interface. (d) Defect in the PSN network. This covers any defect in the PSN which impacts all or a subset of the PSN tunnels and PWs terminating in a PE. The defect is conveyed to the PE using a PSN and/or a PW specific OAM defect indication. (e) Defect in the second L2 network (L2N2). This covers any defect in L2N2 which impacts all or a subset of ACs terminating in PE2. The defect is conveyed to PE2 and to the remote L2 network (L2N1) using a L2 specific OAM defect indication. (f) Defect on a PE2 AC interface. 3.2 VPWS OAM Interworking Models There are two different OAM interworking models which are dictated by the type of VPWS. In a homogeneous VPWS, the link layer of the AC is not terminated at a PE. This has the implication that the native service OAM has to operate transparently across the PSN. In this case, the default OAM procedures are to use the native service OAM for both the AC and PW defect indications. This model is referred to as the homogeneous VPWS OAM model. An example of this is ATM VPWS OAM procedures as specified in [PWE3-ATM]. However, it is acknowledged that some PE implementations may not be capable of generating and/or passing native service OAM messages over a PW. For those situations, an optional procedure based on terminating the native service OAM and conveying the corresponding status using out-of- band PW status signaling messages [PWE3-CONTROL] is proposed. This method is also proposed for the FR VPWS and the Ethernet VPWS for different reasons. Frame Relay link management protocol is widely used on FR UNI links but there is no known deployment of FR OAM standard [FRF.19]. Finally, Ethernet link management and OAM standards are at their early development stage. In a heterogeneous VPWS, the AC link layer is terminated at a PE. Therefore, the native service OAM always terminates at the AC endpoint in the PE. In this case, the default OAM procedures are to terminate the native service OAM and to convey the corresponding status using out-of-band PW status signaling messages. This model is referred to as the heterogeneous VPWS OAM model. As always, there is an exception to this. The FR-ATM interworking VPWS can be achieved by extending a ATM PW, instead of a FR PW, to the remote PE. Therefore, one can use the homogeneous VPWS OAM model and rely on the native ATM OAM inband. Aissaoui, et al. Expires August 2004 [Page 4] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt February 2004 3.3 PW Status A PW is declared DOWN if any of the following conditions are met: (i) A physical layer alarm is detected on the PSN interface. (ii) The status of the PSN tunnel over which the PW is riding is DOWN. In the case of a MPLS PSN, this status can be the result of running a MPLS specific OAM mechanism such as LSP-Ping [LSP-Ping] or Y.1711 CV [Y.1711]. This can also be the result of receiving a Y.1711 FDI/BDI in a MPLS tunnel. Finally, this status can be the result of a PE receiving a RSVP-TE PathErr message. (iii) A remote PW status message [PWE3-CONTROL] is received indicating that one or both directions of the PW are down. (iv) An inband PW OAM connectivity verification, such as VCCV [VCCV] or Y.1711 CV, or the receipt of a Y.1711 FDI/BDI indicates that one or both directions of the PW are down. Note that a PW is a bidirectional entity. A defect in one of the directions is treated as a defect in the entire PW. 3.4 ATM AC Status An ATM AC is declared DOWN if any of the following conditions are met: (i) A physical layer alarm is detected on the ATM interface. (ii) PE2 receives an F4/F5 AIS/RDI OAM cell indicating that the ATM VP/VC is down in the L2N2 ATM network. 3.5 FR AC Status A FR AC is declared DOWN if any of the following conditions are met: (i) A PVC is not ædeletedÆ from the Frame Relay network and the Frame Relay network explicitly indicates in a full status report (and optionally by the asynchronous status message) that this Frame Relay PVC is æinactiveÆ. In this case, this status maps across the PE to the corresponding PW only. (ii) The LIV indicates that the link from the PE1 to the Frame Relay network is down. In this case, the link down indication maps across the PE to all corresponding PWs. (iii) A physical layer alarm is detected on the FR interface. In this case, this status maps across the PE to all corresponding PWs. 3.6 Ethernet AC Status Aissaoui, et al. Expires August 2004 [Page 5] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt February 2004 An Ethernet AC is declared DOWN if any of the following conditions are met: (i) A physical layer alarm is detected on the Ethernet interface. 4 OAM Procedures for VPWS with homogeneous ACs Note: it has been pointed out at time of publication that Section 4 of this document and revision 4 of draft-nadeau-pwe3-oam-msg-map [OAM-MSG] converged on many aspects. It is the intent of the authors of the two drafts to fully align these sections and move the result into the next revision of draft-nadeau-pwe3-oam-msg- map. 4.1 ATM VPWS The ATM VPWS is based on the PWE3 ATM PW specification [PWE3-ATM]. ATM provides a complete set of OAM capabilities which include defect indication (AIS/RDI), continuity checking (CC), loopback verification (LB), and performance monitoring [I.610]. In normal, i.e., defect-free, operation, all the above types of ATM OAM cells are either terminated at the PE, for OAM segments terminating in the AC endpoint, or transparently carried over the PSN tunnel [PWE3-ATM]. In other words, the ATM VPWS makes use of the homogeneous VPWS OAM model. Defects in locations (a) or (b) should be conveyed to the remote ATM network L2N2 [PWE3-ATM]. In this case, PE1 should transparently carry the AIS/RDI cells received on the corresponding AC (defect a) or generated locally (defect b) over the corresponding ATM PW. Optionally, if PE1 cannot generate and/or transmit ATM OAM cells over the ATM PW, it may use the heterogeneous OAM model. PE1 should change the status of the corresponding ATM ACs to DOWN and generate PW status signaling messages [PWE3-CONTROL] to notify PE2 of the defect. PE2 will in turn generate AIS messages on the corresponding ACs towards L2N2. Defects in locations (c) or (d) will result in changing the status of the PSN tunnel and the corresponding PWs (both directions) to DOWN in PE1. Note that PE1 will only know that the transmit direction of the PSN tunnel is down. The receive direction for that same PSN tunnel can terminate on any other PSN interface and its status at PE1 is unknown. PE1 should generate AIS on the affected ACs to convey this status to L2N1 [PWE3-ATM]. Given that the transmit direction of the PSN tunnel is down, PE1 cannot use an ATM AIS inband to notify PE2 and L2N2. Therefore, an out-of- band notification may be used here. PE1 may generate PW status signaling messages to notify PE2 of the defect. Also, in the case of a MPLS PSN, PE2 may be able to detect the defect on its own by Aissaoui, et al. Expires August 2004 [Page 6] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt February 2004 running LSP-Ping [LSP-Ping] or Y.1711 CV [Y.1711] over the tunnel LSP. Also, PE2 may receive a RSVP-TE PathErr message if the other direction of the PSN tunnel has failed. In any case, PE2 should in turn generate AIS messages on the corresponding ACs towards L2N2. The handling of a defect in locations (e) and (f) is similar to that of locations (a) and (b) respectively. 4.2 FR VPWS The FR VPWS is based on the PWE3 FR PW specification [PWE3-FR]. Frame relay networks make use of PVC management over a FR UNI. This is based on Q.933 Annex A. A more extensive FR OAM capability set has subsequently been specified by the FR Forum [FRF.19] but this has little known deployments. Based on that, it is proposed to use the heterogeneous VPWS OAM model. In order to provide end-to-end defect notification in a FR VPWS, the following procedures should be followed. Defects in locations (a) or (b) will result in changing the status of the corresponding FR ACs to DOWN in PE1. In this case, PE1 should generate a PW status message on each of the corresponding FR PWs to convey this status to the remote PE (PE2). PE2 should in turn generate a full status report with the Active bit = 0 (and optionally in the asynchronous status message), as per Q.933 annex A, into L2N2 for the corresponding FR ACs. A FR AC is declared DOWN if any of the conditions described in Section 3.5 are met. Defects in locations (c) or (d) will result in changing the status of the corresponding PWs (both directions) to DOWN in PE1. In this case, PE1 should translate this status by sending Active bit = 0 in the full status report (and optionally in the asynchronous status message), as per Q.933 annex A, into L2N1 and for the corresponding FR ACs. In addition, PE1 should send a PW status signaling message to the remote PE to convey the status of the affected PWs. PE2 should in turn generate a full status report with the Active bit = 0 (and optionally in the asynchronous status message), as per Q.933 annex A, into L2N2 for the corresponding FR ACs. A PW is declared DOWN if any of the conditions described in Section 3.3 are met. The handling of a defect in locations (e) and (f) is similar to that of locations (a) and (b) respectively. 4.3 Ethernet VPWS Aissaoui, et al. Expires August 2004 [Page 7] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt February 2004 The Ethernet VPWS is based on the PWE3 Ethernet PW specification [PWE3-ETH]. Ethernet link layer management and service OAM standards are at their early development stage. Therefore, the determination of Ethernet AC status is based on the status of the physical interface. In addition, Ethernet AC status change can only be conveyed to a management system. Based on that, it is proposed to use the heterogeneous VPWS OAM model. In order to provide end-to-end defect notification in an Ethernet VPWS, the following procedures should be followed. Defects in locations (a) or (b) will result in changing the status of the corresponding Ethernet ACs to DOWN in PE1. In this case, PE1 should generate a PW status message on each of the corresponding Ethernet PWs to convey this status to the remote PE (PE2). PE2 should in turn change the status of the corresponding Ethernet ACs to DOWN. An Ethernet AC is declared DOWN if any of the conditions described in Section 3.6 are met. Defects in locations (c) or (d) will result in changing the status of the corresponding PWs (both directions) to DOWN in PE1. In this case, PE1 should translate this status by changing the status of the corresponding Ethernet ACs to DOWN. In addition, PE1 should send a PW status signaling message to the remote PE to convey the status of the affected PWs. PE2 should in turn change the status of the corresponding Ethernet ACs to DOWN. A PW is declared DOWN if any of the conditions described in Section 3.3 are met. The handling of a defect in locations (e) and (f) is similar to that of locations (a) and (b) respectively. 5 OAM Procedures for VPWS with heterogeneous ACs 5.1 FR-ATM Interworking VPWS The FR-ATM interworking VPWS consists of interworking FR and ATM ACs over the PSN. Frame relay networks make use of PVC management over a FR UNI. This is based on Q.933 Annex A. ATM networks make use of the ATM OAM capabilities as specified in [I.610]. 5.1.1 Heterogeneous VPWS OAM Model In order to provide end-to-end defect notification in a FR-ATM interworking VPWS, the following procedures should be followed. For clarity of the text, it is assumed that the ACs attached to PE1 in Figure 2 are of FR type. Similarly, it is assumed that the ACs attached to PE2 are of ATM type. The PW type is ATM if the Aissaoui, et al. Expires August 2004 [Page 8] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt February 2004 FRF.8.1 [FRF.8.1] interworking function resides in PE1. The PW type is FR if it resides in PE2. Defects in locations (a) or (b) will result in changing the status of the corresponding FR ACs to DOWN in PE1. In this case, PE1 should generate a PW status message on each of the corresponding FR PWs to convey this status to the remote PE (PE2). PE2 should in turn translate this status into an ATM AIS message to be sent in each of the corresponding ATM ACs. A FR AC is declared DOWN if any of the conditions described in Section 3.5 are met. Defects in locations (c) or (d) will result in changing the status of the corresponding PWs (both directions) to DOWN in PE1. In this case, PE1 should translate this status by sending Active bit = 0 in the full status report (and optionally in the asynchronous status message), as per Q.933 annex A, into the local Frame Relay network and for the corresponding FR ACs. In addition, PE1 should send a PW status signaling message to the remote PE to convey the status of the affected PWs. PE2 should in turn translate this status into an ATM AIS message to be sent in each of the corresponding ATM ACs. A PW is declared DOWN if any of the conditions described in Section 3.3 are met. Defects in location (e) or (f) will result in changing the status of the corresponding ATM ACs to DOWN in PE2. In this case, PE2 should generate a PW status message on each of the corresponding PWs to convey this status to PE1. PE1 should in turn translate this status by sending Active bit = 0 in the full status report (and optionally in the asynchronous status message), as per Q.933 annex A, into the local Frame Relay network and for the corresponding FR ACs. An ATM AC is declared DOWN if any of the conditions described in Section 3.4 are met. 5.1.2 Homogeneous VPWS OAM Model When the PW type is ATM, the homogeneous VPWS OAM procedures may be used instead. These are described in Section 4.1 for a ATM VPWS. 5.2 Ethernet Interworking VPWS The Ethernet interworking VPWS consists of interworking FR, ATM, and Ethernet ACs over the PSN when the PW is of Ethernet type only [L2VPN-IW]. The heterogeneous VPWS OAM model is used here. Aissaoui, et al. Expires August 2004 [Page 9] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt February 2004 In order to provide end-to-end defect notification in a Ethernet interworking VPWS, the following procedures should be followed. For clarity of the text, it is assumed that the ACs attached to PE1 in Figure 2 are of FR type. It is also assumed that the ACs attached to PE2 are either of ATM type or of a Ethernet type. Defects in locations (a) or (b) will result in changing the status of the corresponding FR ACs to DOWN in PE1. In this case, PE1 should generate a PW status message on each of the corresponding PWs to convey this status to the remote PE (PE2). PE2 should in turn translate this status into an ATM AIS message to be sent in each of the corresponding ATM ACs. Also, PE2 should change the status of the corresponding Ethernet ACs to DOWN. A FR AC is declared DOWN if any of the conditions described in Section 3.5 are met. Defects in locations (c) or (d) will result in changing the status of the corresponding PWs (both directions) to DOWN in PE1. In this case, PE1 should translate this status by sending Active bit = 0 in the full status report (and optionally in the asynchronous status message), as per Q.933 annex A, into the local Frame Relay network (L2N1) and for the corresponding FR ACs. In addition, PE1 should send a PW status signaling message to the remote PE to convey the status of the affected PWs. PE2 should in turn translate this status into an ATM AIS message to be sent in each of the corresponding ATM ACs. Also, PE2 should change the status of the corresponding Ethernet ACs to DOWN. A PW is declared DOWN if any of the conditions described in Section 3.3 are met. Defects in location (e) or (f) will result in changing the status of the corresponding ATM ACs or Ethernet ACs to DOWN in PE2. In this case, PE2 should generate a PW status message on each of the corresponding PWs to convey this status to PE1. PE1 should in turn translate this status by sending Active bit = 0 in the full status report (and optionally in the asynchronous status message), as per Q.933 annex A, into the local Frame Relay network and for the corresponding FR ACs. An ATM AC is declared DOWN if any of the conditions described in Section 3.4 are met. An Ethernet AC is declared DOWN if any of the conditions described in Section 3.6 are met. 5.3 IP Interworking VPWS The IP interworking VPWS consists of interworking FR, ATM, and Ethernet ACs over the PSN when the PW is of IP type only [ARP- MEDIATION]. The heterogeneous VPWS OAM model is used here. Aissaoui, et al. Expires August 2004 [Page 10] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt February 2004 The OAM procedures for this VPWS type are the same as those for the Ethernet Interworking VPWS. See Section 5.2 for details. 6 Security Considerations This draft does not introduce any new security considerations to VPWS. Though, it is worth mentioning that in the heterogeneous VPWS OAM model, a flooding of alarms on the ACs may result in a large number of PW status signaling messages generated. This may have an impact on the performance of the MPLS control plane. This issue should be investigated and solutions should be provided if required. A method for aggregating PW status messages is one possible solution. 7 Intellectual Property Disclaimer This document is being submitted for use in IETF standards discussions. 8 References [L2VPN-FRMK] Andersson, L. et. al., "L2VPN Framework", draft-ietf- l2vpn-l2-framework-03.txt, October 2003. [FRF8.1] Frame Relay Forum, ôFRF 8.1 - Frame Relay / ATM PVC Service Interworking Implementation Agreementö, February 2000. [L2VPN-IW] Sajassi, A., et al., ôL2VPN Interworkingö, draft- sajassi-l2vpn-interworking-01.txt, March 2003. [ARP-MEDIATION] Shah, H., et al., ôARP Mediation for IP interworking of Layer 2 VPNö, draft-shah-l2vpn-arp-mediation- 03.txt, October 2003. [I.610] ôB-ISDN operation and maintenance principles and functionsö, ITU-T Recommendation I.610, February 1999. [OAM-MSG] Nadeau, T., et al., ôPseudo Wire (PW) OAM Message Mappingö, draft-nadeau-pwe3-oam-msg-map-04.txt, January 2004. [PWE3-ATM] Martini, L., et al., ôEncapsulation Methods for Transport of ATM Over IP and MPLS Networksö, draft-ietf-pwe3- atm-encap-04.txt, December 2003. [PWE3-CONTROL] Martini, L., et al., ôPseudowire Setup and Maintenance using LDPö, draft-ietf-pwe3-control-protocol- 05.txt, December 2003. [PWE3-FR] Kawa, C., et al., ôFrame Relay over Pseudo-Wiresö, draft-ietf-pwe3-frame-relay-01.txt, July 2003. Aissaoui, et al. Expires August 2004 [Page 11] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt February 2004 [FRF.19] Frame Relay Forum, ôFrame Relay Operations, Administration, and Maintenance Implementation Agreementö, March 2001. [LSP-Ping] Kompella, K., et al., ôDetecting MPLS Data Plane Livenessö, draft-ietf-mpls-lsp-ping-04.txt, October 2003. [Y.1711] ôOAM Mechanisms for MPLS Networksö, ITU-T Recommendation Y.1711, November 2002. [VCCV] Nadeau, T., et al., ôPseudo Wire (PW) Virtual Circuit Connection Verification (VCCV)ö, draft-ietf-pwe3-vccv-01.txt, October 2003. [PWE3-ETH] Martini, L., et al., ôEncapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networksö, draft- ietf-pwe3-ethernet-encap-05.txt, December 2003. 9 Authors' Addresses Mustapha Aissaoui Alcatel 600 March Rd Kanata, ON, Canada. K2K 2E6 Email: mustapha.aissaoui@alcatel.com Matthew Bocci Alcatel Voyager Place, Shoppenhangers Rd Maidenhead, Berks, UK SL6 2PJ Email: matthew.bocci@alcatel.co.uk David Watkinson Alcatel 600 March Rd Kanata, ON, Canada. K2K 2E6 Email: david.watkinson@alcatel.com Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Phone: +1 (613) 765 3418 Email: hbrahim@nortelnetworks.com Mike Loomis Nortel Networks 600 Technology Park Dr. Billerica, MA 01821 Phone: +1-978-288-6322 Email: mloomis@nortelnetworks.com Thomas D. Nadeau Aissaoui, et al. Expires August 2004 [Page 12] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt February 2004 Cisco Systems, Inc. 300 Beaverbrook Drive Boxborough, MA Phone: +1-978-936-1470 Email: tnadeau@cisco.com Monique Morrow Cisco Systems, Inc. Glatt-com CH-8301 Glattzentrum Switzerland Email: mmorrow@cisco.com John Yu Hammerhead Systems, Inc. 640 Clyde Court Mountain View, CA 94043 USA Phone: +1 650 210 3312 Email: john@hammerheadsystems.com Himanshu Shah Ciena Networks 35 Nagog Park, Acton, MA 01720 Email: hshah@ciena.com Paul Doolan Mangrove Systems 10 Fairfield Blvd., Wallingford, CT 06492 Email: pdoolan@mangrovesystems.com Peter B. Busschbach Lucent Technologies 67 Whippany Road Whippany, NJ, 07981 Email: busschbach@lucent.com 10 Full Copyright Statement "Copyright (C) The Internet Society (2004). Except as set forth below, authors retain all their rights. 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 Aissaoui, et al. Expires August 2004 [Page 13] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt February 2004 procedures for rights in submissions defined in the IETF 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 CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS (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. Aissaoui, et al. Expires August 2004 [Page 14]