[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 draft-ietf-l2vpn-vpws-iw-oam

      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: <AC, PW, AC> [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: <ATM AC, ATM PW, ATM AC>.
  
     A L2 VPN circuit is heterogeneous if any two segments of the
     circuit are of different types. E.g., IP interworking circuit:
     <ATM AC, IP PW, ATM AC>, or <ATM AC, IP PW, FR AC>.
  
     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 <draft-ietf-l2tpext-l2tp-base-15.txt>,
          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]
  

Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/