L2VPN Working Group Mustapha Aissaoui Internet Draft Matthew Bocci Expiration Date: April 2005 David Watkinson Alcatel Hamid Ould-Brahim Mike Loomis Himanshu Shah David Allan Ciena Nortel Paul Doolan Thomas D. Nadeau Mangrove Systems Monique Morrow Cisco Systems Peter Busschbach Lucent Technologies John Z. Yu Hammerhead Systems October 2004 OAM Procedures for VPWS Interworking draft-aissaoui-l2vpn-vpws-iw-oam-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 April 2005 [Page 1] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 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..................9 5.1.1 FR PW and ATM PW with AAL5-mode encapsulation.........9 5.1.2 ATM PW with cell-mode encapsulation..................10 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..................11 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 IP Interworking VPWS......................14 6.1 FR Network and Attachment Circuit Defects.................14 6.2 ATM Network and Attachment Circuit Defects................14 6.3 Ethernet Network and Attachment Circuit Defects...........15 6.4 PW Defects................................................15 7 OAM Procedures for Ethernet Interworking VPWS................17 8 Security Considerations......................................17 9 Intellectual Property Disclaimer.............................17 10 References..................................................17 11 Authors' Addresses..........................................18 12 Full Copyright Statement....................................20 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 April 2005 [Page 2] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 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 [MPLS-in-IP], 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. 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 April 2005 [Page 3] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 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. In a homogeneous VPWS circuit, the AC link layer is emulated by the PW by extending it across the PSN. This has the implication Aissaoui, et al. Expires April 2005 [Page 4] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 2004 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 detects a defect in the attached ATM AC or receives AIS cells as a result of a defect in the local ATM network,it will always reply with RDI cells to close the local defect loop.. At the same time, the PE should always relay over the PW the defect state of a received F4/F5 RDI from the local CE, thus treating it as a separate defect event. 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 | | ------------------------------------------------------------------ |FR-ATM Interworking | | | |- FR or AAL5 PDU/SDU PW| | X | Aissaoui, et al. Expires April 2005 [Page 5] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 2004 ------------------------------------------------------------------ |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. 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]. This is typically used for defects in the PSN which impact both the control connection and the individual data plane sessions. 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 April 2005 [Page 6] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 2004 This is typically used for local defects in a PE which impact only a specific session and the corresponding PW. (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. (v) Note that if the PW control session between the PEs fails, the PW is torn down and needs to be re-established. However, the consequent actions towards the ACs are the same as if the PW state were 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. 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 Aissaoui, et al. Expires April 2005 [Page 7] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 2004 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. 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 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 Aissaoui, et al. Expires April 2005 [Page 8] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 2004 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 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. e. PE2 MUST treat this as a separate defect from the original remote AC defect and MUST generate a PW status message indicating ææAC Transmit FaultÆÆ towards PE1. f. PE1 MUST terminate the received PW status message and does not perform any additional action since it is sourcing a Q.933 Status Message to CE1 indicating that the corresponding FR VCs are down. 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. e. PE2 MUST treat this as a separate defect from the original remote AC defect and MUST generate an L2TP Set-Link Info (LSI) message with a Circuit Status AVP indicating "inactive" towards PE1. f. PE1 MUST terminate the received PW status message and does not perform any additional action since it is sourcing a Q.933 Status Message to CE1 indicating that the corresponding FR VCs are down. Aissaoui, et al. Expires April 2005 [Page 9] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 2004 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 since it is sourcing a Q.933 Status Message to CE1 indicating that the corresponding FR VCs are down. 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. 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 Aissaoui, et al. Expires April 2005 [Page 10] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 2004 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. 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 for the direction of the defect. 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ÆÆ. If only the Transmit direction is down, PE1 MUST generate a PW status message indicating ææLocal PSN-facing PW (egress) Transmit FaultÆÆ. 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 a ææPW not forwardingÆÆ or a ææLocal PSN- facing PW (egress) Transmit FaultÆÆ status message, PE2 MUST generate a F5 AIS on the affected ACs to convey this status to the ATM network (N2) and CE2. On reception of a ææLocal PSN-facing PW (ingress) Receive FaultÆÆ status Aissaoui, et al. Expires April 2005 [Page 11] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 2004 message, PE2 MUST generate a F4/F5 RDI on the related ATM ACs towards CE2. f. CE2 replies with a F5 RDI in response to the received F5 AIS only. PE2 MUST terminate the F5 RDI and treat it as a separate defect from the original PW defect. It MUST generate a PW status message indicating ææAC Transmit FaultÆÆ towards PE1.PE1 MUST terminate the received PW status message and does not perform any additional action since it is sourcing a Q.933 Status Message to CE1 indicating that the corresponding FR VCs are down.. 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 for both directions. 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. PE1 MUST send an L2TPv3 CDN message or a StopCCN message to inform PE2 that it had disconnected the corresponding L2TPv3 sessions. 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 has disconnected the corresponding L2TPv3 sessions. 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 PW UP state is the result of the successful re-establishment of a L2TPv3 session to carry the PW packets.. 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 Aissaoui, et al. Expires April 2005 [Page 12] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 2004 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 Receive direction detected a PE2. If however, PE1 detects the defect in the transmit direction through a time-out of a connectivity verification mechanism such as LSP-Ping or VCCV-Ping, it MUST generate a PW status message indicating ææLocal PSN-facing PW (egress) Transmit FaultÆÆ and forward it to PE2. On reception of this message, PE2 will follow the same procedures described below for a defect in the PW Receive direction detected at 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 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 forward 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 Aissaoui, et al. Expires April 2005 [Page 13] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 2004 status message), as per Q.933 annex A, into N1 for the corresponding FR ACs. If only the PW Transmit direction is DOWN at PE2, this is generally detected by PE1 through a PSN or a PW continuity checking or connectivity verification mechanism as explained in Section 4.3.1. PE2 is notified through the return path of that specific mechanism. In this case, PE1 will follow the procedures described above for a defect in the PW Receive direction detected at PE1. If however, PE2 detects the defect in the transmit direction through a time-out of a connectivity verification mechanism such as LSP-Ping or VCCV-Ping, it MUST generate a PW status message indicating ææLocal PSN-facing PW (egress) Transmit FaultÆÆ and forward it to PE1. On reception of this message, PE1 will follow the same procedures described above for a defect in the PW Receive direction detected at PE1. 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 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]. For clarity of the text, it is assumed that the ACs attached to PE1 in Figure 1 are of Ethernet type. Similarly, it is assumed that the ACs attached to PE2 are of either Ethernet type, ATM type, or FR type. 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. If an egress PE determines that all ACs on a specific Ethernet physical interface are affected, it MAY propagate these alarms by bringing the entire physical interface down. 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. If an egress PE determines that all ACs on a specific Ethernet physical interface are affected, it MAY Aissaoui, et al. Expires April 2005 [Page 14] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 2004 propagate these alarms by bringing the entire physical interface down. 6.3 Ethernet Network and Attachment Circuit Defects 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.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. In the case of a remote Ethernet AC, this draft does not procedures the remote PE performs on the Ethernet AC once it is notified of the defect. If an egress PE determines that all ACs on a specific Ethernet physical interface are affected, it MAY propagate these alarms by bringing the entire physical interface down. 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 following procedures: a. PE1 MUST change the state of the affected PWs to DOWN for the direction of the defect. b. If both directions of the PW are down, PE1 MUST generate a PW status message indicating ææPW not forwardingÆÆ. If only the Transmit direction is down, PE1 MUST generate a PW status message indicating ææLocal PSN-facing PW (egress) Transmit FaultÆÆ. c. 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ÆÆ. d. When the remote AC is ATM, PE2 and PE1 MUST follow these procedures: i. On reception of the a ææPW not forwardingÆÆ or a ææLocal PSN-facing PW (egress) Transmit FaultÆÆ status message, PE2 MUST generate a F5 AIS on the affected ACs to convey this status to the ATM network (N2) and CE2. On reception of a ææLocal PSN-facing PW (ingress) Receive FaultÆÆ status message, PE2 MUST generate a F4/F5 RDI on the related ATM ACs towards CE2. ii. CE2 replies with a F5 RDI in response to the received F5 AIS only. PE2 MUST terminate the F5 RDI and treat it as a separate defect from the original PW defect. It MUST generate a PW status message indicating ææAC Transmit FaultÆÆ towards PE1.PE1 MUST terminate the received PW status message and does not perform any additional. Aissaoui, et al. Expires April 2005 [Page 15] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 2004 e. When the remote AC is FR, PE2 MUST follow these procedures: iii. On reception of the a ææPW not forwardingÆÆ or a ææLocal PSN-facing PW (egress) Transmit FaultÆÆ status message, PE2 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 N2 for the corresponding FR ACs. f. When the remote AC is Ethernet, PE2 MUST follow these procedures: iv. On reception of the a ææPW not forwardingÆÆ or a ææLocal PSN-facing PW (egress) Transmit FaultÆÆ status message, PE2 marks the state of the PW to DOWN for the direction of the defect. No further procedures are defined in this document. 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 for both directions. b. PE1 MUST send an L2TPv3 CDN message or a StopCCN message to inform PE2 that it had disconnected the corresponding L2TPv3 sessions. c. When the remote AC is ATM, PE2 and PE1 MUST follow these procedures: i. 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. ii. CE2 replies with a F5 RDI. PE2 MUST terminate the F5 RDI since it has disconnected the corresponding L2TPv3 sessions. d. When the remote AC is FR, PE2 MUST follow these procedures: i. On reception of the CDN or StopCCN message, PE2 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 N2 for the corresponding FR ACs. e. When the remote AC is Ethernet, PE2 MUST follow these procedures: i. On reception of the CDN or StopCCN message, PE2 marks the state of the PW to DOWN. No further procedures are defined in this document. 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. No procedures are defined for an Ethernet AC. Aissaoui, et al. Expires April 2005 [Page 16] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 2004 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 PW UP state is the result of the successful re-establishment of a L2TPv3 session to carry the PW packets. This will result in clearing the alarm states in the remote PE, in CE1, and in CE2. 7 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. The OAM procedures for this VPWS type are the same as those for the IP 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. [FRF8.2] Frame Relay Forum, ææFRF 8.2 - Frame Relay / ATM PVC Service Interworking Implementation AgreementÆÆ, February 2004. [ARP-MEDIATION] Shah, H., et al., ææARP Mediation for IP interworking of Layer 2 VPNÆÆ, draft-ietf-l2vpn-arp-mediation- 00.txt, October 2004. [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-01.txt, October 2004. Aissaoui, et al. Expires April 2005 [Page 17] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 2004 [PWE3-ATM] Martini, L., et al., ææEncapsulation Methods for Transport of ATM Over IP and MPLS NetworksÆÆ, draft-ietf-pwe3- atm-encap-07.txt, October 2004. [PWE3-CONTROL] Martini, L., et al., ææPseudowire Setup and Maintenance using LDPÆÆ, draft-ietf-pwe3-control-protocol- 11.txt, October 2004. [PWE3-FR] Kawa, C., et al., ææFrame Relay over Pseudo-WiresÆÆ, draft-ietf-pwe3-frame-relay-03.txt, August 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-06.txt, July 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. [PWE3-ETH] Martini, L., et al., ææEncapsulation Methods for Transport of Ethernet Frames Over IP/MPLS NetworksÆÆ, draft- ietf-pwe3-ethernet-encap-08.txt, September 2004. [MPLS-in-IP] Worster. T., et al., ææEncapsulating MPLS in IP or Generic Routing Encapsulation (GRE)ÆÆ, draft-ietf-mpls-in-ip- or-gre-08.txt, June 2004. 11 Authors' Addresses Mustapha Aissaoui Alcatel 600 March Rd Kanata, ON, Canada. K2K 2E6 Email: mustapha.aissaoui@alcatel.com Aissaoui, et al. Expires April 2005 [Page 18] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 2004 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 David Allan Nortel Networks 3500 Carling Ave., Ottawa, Ontario, CANADA Email: dallan@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 Hammerhead Systems, Inc. 640 Clyde Court Mountain View, CA 94043 USA Phone: +1 650 210 3312 Email: john@hammerheadsystems.com Aissaoui, et al. Expires April 2005 [Page 19] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-02.txt October 2004 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). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Aissaoui, et al. Expires April 2005 [Page 20]