L2VPN Working Group Mustapha Aissaoui Internet Draft Matthew Bocci Expiration Date: January 2005 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 July 2004 OAM Procedures for VPWS Interworking draft-aissaoui-l2vpn-vpws-iw-oam-01.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 Ethernet interworking, IP interworking and FR-ATM interworking Virtual Private Wire Service (VPWS). Aissaoui, et al. Expires January 2005 [Page 1] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt July 2004 Table of Contents Status of this Memo.............................................1 Abstract........................................................1 Table of Contents...............................................2 1 Conventions used in this document.............................2 2 Terminology...................................................3 3 Introduction..................................................3 4 General OAM Procedures........................................4 4.1 Defect Locations...........................................4 4.2 VPWS OAM Interworking Models...............................4 4.3 PW State...................................................6 4.3.1 PW DOWN...............................................6 4.3.2 PW UP.................................................7 4.4 ATM AC State...............................................7 4.5 FR AC State................................................8 4.6 Ethernet AC State..........................................8 5 OAM Procedures for FR-ATM Interworking VPWS...................8 5.1 FR Network and Attachment Circuit Defects..................8 5.1.1 FR PW and ATM PW with AAL5-mode encapsulation.........9 5.1.2 ATM PW with cell-mode encapsulation...................9 5.2 ATM Network and Attachment Circuit Defects................10 5.2.1 FR PW and ATM PW with AAL5-mode encapsulation........10 5.2.2 ATM PW with cell-mode encapsulation..................10 5.3 PW Defects................................................11 5.3.1 FR PW and ATM PW with AAL5-mode encapsulation........11 5.3.2 ATM PW with cell-mode encapsulation..................12 6 OAM Procedures for Ethernet Interworking VPWS................13 6.1 FR Network and Attachment Circuit Defects.................13 6.2 ATM Network and Attachment Circuit Defects................13 6.3 Ethernet Network and Attachment Circuit Defects...........14 6.4 PW Defects................................................14 7 OAM Procedures for IP Interworking VPWS......................14 8 Security Considerations......................................14 9 Intellectual Property Disclaimer.............................14 10 References..................................................14 11 Authors' Addresses..........................................16 12 Full Copyright Statement....................................17 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. Aissaoui, et al. Expires January 2005 [Page 2] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt July 2004 2 Terminology An end-to-end virtual circuit in a L2 VPN consists of a 3 segment set: [L2VPN-FRMK]. Note that the AC does not need to connect a CE directly to a PE. An intermediate L2 network may exist. A L2 VPN circuit is homogeneous if AC and PW types are the same. E.g., ATM circuit: . A L2 VPN circuit is heterogeneous if any two segments of the circuit are of different types. E.g., IP interworking circuit: , or . The PW of a L2 VPN circuit can ride over three types of Packet Switched Network (PSN). A PSN which makes use of LSPs as the tunneling technology to forward the PW packets will be referred to as a MPLS PSN. A PSN which makes use of MPLS-in-IP tunneling, with a MPLS shim header used as PW demultiplexer, will be referred to as MPLS-IP PSN. A PSN which makes use of L2TPv3 [L2TPv3] as the tunneling technology will be referred to as L2TP-IP PSN. 3 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 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.2] 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ö. 2. 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ö. 3. 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ö. OAM procedures for homogeneous VPWS circuits of ATM, FR, or Ethernet types are described in [OAM-MSG]. The following topics are not covered and may be addressed in a future revision of this document: 1. ATM ILMI Interworking Aissaoui, et al. Expires January 2005 [Page 3] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt July 2004 2. Handling of Loopback and CC OAM cells for ATM [I.610]. 4 General OAM Procedures 4.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| (N1) | | | | (N2) |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: (a) Defect in the first L2 network (N1). This covers any defect in the N1 which impacts all or a subset of ACs terminating in PE1. The defect is conveyed to PE1 and to the remote L2 network (N2) 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 (N2). This covers any defect in N2 which impacts all or a subset of ACs terminating in PE2. The defect is conveyed to PE2 and to the remote L2 network (N1) using a L2 specific OAM defect indication. (f) Defect on a PE2 AC interface. 4.2 VPWS OAM Interworking Models There are two different OAM interworking models which are dictated by the type of VPWS. Aissaoui, et al. Expires January 2005 [Page 4] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt July 2004 In a homogeneous VPWS circuit, the AC link layer is emulated by the PW by extending it across the PSN. 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 circuit OAM model. An example of this is ATM VPWS OAM procedures. Detailed OAM procedures for the homogeneous VPWS circuit types are described in [OAM-MSG]. In a heterogeneous VPWS circuit, 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 defect state using a PW specific defect mechanism.. This model is referred to as the heterogeneous VPWS circuit OAM model and is the model suitable for the VPWS types covered in this document. For a MPLS PSN and a IP PSN using MPLS- in-IP (MPLS-IP PSN), PW status signaling messages are used for AC and PW status and defect indication [PWE3-CONTROL]. For a IP PSN using L2TPv3, i.e., a L2TP-IP PSN, StopCCN and CDN messages are used for conveying defects in the PSN and PW respectively, while the Set-Link-Info (SLI) messages are used to convey status and defects in the AC and local L2 network as detailed in [OAM-MSG]. Note that the heterogeneous circuit OAM model assumes that the end-to-end circuit consists of three independent segments, , with defect states relayed across the boundary of these segments. This has important implications for the handling of ATM OAM at a PE. When a PE is notified of a defect in the remote L2 network, in the remote AC, or in the PW, it will always generate a F4/F5 AIS message towards the local ATM network and local CE regardless of the stated direction of the defect. At the same time, the PE should not relay over the PW the defect state of a received F4/F5 RDI from the local CE if it is sourcing a F4/F5 AIS on the same AC towards that CE. These conditions maintain the independence of the three defect loops while relaying the defect states end-to-end. The procedures in sections 5, 6, and 7 satisfy these two conditions. Finally, it may be desirable to operate ATM OAM inband in the case of the FR-ATM interworking VPWS. This document proposes to use the homogeneous OAM circuit model together with a ATM cell mode PW to achieve this. This is explained in Section 5. Table 1 summarizes the OAM model used with each type of VPWS covered in this document. ------------------------------------------------------------------ |VPWS Type | Homogeneous Circuit | Heterogeneous | | | OAM Model | Circuit OAM Model| ------------------------------------------------------------------ |FR-ATM Interworking | | | |- ATM cell mode PW | X | | Aissaoui, et al. Expires January 2005 [Page 5] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt July 2004 ------------------------------------------------------------------ |FR-ATM Interworking | | | |- FR or AAL5 PDU/SDU PW| | X | ------------------------------------------------------------------ |Ethernet Interworking | | X | ------------------------------------------------------------------ |IP Interworking | | X | ------------------------------------------------------------------ Table 1: Summary of VPWS OAM Interworking 4.3 PW State 4.3.1 PW DOWN A PE changes the state of a PW to DOWN if any of the following conditions are met: (i) It detects a physical layer alarm on the PSN interface over which the PW is riding and cannot re-establish the PW over another PSN interface. (ii) It detects a defect in the PSN tunnel over which the PW is riding and cannot re-establish the PW over another PSN tunnel. Defects include loss of connectivity, label swapping errors and label merging errors. In the case of a MPLS PSN and a MPLS-IP PSN, these defects can be detected by running a MPLS specific connectivity verification mechanism such as LSP-Ping [LSP-Ping], BFD on a LSP [LSP- BFD] 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 can be the result of a PE receiving a RSVP-TE PathErr message. (iii) It receives a message from the remote PE indicating a PW defect. In the case of a MPLS PSN and a MPLS-IP PSN, this is a PW status message [PWE3-CONTROL] indicating a "PW Receive Fault", a "PW Transmit Fault", or a "PW not forwarding". In the case of an L2TP-IP, this is a L2TP StopCCN or CDN message. A StopCCN message indicates that the control connection has been shut down by the remote PE [L2TPv3]. On reception of this message, a PE closes the control connection and will clear all the sessions managed by this control connection. Since each session carries a single PW, the state of the corresponding PWs is changed to DOWN. A CDN message indicates that the remote peer requests the disconnection of a specific session [L2TPv3]. In this case only the state of the corresponding PW is changed to DOWN. Aissaoui, et al. Expires January 2005 [Page 6] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt July 2004 (iv) It detects a loss of PW connectivity, including label errors, via an inband PW OAM connectivity verification, such as VCCV. [VCCV]describes how LSP-Ping and BFD can be used over individual PWs for connectivity verification and continuity checking respectively. It also specifies a return path for notifying the remote PE of the PW defect. Note that a PW is a bidirectional entity. A defect in one of the directions is treated as a defect in the entire PW. 4.3.2 PW UP For PWE3 over a MPLS PSN and a MPLS-IP PSN, a PE exits the PW DOWN state when the following conditions are true: (i) All defects it had previously detected, as described in Section 4.3.1, have disappeared, and (ii) It has received a PW Status message from its peer indicating "PW Forwarding". For a PWE3 over a L2TP-IP, a PE exits the PW DOWN state when the following conditions are true: (i) All defects it had previously detected, as described in Section 4.3.1, have disappeared, and (ii) A L2TPv3 session is successfully established to carry the PW packets. 4.4 ATM AC State A PE changes the state of an ATM AC to DOWN if any of the following conditions are met: (i) It detects a physical layer alarm on the ATM interface. (ii) It receives an F4/F5 AIS/RDI OAM cell indicating that the ATM VP/VC is down in the adjacent L2 ATM network (e.g., N1 for PE1). (iii) It detects loss of connectivity on the ATM VPC/VCC while running ATM continuity checking (ATM CC) with the local ATM network and CE. A PE exits the ATM AC Down state when all defects it had previously detected have disappeared. The exact conditions under which a PE exits a AIS or a RDI state, or declares that connectivity is restored via ATM CC are explained in I.610 [I.610]. Note that for a FR-ATM interworking VPWS, FRF.8.2 specifies interworking for ATM VCCs only [FRF.8.2]. Therefore only F5 OAM messages are relevant. Aissaoui, et al. Expires January 2005 [Page 7] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt July 2004 4.5 FR AC State A PE changes the state of an FR AC to 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 PE 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. A PE exits the FR AC Down state when all defects it had previously detected have disappeared. 4.6 Ethernet AC State A PE changes the state of an Ethernet AC to DOWN if any of the following conditions are met: (i) A physical layer alarm is detected on the Ethernet interface. A PE exits the Ethernet AC Down state when all defects it had previously detected have disappeared. 5 OAM Procedures for FR-ATM Interworking VPWS The FR-ATM interworking VPWS consists of interworking FR and ATM ACs over the PSN, and therefore a heterogeneous OAM model applies. Frame relay networks make use of PVC management over a FR UNI. This is based on Q.933 Annex A [Q.933AnnexA]. 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]. For clarity of the text, it is assumed that the ACs attached to PE1 in Figure Figure 1 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 FRF.8.1 [FRF.8.1] interworking function resides in PE1. The PW type is FR if it resides in PE2. 5.1 FR Network and Attachment Circuit Defects Aissaoui, et al. Expires January 2005 [Page 8] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt July 2004 5.1.1 FR PW and ATM PW with AAL5-mode encapsulation For a MPLS PSN and a MPLS-IP PSN, the following procedures MUST be followed when PE1 detects a defect in locations (a) or (b) as a result of any of the conditions described in Section 4.5: a. PE1 MUST change the state of the corresponding FR ACs to DOWN. b. PE1 MUST send a PW Status message indicating both "AC Receive Fault" and "AC Transmit Fault". c. On reception of the PW status message, PE2 MUST generate a F5 AIS on the related ATM ACs towards CE2. d. The termination point of the ATM VCC or VPC in the far- end, i.e., CE2, generates a F5 RDI in response to the received F5 AIS. PE2 MUST terminate the F5 RDI since it is sourcing a AIS over the same AC towards CE2. For an L2TP-IP, the following procedures MUST be performed when PE1 detects a defect in locations (a) or (b) as a result of any of the conditions described in Section 4.5: a. PE1 MUST change the state of the corresponding FR ACs to DOWN. b. PE1 MUST send an L2TP Set-Link Info (LSI) message with a Circuit Status AVP indicating "inactive". c. On reception of the L2TP LSI message, PE2 MUST generate a F5 AIS on the related ATM ACs towards CE2. d. The termination point of the ATM VCC or VPC in the far-end CE, i.e., CE2, generates a F5 RDI in response to the received F5 AIS. PE2 MUST terminate the F5 RDI since it is sourcing a AIS over the same AC towards CE2. 5.1.2 ATM PW with cell-mode encapsulation If the PW type is ATM cell (N:1 or 1:1), the following procedures MUST be performed: a. PE1 MUST change the state of the corresponding FR ACs to DOWN. b. PE1 MUST generate an F5 AIS message and send it over the PW to PE2. c. PE2 MUST forward the received F5 AIS message over the ATM AC. d. The termination point of the ATM VCC in the far-end CE, i.e., CE2, generates a F5 RDI in response to the F5 AIS. PE2 MUST forward the RDI over the PW. e. PE1 MUST terminate and MUST not reply to the received F5 RDI message. Aissaoui, et al. Expires January 2005 [Page 9] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt July 2004 5.2 ATM Network and Attachment Circuit Defects 5.2.1 FR PW and ATM PW with AAL5-mode encapsulation For a MPLS PSN and a MPLS-IP PSN, the following procedures MUST be followed when PE2 detects a defect in locations (e) or (f) as a result of any of the conditions described in Section 4.4: a. PE2 MUST change the state of the corresponding ATM ACs to DOWN. b. PE2 MUST send a PW Status message indicating "AC Receive Fault" for a received F5 AIS. c. PE2 MUST send a PW status message indicating "AC Transmit Fault" for a received F5 RDI only if it is not sourcing a F5 AIS over the same AC towards CE2. d. PE2 MUST generate a F5 RDI on the related ACs towards CE2 in response to a received F5 AIS only. e. On reception of the PW status message, PE1 MUST generate a full status report with the Active bit = 0 (and optionally in the asynchronous status message), as per Q.933 annex A, into N1 for the corresponding FR ACs. For an L2TP-IP, the following procedures MUST be performed when PE2 detects a defect in locations (a) or (b) as a result of any of the conditions described in Section 4.4: a. PE2 MUST change the state of the corresponding ATM ACs to DOWN. b. PE1 MUST send an L2TP Set-Link Info (LSI) message with a Circuit Status AVP indicating "inactive". c. PE2 MUST generate a F5 RDI on the related ACs towards CE2 in response to a received F5 AIS only. d. On reception of the L2TP LSI message, PE1 MUST generate a full status report with the Active bit = 0 (and optionally in the asynchronous status message), as per Q.933 annex A, into N1 for the corresponding FR ACs. 5.2.2 ATM PW with cell-mode encapsulation If the PW type is ATM cell (N:1 or 1:1), the following procedures MUST be performed: a. PE2 MUST transparently carry the F5 AIS or RDI cells received on the corresponding ATM AC (defect e) or the F5 AIS generated locally (defect f) over the corresponding ATM PW. b. On reception of the F5 AIS or RDI message, PE1 MUST generate a full status report with the Active bit = 0 (and optionally in the asynchronous status message), as per Q.933 annex A, into N1 for the corresponding FR ACs. Aissaoui, et al. Expires January 2005 [Page 10] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt July 2004 c. PE1 MUST terminate a received F5 RDI message. PE1 MUST generate a F5 RDI in response to a F5 AIS only and MUST forward it over the PW. d. On its reception, PE2 MUST forward the F5 RDI message on the corresponding AC. CE2 does not reply to a received F5 RDI message. 5.3 PW Defects 5.3.1 FR PW and ATM PW with AAL5-mode encapsulation For PWE3 over MPLS AND MPLS-IP, the following operations MUST be performed when PE1 detects a defect in locations (c) or (d) as a result of any of the conditions described in Section 4.3.1: a. PE1 MUST change the state of the affected PWs to DOWN. b. PE1 MUST generate a full status report with the Active bit = 0 (and optionally in the asynchronous status message), as per Q.933 annex A, into N1 for the corresponding FR ACs. c. If both directions of the PW are down, PE1 MUST generate a PW status message indicating ôPW not forwardingö. d. If only the Receive direction of the PW is down, PE1 MUST generate a PW status message indicating ôLocal PSN-facing PW (ingress) Receive Faultö. e. On reception of the PW status message, PE2 MUST generate a F5 AIS on the affected ACs to convey this status to the ATM network (N2) and CE2. f. CE2 replies with a F5 RDI. PE2 MUST terminate the F5 RDI since it is sourcing a AIS over the same AC towards CE2. For PWE3 over L2TP-IP, the following operations MUST be performed when PE1 detects a defect in locations (c) or (d) as a result of any of the conditions described in Section 4.3.1: a. PE1 MUST change the state of the affected PWs to DOWN. b. PE1 MUST generate a full status report with the Active bit = 0 (and optionally in the asynchronous status message), as per Q.933 annex A, into N1 for the corresponding FR ACs. c. If both directions of the PW are down, or if only the Receive direction of the PW is down, PE1 MUST send an L2TPv3 CDN message or a StopCCN message. d. On reception of the CDN or StopCCN message, PE2 MUST generate a F5 AIS on the affected ACs to convey this status to the ATM network (N2) and CE2. e. CE2 replies with a F5 RDI. PE2 MUST terminate the F5 RDI since it is sourcing a AIS over the same AC towards CE2. If only the PW Transmit direction is DOWN at PE1, this is generally detected by PE2 through a PSN or a PW continuity checking or connectivity verification mechanism as explained in Section 4.3.1. PE1 is notified through the return path of that Aissaoui, et al. Expires January 2005 [Page 11] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt July 2004 specific mechanism. In this case, PE2 will follow the procedures described below for a defect in the PW detected a PE2. When the PW state changes back to UP, a PE MUST cease the generation of the F5 messages on the ATM AC towards the CE. It MUST also generate a full status report (and optionally in the asynchronous status message), indicating a ôactiveö status for the corresponding FR AC. In addition, it MUST generate a PW Status message indicating ôPseudo Wire forwarding (clear all failures)ö for PWE3 over a MPLS PSN and a MPLS-IP PSN. For PWE3 or an L2TP-IP, the PE actions are TBD. This will result in clearing the alarm states in the remote PE, in CE1, and in CE2. The above procedures also apply if PE2 detects a defect in locations (c) or (d) as a result of any of the conditions described in Section 4.3.1. PE2 performs the same actions on the PW side as PE1 in the text above but will use the ATM AC procedures on the AC side instead. 5.3.2 ATM PW with cell-mode encapsulation The following operations MUST be performed when PE1 detects a defect in locations (c) or (d) as a result of any of the conditions described in Section 4.3.1: a. PE 1 MUST change the state of the affected PWs to DOWN. b. If both directions of the PW are down or if only the Receive direction of the PW is down, PE1 MUST generate a full status report with the Active bit = 0 (and optionally in the asynchronous status message), as per Q.933 annex A, into N1 for the corresponding FR ACs. c. PE1 MUST generate a F5 RDI and forward it over the PW. d. PE2 will receive the F5 RDI message only if the forward direction of the PW, i.e., PE1-to-PE2, is not affected by the defect. In this case, PE2 MUST forward the RDI message to CE2 through the ATM network (N2). CE2 terminates the F5 RDI message. If only the PW Transmit direction is DOWN at PE1, this is generally detected by PE2 through a PSN or a PW continuity checking or connectivity verification mechanism as explained in Section 4.3.1. PE1 is notified through the return path of that specific mechanism. In this case, PE2 will follow the procedures described below for a defect in the PW detected a PE2. When the PW state changes back to UP, PE1 MUST cease the generation of the F5 RDI messages on the AC towards CE1. It MUST also generate a full status report (and optionally in the asynchronous status message), indicating a ôactiveö status for the Aissaoui, et al. Expires January 2005 [Page 12] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt July 2004 corresponding FR AC. This will result in clearing the alarm states in PE1, in CE1, and in CE2. The following procedures MUST be performed when PE2 detects a defect in locations (c) or (d) as a result of any of the conditions described in Section 4.3.1: a. PE2 MUST change the state of the affected PWs to DOWN. b. If both directions of the PW are down or if only the Receive direction of the PW is down, PE2 MUST generate a F5 AIS on the affected ACs to convey this status to the ATM network (N2) and CE2. CE2 will reply with a F5 RDI messages towards PE2. c. On reception of the F5 AIS message, PE1 MUST carry it over the PW towards PE1. d. PE1 will receive the F5 RDI message only if the forwards direction of the PW, i.e., PE2-to-PE1, is not affected by the defect. In this case, PE1 MUST generate a full status report with the Active bit = 0 (and optionally in the asynchronous status message), as per Q.933 annex A, into N1 for the corresponding FR ACs. When the PW state changes back to UP, PE2 MUST cease the generation of the F5 AIS messages over the AC towards CE2. This will result in clearing the alarm state at CE2 and PE1. PE1 MUST then generate a full status report (and optionally in the asynchronous status message), indicating a ôactiveö status for the corresponding FR AC. This will result in clearing the alarm state in CE1. 6 OAM Procedures for 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]. 6.1 FR Network and Attachment Circuit Defects The procedures are the same as those described in Section 5.1.1 when the remote AC is ATM. When the remote AC is Ethernet, the same procedures apply with the exception that this document does not specify procedures the remote PE performs on the Ethernet AC once it is notified of the defect. 6.2 ATM Network and Attachment Circuit Defects The procedures are the same as those described in Section 5.2.1 when the remote AC is FR. When the remote AC is Ethernet, the same procedures apply with the exception that this document does not specify procedures the remote PE performs on the Ethernet AC once it is notified of the defect. Aissaoui, et al. Expires January 2005 [Page 13] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt July 2004 6.3 Ethernet Network and Attachment Circuit Defects The following procedures MUST be followed when PE2 detects a defect in locations (a), (b), (c), or (d), as a result of any of the conditions described in Section 4.6: a. PE1 MUST change the state of the corresponding Ethernet ACs to DOWN. b. PE1 MUST notify PE2 of the defect using the same PW procedures described in Section 5.1.1 for a MPLS PSN, a MPLS-IP PSN, and L2TP-IP PSN. c. PE2 MUST follow the procedures in Section 5.1.1 for a remote ATM AC or the procedures in Section 5.2.1 for a remote FR AC. 6.4 PW Defects When a PE detects a defect in location (c) or (d) as a result of any of the conditions described in Section 4.3.1, it MUST follow the procedures described in Section 5.3.1 for the PW, the ATM AC, and the FR AC. Note that this document does not specify procedures a PE performs on a Ethernet AC once it detects or is notified of the defect in the PW. 7 OAM Procedures for 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 OAM procedures for this VPWS type are the same as those for the Ethernet Interworking VPWS. See Section 6 for details. 8 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. 9 Intellectual Property Disclaimer This document is being submitted for use in IETF standards discussions. 10 References [L2VPN-FRMK] Andersson, L. et. al., "L2VPN Framework", draft-ietf- l2vpn-l2-framework-05.txt, June 2004. Aissaoui, et al. Expires January 2005 [Page 14] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt July 2004 [FRF8.2] Frame Relay Forum, ôFRF 8.2 - Frame Relay / ATM PVC Service Interworking Implementation Agreementö, February 2004. [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-ietf-pwe3-oam-msg-map-00.txt, July 2004. [PWE3-ATM] Martini, L., et al., ôEncapsulation Methods for Transport of ATM Over IP and MPLS Networksö, draft-ietf-pwe3- atm-encap-05.txt, April 2004. [PWE3-CONTROL] Martini, L., et al., ôPseudowire Setup and Maintenance using LDPö, draft-ietf-pwe3-control-protocol- 08.txt, July 2004. [PWE3-FR] Kawa, C., et al., ôFrame Relay over Pseudo-Wiresö, draft-ietf-pwe3-frame-relay-02.txt, February 2004. [Q933AnnexA] ITU-T, ôAdditional procedures for Permanent Virtual Connection (PVC) status managementö, ITU-T Q.933 Annex A, February 2003. [FRF.19] Frame Relay Forum, ôFrame Relay Operations, Administration, and Maintenance Implementation Agreementö, March 2001. [L2TPv3] Lau, J., et.al. " Layer Two Tunneling Protocol (Version 3", Internet Draft , June 2004 [LSP-BFD] Aggarwal, R., et al., ö BFD For MPLS LSPsö, draft-ietf- bfd-mpls-00.txt, July 2004. [LSP-Ping] Kompella, K., et al., ôDetecting MPLS Data Plane Livenessö, draft-ietf-mpls-lsp-ping-05.txt, February 2004. [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-03.txt, June 2004. Aissaoui, et al. Expires January 2005 [Page 15] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt July 2004 [PWE3-ETH] Martini, L., et al., ôEncapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networksö, draft- ietf-pwe3-ethernet-encap-06.txt, April 2004. 11 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 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 Aissaoui, et al. Expires January 2005 [Page 16] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt July 2004 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 12 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 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 January 2005 [Page 17]