L2VPN Working Group Mustapha Aissaoui Internet Draft Matthew Bocci Expiration Date: August 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 Simon Delord France Telecom February 2005 OAM Procedures for VPWS Interworking draft-aissaoui-l2vpn-vpws-iw-oam-03.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. Aissaoui, et al. Expires August 2005 [Page 1] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 Abstract This draft proposes OAM procedures for the Ethernet interworking, IP interworking and FR-ATM interworking Virtual Private Wire Service (VPWS). Table of Contents Status of this Memo.............................................1 Abstract........................................................2 Table of Contents...............................................2 1 Conventions used in this document.............................3 2 Terminology...................................................3 3 Introduction..................................................5 4 General OAM Procedures........................................5 4.1 Defect Locations...........................................5 4.2 Abstract Defect States.....................................6 4.3 VPWS OAM Interworking Models...............................7 4.4 PW Entry/Exit Criteria.....................................8 4.4.1 PW Forward Defect Entry...............................8 4.4.2 PW Reverse Defect Entry...............................9 4.4.3 PW reverse defects that are treated as AC Forward Defects.....................................................9 4.4.4 PW Forward Defect Exit...............................10 4.4.5 PW Reverse Defect Exit...............................10 4.5 ATM AC Defect Entry/Exit Criteria.........................10 4.5.1 Forward Defect Entry.................................10 4.5.2 Forward Defect Exit..................................11 4.5.3 Reverse Defect Entry.................................11 4.5.4 Reverse Defect Exit..................................11 4.6 FR AC Defect Entry/Exit...................................11 4.6.1 Forward Defect Entry Criteria........................11 4.6.2 Forward Defect Exit Criteria.........................12 4.7 Ethernet AC Defect Entry/Exit Criteria....................12 4.7.1 Forward Defect State Entry...........................12 4.7.2 Forward Defect State Exit............................12 5 AC Defect Entry/Exit Procedures..............................12 5.1 AC Forward defect entry:..................................12 5.1.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs......12 5.1.2 Procedures for ATM cell PWs..........................12 5.1.3 Additional procedures for ATM ACs....................13 5.2 AC Reverse defect entry...................................13 5.2.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs......13 5.2.2 Procedures for ATM cell PWs..........................13 5.3 AC Forward Defect Exit....................................13 Aissaoui, et al. Expires August 2005 [Page 2] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 5.3.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs......13 5.3.2 Procedures for ATM cell PWs..........................14 5.3.3 Additional procedures for ATM ACs....................14 5.4 AC Reverse Defect Exit....................................14 5.4.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs......14 5.4.2 Procedures for ATM cell PWs..........................14 6 PW Forward Defect Entry/Exit procedures......................15 6.1 PW Forward Defect Entry Procedures........................15 6.1.1 FR AC procedures.....................................15 6.1.2 Ethernet AC Procedures...............................15 6.1.3 ATM AC procedures....................................15 6.1.4 Additional procedures for FR, ATM AAL5, IP or Ethernet PWs........................................................15 6.1.5 Additional procedures for ATM Cell PWs...............16 6.2 PW Forward Defect Exit Procedures.........................16 6.2.1 FR AC procedures.....................................16 6.2.2 Ethernet AC Procedures...............................16 6.2.3 ATM AC procedures....................................16 6.2.4 Additional procedures for FR, ATM AAL5, IP or Ethernet PWs........................................................16 6.2.5 Additional procedures for ATM Cell PWs...............16 6.3 PW Reverse Defect Entry Procedures........................17 6.3.1 FR AC procedures.....................................17 6.3.2 Ethernet AC Procedures...............................17 6.3.3 ATM AC procedures....................................17 6.4 PW Reverse Defect Exit Procedures.........................17 6.4.1 FR AC procedures.....................................17 6.4.2 Ethernet AC Procedures...............................17 6.4.3 ATM AC procedures....................................17 7 Security Considerations......................................17 8 Intellectual Property Disclaimer.............................18 9 References...................................................18 10 Authors' Addresses..........................................19 11 Full Copyright Statement....................................21 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 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. Aissaoui, et al. Expires August 2005 [Page 3] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 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. A PE interworks or adapts an AC onto a PW (depending on whether it terminates the attachment circuit or the AC corresponds to the NS for the PW). The other PE that terminates the PW is the ææpeerÆÆ PE and the attachment circuit associated with the far end PW termination is the ææremote ACÆÆ. Defects are discussed in the context of defect states, and the criteria to enter and exit the defect state. The direction of defects is discussed from the perspective of the observing PE and what the PE may explicitly know about information transfer capabilities of the VPWS service. A forward defect is one that impacts information transfer to the observing PE. It impacts the observing PEÆs ability to receive information. A forward defect MAY also imply impact on information sent or relayed by the observer (and as it cannot receive is therefore unknowable) and so the forward defect state is considered to be a superset of the two defect states. A reverse defect is one that uniquely impacts information sent or relayed by observer. At the present time code points for forward defect and reverse defect have not been specified for BFD and LDP PW control. These are referred to as ææforward defectÆÆ and ææreverse defectÆÆ indications as placeholders for code point assignment. A crude mapping may be performed between current code points in [IANA]: Forward defect - corresponds to the logical OR of Local Attachment Circuit ( ingress ) Receive Fault AND Local PSN-facing PW ( egress ) Transmit Fault Reverse defect - corresponds to the logical OR of Local Attachment Circuit ( egress ) Transmit Fault Aissaoui, et al. Expires August 2005 [Page 4] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 AND Local PSN-facing PW ( egress ) Transmit Fault 3 Introduction This draft augments OAM message mapping [OAM-MSG] with OAM procedures for scenarios when the attachment circuit does not correspond to the pseudo wire. When combined with procedures defined in [OAM-MSG], comprehensive OAM interworking can be defined for VPWS services. VPWS services 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]. 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 Aissaoui, et al. Expires August 2005 [Page 5] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 Figure 1: VPWS Defect Locations In all interworking scenarios described in this document, it is assumed that at PE1 the AC does not correspond to the PW. The procedures described in this document exclusively apply to PE1. PE2 either implements the procedures described in this document or those in [OAM-MSG]. The notifications received from PE2 and consequent actions taken at PE1 will be common to both scenarios. 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 (which is considered a ææremote AC defectÆÆ in the context of procedures outlined in this draft). 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 (which is also considered a ææremote AC defectÆÆ in the context of this draft). 4.2 Abstract Defect States PE1 is obliged to track four abstract defect states that reflect the observed state of both directions of the VPWS service on both the AC and the PW sides. Faults may impact only one or both directions of the PW. The observed state is a combination of faults directly detected by PE1, or faults it has been made aware of via notifications. +-----+ ----AC forward---->| |-----PW reverse----> CE1 | PE1 | PE2/CE2 <---AC reverse-----| |<----PW forward----- +-----+ (arrows indicate direction of traffic) Figure 2: Forward and Reverse Defect States PE1 will directly detect or be notified of AC forward and PW forward defects as they occur upstream of PE1 and impact traffic Aissaoui, et al. Expires August 2005 [Page 6] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 being sent to PE1. PE1 will only be notified of AC reverse and PW reverse defects as they universally will be detected by other devices and only impact traffic that has already been relayed by PE1. The procedures outlined in this document define the entry and exit criteria for each of the four states with respect to the set of potential ACs and PWs within the document scope and the consequent actions that PE1 must perform to properly interwork those notifications. The abstract defect states used by PE1 are common to all potential interworking combinations of PWs and ACs. 4.3 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 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. Some homogenous scenarios use PW OAM mechanisms to synchronize VPWS state between PEs due to discontinuities in native service OAM between the AC and the PW (e.g. FR LMI), or lack of native service OAM (e.g. Ethernet). 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 as the default mechanism for AC and PW status and defect indication [PWE3-CONTROL]. If the PEs have negotiated the use of VCCV-BFD for PW fault detection and AC/PW fault notifications as explained in [VCCV] then BFD is the preferred mechanism. 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]. Aissaoui, et al. Expires August 2005 [Page 7] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 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 an ATM cell mode PW to achieve this. 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 | ------------------------------------------------------------------ |Ethernet Interworking | | X | ------------------------------------------------------------------ |IP Interworking | | X | ------------------------------------------------------------------ Table 1: Summary of VPWS OAM Interworking 4.4 PW Entry/Exit Criteria 4.4.1 PW Forward Defect Entry PE1 enters the forward defect state if any of the following conditions are met: (i) It detects or is notified of a defect upstream of PE1 in the PSN tunnel over which the PW is riding. Defects detected explicitly include the 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]. The assumption is that deployed PSN resiliency mechanisms have not been sufficient to recover from the defect and restore connectivity to the peer PE. Notifications of defects remote from the PE include Y.1711 FDI/BDI, BFD and RSVP-TE PathErr message. (ii) It receives a message from the remote PE indicating a forward defect. In the case of a MPLS PSN and a MPLS-IP PSN, this is a PW status message [PWE3-CONTROL] or BFD diagnostic code indicating a "Forward defect", or "PW not forwarding". Aissaoui, et al. Expires August 2005 [Page 8] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 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. This is typically used for local defects in a PE which impact only a specific session and the corresponding PW. (iii) 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. (iv) 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. 4.4.2 PW Reverse Defect Entry For PWE3 over a MPLS PSN and a MPLS-IP PSN, PE1 enters the PW reverse defect state when the following conditions are true: (i) The status communicated by PE2 via BFD or LDP status TLV indicates a reverse defect 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 have disappeared, AND (ii) A L2TPv3 session is successfully established to carry the PW packets. 4.4.3 PW reverse defects that are treated as AC Forward Defects Some PW mechanisms will result in PW defects being detected by or notified to PE1 when PE1 is upstream of the fault but the notification did not originate with PE2. The resultant actions are identical to that of entering the AC forward defect state as PE1 needs to synchronize state with PE2 and the PW state communicated from PE1 to PE2 needs to indicate state accordingly. Aissaoui, et al. Expires August 2005 [Page 9] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 When the PSN uses RSVP-TE or proactively uses LSP-PING as a PW fault detection mechanism, PE1 must consider entry to the AC forward defect state to be the logical or of the AC entry criteria outlined for each AC type in the subsequent sections, and that of the known PW state in the direction of PE2 downstream of PE1 (indicated via RSVP patherr or LSP-PINGs). The exit criteria being when the logical AND of the RSVP fault state, LSP-PING fault state and the actual AC forward defect exit criteria has been met, indicating no forward defects. 4.4.4 PW Forward Defect Exit For PWE3 over a MPLS PSN and a MPLS-IP PSN, PE1 exits the PW Forward state when the following conditions are true: (ii) The status communicated by PE2 via BFD or LDP status TLV no longer indicates a forward defect AND (iii) Local indications (BFD processing etc.) indicate that PW and PSN connectivity exists. For a PWE3 over a L2TP-IP, a PE exits the PW DOWN state when the following conditions are true: (iii) All defects it had previously detected have disappeared, and (iv) A L2TPv3 session is successfully established to carry the PW packets. 4.4.5 PW Reverse Defect Exit For PWE3 over a MPLS PSN and a MPLS-IP PSN, PE1 exits the PW Reverse defect state when the following conditions are true: (i) The status communicated by PE2 via BFD or LDP status TLV no longer indicates a reverse defect 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 have disappeared, and (ii) A L2TPv3 session is successfully established to carry the PW packets. 4.5 ATM AC Defect Entry/Exit Criteria 4.5.1 Forward Defect Entry PE1 enters the AC forward defect state if any of the following conditions are met: (i) It detects a physical layer alarm on the ATM interface. Aissaoui, et al. Expires August 2005 [Page 10] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 (ii) It receives an F5 AIS 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. Note that all interworking VPWS referred to in this document make use of ATM VCCs as the AC. ATM VPC cannot be terminated directly on an interworking VPWS. Therefore only F5 OAM messages are relevant. 4.5.2 Forward Defect Exit PE1 exits the AC forward defect state when all defects it had previously detected have disappeared. The exact conditions under which a PE exits AIS or declares that connectivity is restored via ATM CC are explained in I.610 [I.610]. Note that it is possible to transition directly from the forward to the reverse defect states. 4.5.3 Reverse Defect Entry PE1 enters the AC reverse defect state if: (i) It terminates the ATM layer and it receives an F5 RDI OAM cell indicating that the ATM VP/VC is down in the adjacent L2 ATM network (e.g., N1 for PE1). 4.5.4 Reverse Defect Exit PE1 exits the AC reverse defect state if: (i) It enters the forward defect state OR (ii) All defects it had previously detected have disappeared. The exact conditions under which a PE exits the RDI state are explained in I.610 [I.610]. 4.6 FR AC Defect Entry/Exit Note that the FR AC ææinactiveÆÆ state, as communicated by the FR LMI, does not indicate direction but is assumed to be the equivalent of a forward defect and is translated to same. The reverse defect state is not valid for an FR AC. 4.6.1 Forward Defect Entry Criteria PE1 enters the AC forward defect state 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. Aissaoui, et al. Expires August 2005 [Page 11] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 (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. 4.6.2 Forward Defect Exit Criteria A PE exits the FR AC Down state when all defects it had previously detected have disappeared. 4.7 Ethernet AC Defect Entry/Exit Criteria Ethernet AC failures are translated directly into AC forward defects. The reverse defect state is not valid for Ethernet ACs. 4.7.1 Forward Defect State Entry PE1 enters the AC forward defect state if any of the following conditions are met: (i) A physical layer alarm is detected on the Ethernet interface. 4.7.2 Forward Defect State Exit A PE exits the Ethernet AC Down state when all defects it had previously detected have disappeared. 5 AC Defect Entry/Exit Procedures 5.1 AC Forward defect entry: On entry to the forward defect state, PE1 may need to perform procedures on both the PW and the AC. 5.1.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs On entry to the AC forward defect state, PE1 notifies PE2 of a forward defect: For PW over MPLS PSN or MPLS-IP PSN (i) A PW Status message indicating ææforward defectÆÆ, or (ii) A VCCV-BFD diagnostic code of ææforward defectÆÆ if the optional use of VCCV-BFD notification has been negotiated. For PW over L2TP-IP PSN (i) An L2TP Set-Link Info (LSI) message with a Circuit Status AVP indicating "inactive", or (ii) A VCCV-BFD diagnostic code of ææforward defectÆÆ if the optional use of VCCV-BFD notification has been negotiated. 5.1.2 Procedures for ATM cell PWs On entry to the AC forward defect state, PE1 MUST: Aissaoui, et al. Expires August 2005 [Page 12] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 a. Commence insertion of ATM AIS cells into the corresponding PW. b. If PE1 is originating F5 I.610 CC cells, PE1 will suspend CC generation for the duration of the defect state. 5.1.3 Additional procedures for ATM ACs On entry to the AC forward defect state PE1 will commence RDI insertion into the AC as per I.610. 5.2 AC Reverse defect entry 5.2.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs On entry to the AC reverse defect state, PE1 notifies PE2 of a reverse defect: For PW over MPLS PSN or MPLS-IP PSN (iii) A PW Status message indicating ææreverse defectÆÆ, or (iv) A VCCV-BFD diagnostic code of ææreverse defectÆÆ if the optional use of VCCV-BFD notification has been negotiated.. For PW over L2TP-IP PSN (iii) An L2TP Set-Link Info (LSI) message with a Circuit Status AVP indicating "inactive", or (iv) A VCCV-BFD diagnostic code of ææreverse defectÆÆ if the optional use of VCCV-BFD notification has been negotiated. 5.2.2 Procedures for ATM cell PWs ATM AC would be the only potential source of AC reverse defect state within the scope of this document. However, There are no procedures in this case as the AC reverse defect state is not valid for PE1 with a ATM AC and a ATM cell mode PW. 5.3 AC Forward Defect Exit 5.3.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs On exit from the AC forward defect state PE1 notifies PE2 that the forward defect state has cleared (note that this may be a direct state transition to either the working state or the reverse defect state): For PW over MPLS PSN or MPLS-IP PSN (i) A PW Status message with forward defect clear and the remaining indicators showing either working or reverse defect state, or (ii) A VCCV-BFD diagnostic code with the same attributes as (i) if the optional use of VCCV-BFD notification has been negotiated. Aissaoui, et al. Expires August 2005 [Page 13] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 For PW over L2TP-IP PSN (i) An L2TP Set-Link Info (LSI) message with a Circuit Status AVP indicating "active", or (ii) A VCCV-BFD diagnostic code with the same attributes as (i) if the optional use of VCCV-BFD notification has been negotiated. 5.3.2 Procedures for ATM cell PWs On exit from the AC forward defect state, PE1 MUST: (i) Cease insertion of ATM AIS cells into the corresponding PW. (ii) If PE1 is originating F5 I.610 CC cells, PE1 will resume CC generation for the duration of the defect state. If the transition is to the AC reverse defect state, the corresponding procedures apply. 5.3.3 Additional procedures for ATM ACs On exit from the AC forward defect state PE1 will cease RDI insertion into the AC as per I.610. 5.4 AC Reverse Defect Exit 5.4.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs On exit from the AC reverse defect state, PE1 notifies PE2 that the reverse defect state has cleared (note that this may be a direct state transition to either the working state or the forward defect state). Depending on the negotiated notification mechanism this will be one of: For PW over MPLS PSN or MPLS-IP PSN (i) A PW Status message with the ææreverse defectÆÆ indicator cleared and the remaining indicators showing either working or a transition to the ææforward defectÆÆ state, or (ii) A VCCV-BFD diagnostic code with the same information as (i) if the optional use of VCCV-BFD notification has been negotiated. For PW over L2TP-IP PSN (i) An L2TP Set-Link Info (LSI) message with a Circuit Status AVP indicating "active", or (ii) A VCCV-BFD diagnostic code with the same information as (i) if the optional use of VCCV-BFD notification has been negotiated. 5.4.2 Procedures for ATM cell PWs ATM AC would be the only potential source of AC reverse defect state within the scope of this document. However, there are no procedures in this case as the AC reverse defect state is not valid for PE1 with a ATM AC and a ATM cell mode PW. Aissaoui, et al. Expires August 2005 [Page 14] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 6 PW Forward Defect Entry/Exit procedures 6.1 PW Forward Defect Entry Procedures 6.1.1 FR AC procedures These procedures are applicable only if the transition from the working state to the PW Forward defect state. A transition from PW reverse defect state to the forward defect state does not require any additional notification procedures to the FR AC as it has already been told the peer is down. (i) 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. 6.1.2 Ethernet AC Procedures No procedures are currently defined. 6.1.3 ATM AC procedures On entry to the PW Forward Defect State (i) PE1 MUST commence F5 AIS insertion into the corresponding AC. (ii) PE1 MUST terminate any F5 CC generation on the corresponding AC. 6.1.4 Additional procedures for FR, ATM AAL5, IP or Ethernet PWs If the PW failure was explicitly detected by PE1, it MUST assume PE2 has no knowledge of the defect and MUST notify PE2 in the form of a reverse defect notification: For PW over MPLS PSN or MPLS-IP PSN (i) A PW Status message indicating a ææreverse defectÆÆ, or (ii) A VCCV-BFD diagnostic code indicating a ææreverse defectÆÆ if the optional use of VCCV-BFD notification has been negotiated. For PW over L2TP-IP PSN (i) An L2TP Set-Link Info (LSI) message with a Circuit Status AVP indicating "active", or (ii) A VCCV-BFD diagnostic code with the same attribute as (i) if the optional use of VCCV-BFD notification has been negotiated. Otherwise the entry to the defect state was the result of a notification from PE2 (indicating that PE2 already had knowledge of the fault) or loss of the control adjacency (similarly visible to PE2). Aissaoui, et al. Expires August 2005 [Page 15] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 6.1.5 Additional procedures for ATM Cell PWs If the PW failure was explicitly detected, by PE1 by entering to the ATM AIS state or loss of CC, PE1 MUST also commence RDI insertion into the reverse direction of the PW. 6.2 PW Forward Defect Exit Procedures 6.2.1 FR AC procedures On transition from the PW forward defect state to the reverse defect state PE1 takes no action with respect to the AC. On exit from the PW Forward defect state (i) PE1 MUST generate a full status report with the Active bit = 1 (and optionally in the asynchronous status message), as per Q.933 annex A, into N1 for the corresponding FR ACs. 6.2.2 Ethernet AC Procedures No procedures are currently defined 6.2.3 ATM AC procedures On exit from the PW Forward Defect State (i) PE1 MUST cease F5 AIS insertion into the corresponding AC. (ii) PE1 MUST resume any F5 CC generation on the corresponding AC. 6.2.4 Additional procedures for FR, ATM AAL5, IP or Ethernet PWs If the PW failure was explicitly detected by PE1, it MUST notify PE2 in the form of clearing the reverse defect notification: For PW over MPLS PSN or MPLS-IP PSN (i) A PW Status message with the ææreverse defectÆÆ indication clear, and the remaining indicators showing either working or a transition to the ææforward defectÆÆ state, or (ii) A VCCV-BFD diagnostic code with the same attribute as in (i) if the optional use of VCCV-BFD notification has been negotiated. For PW over L2TP-IP PSN (i) An L2TP Set-Link Info (LSI) message with a Circuit Status AVP indicating "active", or (ii) A VCCV-BFD diagnostic code with the same attributes as (i) if the optional use of VCCV-BFD notification has been negotiated. 6.2.5 Additional procedures for ATM Cell PWs On exit from the PW forward defect state, PE1 will cease F5 RDI generation into the corresponding PW. Aissaoui, et al. Expires August 2005 [Page 16] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 6.3 PW Reverse Defect Entry Procedures 6.3.1 FR AC procedures On transition from the PW forward defect state to the reverse defect state PE1 takes no action with respect to the AC. On entry to the PW Forward defect state (i) 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. 6.3.2 Ethernet AC Procedures No procedures are currently defined 6.3.3 ATM AC procedures On entry to the PW Reverse Defect State (i) PE1 MUST commence F5 RDI insertion into the corresponding AC. 6.4 PW Reverse Defect Exit Procedures 6.4.1 FR AC procedures On transition from the PW reverse defect state to the PW forward defect state PE1 takes no action with respect to the AC. On exit from the PW Reverse defect state (i) PE1 MUST generate a full status report with the Active bit = 1 (and optionally in the asynchronous status message), as per Q.933 annex A, into N1 for the corresponding FR ACs. 6.4.2 Ethernet AC Procedures No procedures are currently defined 6.4.3 ATM AC procedures On exit from the PW Reverse Defect State (i) PE1 MUST cease F5 RDI insertion into the corresponding AC. 7 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. Aissaoui, et al. Expires August 2005 [Page 17] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 8 Intellectual Property Disclaimer This document is being submitted for use in IETF standards discussions. 9 References [ARP-MEDIATION] Shah, H., et al., ææARP Mediation for IP interworking of Layer 2 VPNÆÆ, draft-ietf-l2vpn-arp-mediation- 00.txt, October 2004. [FRF8.2] Frame Relay Forum, ææFRF 8.2 - Frame Relay / ATM PVC Service Interworking Implementation AgreementÆÆ, February 2004. [FRF.19] Frame Relay Forum, ææFrame Relay Operations, Administration, and Maintenance Implementation AgreementÆÆ, March 2001. [I.610] ææB-ISDN operation and maintenance principles and functionsÆÆ, ITU-T Recommendation I.610, February 1999. [IANA] Martini, L. et.al., ææIANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)ÆÆ, draft-ietf-pwe3-iana-allocation- 07.txt, October 2004 [L2TPv3] Lau, J., et.al. " Layer Two Tunneling Protocol (Version 3", Internet Draft , December 2004 [L2VPN-FRMK] Andersson, L. et. al., "L2VPN Framework", draft-ietf- l2vpn-l2-framework-05.txt, 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-07.txt, October 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. [OAM-MSG] Nadeau, T., et al., ææPseudo Wire (PW) OAM Message MappingÆÆ, draft-ietf-pwe3-oam-msg-map-02.txt, February 2005. [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. Aissaoui, et al. Expires August 2005 [Page 18] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 [PWE3-CONTROL] Martini, L., et al., ææPseudowire Setup and Maintenance using LDPÆÆ, draft-ietf-pwe3-control-protocol- 14.txt, December 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. [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. [VCCV] Nadeau, T., et al., ææPseudo Wire (PW) Virtual Circuit Connection Verification (VCCV)ÆÆ, draft-ietf-pwe3-vccv-04.txt, February 2005. [Y.1711] ææOAM Mechanisms for MPLS NetworksÆÆ, ITU-T Recommendation Y.1711, November 2002. 10 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 Aissaoui, et al. Expires August 2005 [Page 19] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 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 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 Simon Delord France Telecom 2 av, Pierre Marzin 22300 LANNION, France E-mail: simon.delord@francetelecom.com Aissaoui, et al. Expires August 2005 [Page 20] Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt February 2005 11 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 August 2005 [Page 21]