L2VPN Working Group Mustapha Aissaoui Internet Draft Matthew Bocci Expiration Date: December 2006 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 Vasile Radoaca West Ridge Networks June 2006 OAM Procedures for VPWS Interworking draft-ietf-l2vpn-vpws-iw-oam-01.txt Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. 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 Aissaoui, et al. Expires April 2006 [Page 1] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 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........................................................1 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 Status Notifications....................................9 4.5 L2TPv3 Control Connection Messages.........................9 4.6 BFD Fault Detection and Notification......................10 5 PW Entry/Exit Criteria.......................................11 5.1.1 PW Forward Defect Entry..............................11 5.1.2 PW Reverse Defect Entry..............................12 5.1.3 PW reverse defects that require PE state synchronization ...........................................................12 5.1.4 PW Forward Defect Exit...............................13 5.1.5 PW Reverse Defect Exit...............................13 6 AC Defect Entry/Exit Criteria................................13 6.1 ATM AC Defect Entry/Exit Criteria.........................13 6.1.1 Forward Defect Entry.................................13 6.1.2 Forward Defect Exit..................................14 6.1.3 Reverse Defect Entry.................................14 6.1.4 Reverse Defect Exit..................................14 6.2 FR AC Defect Entry/Exit...................................14 6.2.1 Forward Defect Entry Criteria........................14 6.2.2 Forward Defect Exit Criteria.........................14 6.3 Ethernet AC Defect Entry/Exit Criteria....................15 6.3.1 Forward Defect State Entry...........................15 6.3.2 Forward Defect State Exit............................15 7 AC Defect Entry/Exit Procedures..............................15 7.1 AC Forward defect entry:..................................15 7.1.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs......15 7.1.2 Procedures for ATM cell PWs..........................15 7.1.3 Additional procedures for ATM ACs....................15 7.2 AC Reverse defect entry...................................16 7.2.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs......16 7.2.2 Procedures for ATM cell PWs..........................16 7.3 AC Forward Defect Exit....................................16 Aissaoui, et al. Expires April 2006 [Page 2] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 7.3.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs......16 7.3.2 Procedures for ATM cell PWs..........................16 7.3.3 Additional procedures for ATM ACs....................17 7.4 AC Reverse Defect Exit....................................17 7.4.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs......17 7.4.2 Procedures for ATM cell PWs..........................17 8 PW Forward Defect Entry/Exit procedures......................17 8.1 PW Forward Defect Entry Procedures........................17 8.1.1 FR AC procedures.....................................17 8.1.2 Ethernet AC Procedures...............................18 8.1.3 ATM AC procedures....................................18 8.1.4 Additional procedures for FR, ATM AAL5, IP or Ethernet PWs........................................................18 8.1.5 Additional procedures for ATM Cell PWs...............18 8.2 PW Forward Defect Exit Procedures.........................19 8.2.1 FR AC procedures.....................................19 8.2.2 Ethernet AC Procedures...............................19 8.2.3 ATM AC procedures....................................19 8.2.4 Additional procedures for FR, ATM AAL5, IP or Ethernet PWs........................................................19 8.2.5 Additional procedures for ATM Cell PWs...............19 8.3 PW Reverse Defect Entry Procedures........................19 8.3.1 FR AC procedures.....................................19 8.3.2 Ethernet AC Procedures...............................20 8.3.3 ATM AC procedures....................................20 8.4 PW Reverse Defect Exit Procedures.........................20 8.4.1 FR AC procedures.....................................20 8.4.2 Ethernet AC Procedures...............................20 8.4.3 ATM AC procedures....................................20 9 Security Considerations......................................20 10 Intellectual Property Disclaimer..Error! Bookmark not defined. 11 References..................................................20 12 Authors' Addresses..........................................22 13 Full Copyright Statement....................................23 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 April 2006 [Page 3] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 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 notifications have not been specified for BFD and LDP PW Status signaling. 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 [PWE3-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 Aissaoui, et al. Expires April 2006 [Page 4] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 Local Attachment Circuit (egress) Transmit Fault 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 Aissaoui, et al. Expires April 2006 [Page 5] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 Edge 1 Edge 2 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----> defect state | | defect state CE1 | PE1 | PE2/CE2 <---AC reverse-----| |<----PW forward----- defect state | | defect state +-----+ (arrows indicate direction of user traffic impacted by a defect) Aissaoui, et al. Expires April 2006 [Page 6] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 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 being sent to PE1. In Figure 2, PE1 may be notified of a forward defect in the AC by receiving a Forward Defect indication, e.g., ATM AIS, from CE1. This defect impacts the ability of PE1 to receive user traffic from CE1 on the AC. PE1 can also directly detect this defect if it resulted from a failure of the receive side in the local port or link over which the AC is configured. Similarly, PE1 may detect or be notified of a forward defect in the PW by receiving a Forward Defect indication from PE2. This notification can either be a "Local PSN-facing PW (egress) Transmit Fault" or a "Local Attachment Circuit (ingress) Receive Fault". This defect impacts the ability of PE1 to receive user traffic from CE2. Note that the AC or PW Forward Defect notification is sent in the same direction as the user traffic impacted by the defect. 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. In Figure 2, PE1 may be notified of a reverse defect in the AC by receiving a Reverse Defect indication, e.g., ATM RDI, from CE1. This defect impacts the ability of PE1 to send user traffic to CE1 on the AC. Similarly, PE1 may be notified of a reverse defect in the PW by receiving a Reverse Defect indication from PE2. This notification can either be a "Local PSN-facing PW (ingress) Receive Fault" or a "Local Attachment Circuit (egress) Transmit Fault". This defect impacts the ability of PE1 to send user traffic to CE2. Note that the AC or PW Reverse Defect notification is sent in the reverse direction to the user traffic impacted by the defect. 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 Aissaoui, et al. Expires April 2006 [Page 7] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 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 notification [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. The interaction of BFD and PW status is explained in more details in Section 4.5. 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]. 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 Aissaoui, et al. Expires April 2006 [Page 8] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 4.4 PW Status Notifications PW status signaling is the default mechanism for conveying the status of a PW and ACs between PEs in a MPLS PSN and a IP PSN using MPLS-in-IP (MPLS-IP PSN). [PWE3-IANA] defines the following valid PW status codepoints: 0x00000000 - Pseudo Wire forwarding (clear all failures) 0x00000001 - Pseudo Wire Not Forwarding 0x00000002 - Local Attachment Circuit (ingress) Receive Fault 0x00000004 - Local Attachment Circuit (egress) Transmit Fault 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 0x00000010 - Local PSN-facing PW (egress) Transmit Fault [PWE3-CONTROL] specifies that "Pseudo Wire forwarding" is used to clear all faults and that "Pseudo Wire Not Forwarding" is used to convey any other defects that cannot be represented by the other codepoints. The remaining codepoints map to the "forward defect" and "reverse defect" defined in this document as follows: 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 AND Local PSN-facing PW (ingress) Receive Fault Note that there are a couple of situations which require PW label withdrawal as opposed to a PW status notification by the PE. The first one is when the PW is taken administratively down in accordance to [PWE3-CONTROL]. The second one is when the Target LDP session established between the two PE's is lost. In the latter case, the PW labels will need to be re-signaled when the Targeted LDP session is re-established. 4.5 L2TPv3 Control Connection Messages For a L2TP-IP PSN, StopCCN and CDN messages are used for conveying defects which impact one or many PWs controlled by a given control connection. 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 Aissaoui, et al. Expires April 2006 [Page 9] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 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. Finally, the Set-Link-Info (SLI) messages are used to convey status and defects in the AC and local L2 network 4.6 BFD Fault Detection and Notification BFD is a mechanism which can be used to detect defects in the PW data path. This document specifies two uses of BFD. When used for PW fault detection only, a PE will continue to use PW status to report defects other than those detected by BFD. When used for both PW fault detection and all PW/AC fault notifications, PW status should not be used. This section describes the behavior of the PE nodes in both use cases. For a MPLS-PSN, the PE's negotiate the use of the VCCV capabilities when the label mapping messages are exchanged to establish the two directions of the PW. A new OAM capability TLV is signaled as part of the PW FEC interface parameters TLV. The CV Type Indicators field in this TLV defines a bitmask used to indicate the specific OAM capabilities that the PE can make use of over the PW being established. The defined values are: 0x01 ICMP Ping 0x02 LSP Ping (VCCV-Ping over a MPLS PSN and MPLS-IP PSN) 0x04 BFD for PW Fault Detection only 0x08 BFD for PW Fault Detection and AC/PW Fault Notification A CV type of 0x04 is part of the VCCV-BFD capability. It indicates that BFD is used for PW fault detection only. A BFD message will notify the remote PE of the fault and the latter enters into the proper PW defect state and triggers the appropriate actions as explained in the subsequent sections. All other PW and AC defects are indicated using PW status signaling. A CV type of 0x08 is also part of the VCCV-BFD capability. It indicates that BFD is used for both PW fault detection and AC/PW Fault Notification, even if the fault was not detected via BFD. In this case, PW status signaling messages should not be used. Similarly, [VCCV] describes a L2TPv3 VCCV Capability AVP which provides the equivalent means to signal OAM capabilities between PE's for PW's over a L2TP-IP PSN. [BFD] defined the following diagnostic codes: Code Message ---- ------------------------------ 0 No Diagnostic Aissaoui, et al. Expires April 2006 [Page 10] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 1 Control Detection Time Expired 2 Echo Function Failed 3 Neighbor Signaled Session Down 4 Forwarding Plane Reset 5 Path Down (Alarm Suppression) 6 Concatenated Path Down 7 Administratively Down 8 Reverse Concatenated Path Down 9-31 Reserved for future use [VCCV] states that, when used over PWs, the asynchronous mode of BFD should be used. Of these, 0 is used when the PW is up and 2 is not applicable to asynchronous mode. 3 is used as explained below. 6 and 8 are used to signal AC forward and reverse defect states respectively when the PE's negotiated the use of BFD as the mechanism for AC and PW fault detection and notification. The following are the BFD procedures for PW fault detection (valid for both CV types 0x04 and 0x08): When the downstream PE (PE1) does not receive control messages from the upstream PE (PE2) during a certain number of transmission intervals (a number provisioned by the operator), it declares that the PW in its receive direction is down. In other word, PE1 enters the "forward defect" state for this PW. PE1 sends a message to PE2 with H=0 (i.e. "I do not hear you") and with diagnostic code 1. In turn, PE2 declares the PW is down in its transmit direction and it uses diagnostic code 3 in its control messages to PE1. PE2 enters the "reverse defect" state for this PW. When a PW is taken administratively down, the PEs will withdraw the PW labels or will send L2TP CDN messages with code "Session disconnected for administrative reasons". In addition, exchange of BFD control messages MUST be suspended. To that end, the PEs MUST send control messages with H=0 and diagnostic code 7 5 PW Entry/Exit Criteria 5.1.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 Aissaoui, et al. Expires April 2006 [Page 11] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 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". (iii) It detects a loss of PW connectivity, including label errors, via an inband PW OAM connectivity verification, such as VCCV. 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. 5.1.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. This indicates PE2 detected or was notified of a PW/PSN fault upstream of it or that there was a remote AC fault and it is not already in the PW forward defect state. For a PWE3 over a L2TP-IP PSN, the PW reverse defect state is not valid and a PE can only enter the PW forward defect state. 5.1.3 PW reverse defects that require PE state synchronization 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 PW reverse defect state with the addition that PE1 needs to synchronize state with PE2 and the PW state communicated from PE1 to PE2 needs to indicate state accordingly. When the PSN uses RSVP-TE or proactively uses LSP-PING as a PW fault detection mechanism, PE1 must enter the AC forward defect. The exit criteria being when, the RSVP fault state or the LSP-PING fault state exit criteria has been met, indicating no PW reverse defects. Aissaoui, et al. Expires April 2006 [Page 12] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 5.1.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 Local indications (BFD processing etc.) indicate that PW and PSN connectivity is working in the forward direction. Note that this may result in a transition to the PW working or PW reverse defect states. 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. 5.1.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 or, (ii) PE1 has entered the PW forward defect state. 6 AC Defect Entry/Exit Criteria 6.1 ATM AC Defect Entry/Exit Criteria 6.1.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. (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. Aissaoui, et al. Expires April 2006 [Page 13] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 6.1.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. 6.1.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). 6.1.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]. 6.2 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. 6.2.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. (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. 6.2.2 Forward Defect Exit Criteria A PE exits the FR AC Down state when all defects it had previously detected have disappeared. Aissaoui, et al. Expires April 2006 [Page 14] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 6.3 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. 6.3.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. 6.3.2 Forward Defect State Exit A PE exits the Ethernet AC Down state when all defects it had previously detected have disappeared. 7 AC Defect Entry/Exit Procedures 7.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. 7.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. 7.1.2 Procedures for ATM cell PWs On entry to the AC forward defect state, PE1 MUST: 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. 7.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. Aissaoui, et al. Expires April 2006 [Page 15] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 7.2 AC Reverse defect entry 7.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. 7.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. 7.3 AC Forward Defect Exit 7.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. 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. 7.3.2 Procedures for ATM cell PWs On exit from the AC forward defect state, PE1 MUST: Aissaoui, et al. Expires April 2006 [Page 16] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 (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. If the transition is to the AC reverse defect state, the corresponding procedures apply. 7.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. 7.4 AC Reverse Defect Exit 7.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. 7.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. 8 PW Forward Defect Entry/Exit procedures 8.1 PW Forward Defect Entry Procedures 8.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 Aissaoui, et al. Expires April 2006 [Page 17] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 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. 8.1.2 Ethernet AC Procedures No procedures are currently defined. 8.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. 8.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). 8.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. Aissaoui, et al. Expires April 2006 [Page 18] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 8.2 PW Forward Defect Exit Procedures 8.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. 8.2.2 Ethernet AC Procedures No procedures are currently defined 8.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. 8.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. 8.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. 8.3 PW Reverse Defect Entry Procedures 8.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. Aissaoui, et al. Expires April 2006 [Page 19] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 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. 8.3.2 Ethernet AC Procedures No procedures are currently defined 8.3.3 ATM AC procedures On entry to the PW Reverse Defect State (i) PE1 MUST commence F5 RDI insertion into the corresponding AC. 8.4 PW Reverse Defect Exit Procedures 8.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. 8.4.2 Ethernet AC Procedures No procedures are currently defined 8.4.3 ATM AC procedures On exit from the PW Reverse Defect State (i) PE1 MUST cease F5 RDI insertion into the corresponding AC. 9 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. 10 References [ARP-MEDIATION] Shah, H., et al., "ARP Mediation for IP interworking of Layer 2 VPN", draft-ietf-l2vpn-arp-mediation- 05.txt, June 2006. Aissaoui, et al. Expires April 2006 [Page 20] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection", Internet Draft , June 2006 [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. [L2TPv3] Lau, J., et.al. " Layer Two Tunneling Protocol (Version 3", RFC 3931, March 2005. [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-02.txt, July 2005. [LSP-Ping] Kompella, K., et al., "Detecting MPLS Data Plane Liveness", RFC 4379, February 2006. [MPLS-in-IP] Worster. T., et al., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005. [OAM-MSG] Nadeau, T., et al., "Pseudo Wire (PW) OAM Message Mapping", draft-ietf-pwe3-oam-msg-map-04.txt, March 2006. [PWE3-ATM] Martini, L., et al., "Encapsulation Methods for Transport of ATM Over IP and MPLS Networks", draft-ietf-pwe3- atm-encap-11.txt, May 2006. [PWE3-CONTROL] Martini, L., et al., "Pseudowire Setup and Maintenance using LDP", RFC 4447, April 2006. [PWE3-ETH] Martini, L., et al., "Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks", RFC 4448, April 2006. [PWE3-FR] Kawa, C., et al., "Frame Relay over Pseudo-Wires", draft-ietf-pwe3-frame-relay-07.txt, February 2006. [PWE3-IANA] Martini, L. et.al., "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", RFC 4446, April 2006 [Q933AnnexA] ITU-T, "Additional procedures for Permanent Virtual Connection (PVC) status management", ITU-T Q.933 Annex A, February 2003. Aissaoui, et al. Expires April 2006 [Page 21] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 [VCCV] Nadeau, T., et al., "Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV)", draft-ietf-pwe3-vccv-09.txt, June 2006. [Y.1711] "OAM Mechanisms for MPLS Networks", ITU-T Recommendation Y.1711, November 2002. 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 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 Aissaoui, et al. Expires April 2006 [Page 22] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 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 Vasile Radoaca West Ridge Networks Littleton, MA 01460 Email: vradoaca@westridgenetworks.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any Aissaoui, et al. Expires April 2006 [Page 23] Internet Draft draft-ietf-l2vpn-vpws-iw-oam-00.txt October 2005 such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf ipr@ietf.org. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Aissaoui, et al. Expires April 2006 [Page 24]