[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: January 2005                        David Watkinson
                                                                   Alcatel
      Hamid Ould-Brahim
      Mike Loomis                                            Himanshu Shah
      Nortel                                                         Ciena
  
      Thomas D. Nadeau                                         Paul Doolan
      Monique Morrow                                      Mangrove Systems
      Cisco Systems
                                                          Peter Busschbach
      John Z. Yu                                       Lucent Technologies
      Hammerhead Systems
  
                                                                 July 2004
  
  
                    OAM Procedures for VPWS Interworking
                   draft-aissaoui-l2vpn-vpws-iw-oam-01.txt
  
  
  
   Status of this Memo
  
     This document is an Internet-Draft and is in full conformance with
     all provisions of section 10 of RFC 2026.
  
     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups. Note that
     other groups may also distribute working documents as Internet-
     Drafts.
  
     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time. It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress."
  
           The list of current Internet-Drafts can be accessed at
           http://www.ietf.org/ietf/1id-abstracts.txt.
  
     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.
  
  
  Abstract
  
     This draft proposes OAM procedures for the Ethernet interworking,
     IP interworking and FR-ATM interworking Virtual Private
     Wire Service (VPWS).
  
  
  
  Aissaoui, et al.         Expires January 2005                 [Page 1]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt      July 2004
  
  Table of Contents
  
     Status of this Memo.............................................1
     Abstract........................................................1
     Table of Contents...............................................2
     1 Conventions used in this document.............................2
     2 Terminology...................................................3
     3 Introduction..................................................3
     4 General OAM Procedures........................................4
      4.1 Defect Locations...........................................4
      4.2 VPWS OAM Interworking Models...............................4
      4.3 PW State...................................................6
         4.3.1 PW DOWN...............................................6
         4.3.2 PW UP.................................................7
      4.4 ATM AC State...............................................7
      4.5 FR AC State................................................8
      4.6 Ethernet AC State..........................................8
     5 OAM Procedures for FR-ATM Interworking VPWS...................8
      5.1 FR Network and Attachment Circuit Defects..................8
         5.1.1 FR PW and ATM PW with AAL5-mode encapsulation.........9
         5.1.2 ATM PW with cell-mode encapsulation...................9
      5.2 ATM Network and Attachment Circuit Defects................10
         5.2.1 FR PW and ATM PW with AAL5-mode encapsulation........10
         5.2.2 ATM PW with cell-mode encapsulation..................10
      5.3 PW Defects................................................11
         5.3.1 FR PW and ATM PW with AAL5-mode encapsulation........11
         5.3.2 ATM PW with cell-mode encapsulation..................12
     6 OAM Procedures for Ethernet Interworking VPWS................13
      6.1 FR Network and Attachment Circuit Defects.................13
      6.2 ATM Network and Attachment Circuit Defects................13
      6.3 Ethernet Network and Attachment Circuit Defects...........14
      6.4 PW Defects................................................14
     7 OAM Procedures for IP Interworking VPWS......................14
     8 Security Considerations......................................14
     9 Intellectual Property Disclaimer.............................14
     10 References..................................................14
     11 Authors' Addresses..........................................16
     12 Full Copyright Statement....................................17
  
  
   1 Conventions used in this document
  
     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
     NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
     in this document are to be interpreted as described in RFC 2119.
  
  
  
  
  
  Aissaoui, et al.         Expires January 2005                 [Page 2]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt      July 2004
  
   2 Terminology
  
     An end-to-end virtual circuit in a L2 VPN consists of a 3 segment
     set: <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.
  
     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, with
     a MPLS shim header used as PW demultiplexer, will be referred to
     as MPLS-IP PSN. A PSN which makes use of L2TPv3 [L2TPv3] as the
     tunneling technology will be referred to as L2TP-IP PSN.
  
   3 Introduction
  
     This draft proposes OAM procedures for the Virtual Private
     Wire Service (VPWS). VPWS are defined in the L2 VPN framework
     [L2VPN-FRMK].
  
     The following VPWS types are covered in this document:
  
  
     1. VPWS with heterogeneous ACs of ATM and FR types, and in which
        the PW type is ATM or FR. In this case, FR-ATM service
        interworking [FRF8.2] is performed in PE1 (or PE2) and a FR (or
        ATM) PW is extended to the remote PE. This VPWS type will be
        referred to as ôFR-ATM Interworking VPWSö.
  
     2. VPWS with heterogeneous ACs of ATM, FR, and Ethernet types, and
        in which the PW type is Ethernet [L2VPN-Interworking]. This
        VPWS type will be referred to as ôEthernet Interworking VPWSö.
  
     3. VPWS with heterogeneous ACs of ATM, FR, and Ethernet types, and
        in which the PW type is IP [ARP-Mediation]. This VPWS type will
        be referred to as ôIP Interworking VPWSö.
  
     OAM procedures for homogeneous VPWS circuits of ATM, FR, or
     Ethernet types are described in [OAM-MSG].
  
     The following topics are not covered and may be addressed in a
     future revision of this document:
  
     1.   ATM ILMI Interworking
  
  
  Aissaoui, et al.         Expires January 2005                 [Page 3]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt      July 2004
  
     2.   Handling of Loopback and CC OAM cells for ATM [I.610].
  
  
   4 General OAM Procedures
  
  
   4.1 Defect Locations
  
     Figure 1 illustrates a VPWS network model with an indication of
     the possible defect locations. This model will be referenced in
     the remainder of this document for describing the OAM procedures.
  
                    ACs           PSN tunnel           ACs
                        +----+                  +----+
        +----+          | PE1|==================| PE2|          +----+
        |    |---(a)---(b)  (c)......PW1...(d).(c)..(f)--(e)----|    |
        | CE1|   (N1)   |    |                  |    |   (N2)   |CE2 |
        |    |----------|............PW2.............|----------|    |
        +----+          |    |==================|    |          +----+
             ^          +----+                  +----+          ^
             |      Provider Edge 1         Provider Edge 2     |
             |                                                  |
             |<-------------- Emulated Service ---------------->|
       Customer                                                Customer
        Edge 1                                                  Edge 2
  
                     Figure 1: VPWS Defect Locations
  
     The following is a brief description of the defect locations:
  
     (a)  Defect in the first L2 network (N1). This covers any defect
          in the N1 which impacts all or a subset of ACs terminating in
          PE1. The defect is conveyed to PE1 and to the remote L2
          network (N2) using a L2 specific OAM defect indication.
     (b)  Defect on a PE1 AC interface.
     (c)  Defect on a PE PSN interface.
     (d)  Defect in the PSN network. This covers any defect in the PSN
          which impacts all or a subset of the PSN tunnels and PWs
          terminating in a PE. The defect is conveyed to the PE using a
          PSN and/or a PW specific OAM defect indication.
     (e)  Defect in the second L2 network (N2). This covers any defect
          in N2 which impacts all or a subset of ACs terminating in
          PE2. The defect is conveyed to PE2 and to the remote L2
          network (N1) using a L2 specific OAM defect indication.
     (f)  Defect on a PE2 AC interface.
  
  
   4.2 VPWS OAM Interworking Models
  
     There are two different OAM interworking models which are dictated
     by the type of VPWS.
  
  
  
  
  Aissaoui, et al.         Expires January 2005                 [Page 4]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt      July 2004
  
     In a homogeneous VPWS circuit, the AC link layer is emulated by
     the PW by extending it across the PSN. This has the implication
     that the native service OAM has to operate transparently across
     the PSN. In this case, the default OAM procedures are to use the
     native service OAM for both the AC and PW defect indications. This
     model is referred to as the homogeneous VPWS circuit OAM model. An
     example of this is ATM VPWS OAM procedures. Detailed OAM
     procedures for the homogeneous VPWS circuit types are described in
     [OAM-MSG].
  
     In a heterogeneous VPWS circuit, the AC link layer is terminated
     at a PE. Therefore, the native service OAM always terminates at
     the AC endpoint in the PE. In this case, the default OAM
     procedures are to terminate the native service OAM and to convey
     the corresponding defect state using a PW specific defect
     mechanism.. This model is referred to as the heterogeneous VPWS
     circuit OAM model and is the model suitable for the VPWS types
     covered in this document. For a MPLS PSN and a IP PSN using MPLS-
     in-IP (MPLS-IP PSN), PW status signaling messages are used for AC
     and PW status and defect indication [PWE3-CONTROL]. For a IP PSN
     using L2TPv3, i.e., a L2TP-IP PSN, StopCCN and CDN messages are
     used for conveying defects in the PSN and PW respectively, while
     the Set-Link-Info (SLI) messages are used to convey status and
     defects in the AC and local L2 network as detailed in [OAM-MSG].
  
     Note that the heterogeneous circuit OAM model assumes that the
     end-to-end circuit consists of three independent segments, <AC1,
     PW, AC2>, with defect states relayed across the boundary of these
     segments. This has important implications for the handling of ATM
     OAM at a PE. When a PE is notified of a defect in the remote L2
     network, in the remote AC, or in the PW, it will always generate a
     F4/F5 AIS message towards the local ATM network and local CE
     regardless of the stated direction of the defect. At the same
     time, the PE should not relay over the PW the defect state of a
     received F4/F5 RDI from the local CE if it is sourcing a F4/F5 AIS
     on the same AC towards that CE. These conditions maintain the
     independence of the three defect loops while relaying the defect
     states end-to-end. The procedures in sections 5, 6, and 7 satisfy
     these two conditions.
  
     Finally, it may be desirable to operate ATM OAM inband in the case
     of the FR-ATM interworking VPWS. This document proposes to use the
     homogeneous OAM circuit model together with a ATM cell mode PW to
     achieve this. This is explained in Section 5.
  
     Table 1 summarizes the OAM model used with each type of VPWS
     covered in this document.
     ------------------------------------------------------------------
     |VPWS Type              | Homogeneous Circuit | Heterogeneous    |
     |                       | OAM Model           | Circuit OAM Model|
     ------------------------------------------------------------------
     |FR-ATM Interworking    |                     |                  |
     |- ATM cell mode PW     |          X          |                  |
  
  Aissaoui, et al.         Expires January 2005                 [Page 5]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt      July 2004
  
     ------------------------------------------------------------------
     |FR-ATM Interworking    |                     |                  |
     |- FR or AAL5 PDU/SDU PW|                     |        X         |
     ------------------------------------------------------------------
     |Ethernet Interworking  |                     |        X         |
     ------------------------------------------------------------------
     |IP Interworking        |                     |        X         |
     ------------------------------------------------------------------
                 Table 1: Summary of VPWS OAM Interworking
  
  
   4.3 PW State
  
  
   4.3.1 PW DOWN
  
     A PE changes the state of a PW to DOWN if any of the following
     conditions are met:
  
     (i)    It detects a physical layer alarm on the PSN interface
             over which the PW is riding and cannot re-establish the PW
             over another PSN interface.
  
     (ii)   It detects a defect in the PSN tunnel over which the PW is
             riding and cannot re-establish the PW over another PSN
             tunnel.
  
             Defects include loss of connectivity, label swapping
             errors and label merging errors. In the case of a MPLS PSN
             and a MPLS-IP PSN, these defects can be detected by
             running a MPLS specific connectivity verification
             mechanism such as LSP-Ping [LSP-Ping], BFD on a LSP [LSP-
             BFD] or Y.1711 CV [Y.1711]. This can also be the result of
             receiving a Y.1711 FDI/BDI in a MPLS tunnel. Finally, this
             can be the result of a PE receiving a RSVP-TE PathErr
             message.
  
     (iii)  It receives a message from the remote PE indicating a PW
             defect. In the case of a MPLS PSN and a MPLS-IP PSN, this
             is a PW status message [PWE3-CONTROL] indicating a "PW
             Receive Fault", a "PW Transmit Fault", or a "PW not
             forwarding".
  
             In the case of an L2TP-IP, this is a L2TP StopCCN or CDN
             message. A StopCCN message indicates that the control
             connection has been shut down by the remote PE [L2TPv3].
             On reception of this message, a PE closes the control
             connection and will clear all the sessions managed by this
             control connection. Since each session carries a single
             PW, the state of the corresponding PWs is changed to DOWN.
             A CDN message indicates that the remote peer requests the
             disconnection of a specific session [L2TPv3]. In this case
             only the state of the corresponding PW is changed to DOWN.
  
  Aissaoui, et al.         Expires January 2005                 [Page 6]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt      July 2004
  
  
  
     (iv)   It detects a loss of PW connectivity, including label
             errors, via an inband PW OAM connectivity verification,
             such as VCCV. [VCCV]describes how LSP-Ping and BFD can be
             used over individual PWs for connectivity verification and
             continuity checking respectively. It also specifies a
             return path for notifying the remote PE of the PW defect.
  
     Note that a PW is a bidirectional entity. A defect in one of the
     directions is treated as a defect in the entire PW.
  
  
   4.3.2 PW UP
     For PWE3 over a MPLS PSN and a MPLS-IP PSN, a PE exits the PW DOWN
     state when the following conditions are true:
  
     (i)    All defects it had previously detected, as described in
             Section 4.3.1, have disappeared, and
     (ii)   It has received a PW Status message from its peer
             indicating "PW Forwarding".
  
     For a PWE3 over a L2TP-IP, a PE exits the PW DOWN state when the
     following conditions are true:
  
     (i)    All defects it had previously detected, as described in
             Section 4.3.1, have disappeared, and
     (ii)   A L2TPv3 session is successfully established to carry the
             PW packets.
  
  
   4.4 ATM AC State
  
     A PE changes the state of an ATM AC to DOWN if any of the
     following conditions are met:
  
     (i)    It detects a physical layer alarm on the ATM interface.
     (ii)   It receives an F4/F5 AIS/RDI OAM cell indicating that the
             ATM VP/VC is down in the adjacent L2 ATM network (e.g., N1
             for PE1).
     (iii)  It detects loss of connectivity on the ATM VPC/VCC while
             running ATM continuity checking (ATM CC) with the local
             ATM network and CE.
  
     A PE exits the ATM AC Down state when all defects it had
     previously detected have disappeared. The exact conditions under
     which a PE exits a AIS or a RDI state, or declares that
     connectivity is restored via ATM CC are explained in I.610
     [I.610].
  
     Note that for a FR-ATM interworking VPWS, FRF.8.2 specifies
     interworking for ATM VCCs only [FRF.8.2]. Therefore only F5 OAM
     messages are relevant.
  
  
  
  Aissaoui, et al.         Expires January 2005                 [Page 7]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt      July 2004
  
   4.5 FR AC State
  
     A PE changes the state of an FR AC to DOWN if any of the following
     conditions are met:
  
     (i)    A PVC is not ædeletedÆ from the Frame Relay network and
             the Frame Relay network explicitly indicates in a full
             status report (and optionally by the asynchronous status
             message) that this Frame Relay PVC is æinactiveÆ. In this
             case, this status maps across the PE to the corresponding
             PW only.
     (ii)   The LIV indicates that the link from the PE to the Frame
             Relay network is down. In this case, the link down
             indication maps across the PE to all corresponding PWs.
     (iii)  A physical layer alarm is detected on the FR interface. In
             this case, this status maps across the PE to all
             corresponding PWs.
     A PE exits the FR AC Down state when all defects it had previously
     detected have disappeared.
  
  
   4.6 Ethernet AC State
  
     A PE changes the state of an Ethernet AC to DOWN if any of the
     following conditions are met:
  
     (i)    A physical layer alarm is detected on the Ethernet
             interface.
  
     A PE exits the Ethernet AC Down state when all defects it had
     previously detected have disappeared.
  
  
   5 OAM Procedures for FR-ATM Interworking VPWS
  
     The FR-ATM interworking VPWS consists of interworking FR and ATM
     ACs over the PSN, and therefore a heterogeneous OAM model applies.
     Frame relay networks make use of PVC management over a FR UNI.
     This is based on Q.933 Annex A [Q.933AnnexA]. ATM provides a
     complete set of OAM capabilities which include defect indication
     (AIS/RDI), continuity checking (CC), loopback verification (LB),
     and performance monitoring [I.610].
  
     For clarity of the text, it is assumed that the ACs attached to
     PE1 in Figure Figure 1 are of FR type. Similarly, it is assumed
     that the ACs attached to PE2 are of ATM type. The PW type is ATM
     if the FRF.8.1 [FRF.8.1] interworking function resides in PE1. The
     PW type is FR if it resides in PE2.
  
  
   5.1 FR Network and Attachment Circuit Defects
  
  
  
  
  
  Aissaoui, et al.         Expires January 2005                 [Page 8]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt      July 2004
  
  
  
  
   5.1.1 FR PW and ATM PW with AAL5-mode encapsulation
  
     For a MPLS PSN and a MPLS-IP PSN, the following procedures MUST be
     followed when PE1 detects a defect in locations (a) or (b) as a
     result of any of the conditions described in Section 4.5:
  
          a. PE1 MUST change the state of the corresponding FR ACs to
             DOWN.
          b. PE1 MUST send a PW Status message indicating both "AC
             Receive Fault" and "AC Transmit Fault".
          c. On reception of the PW status message, PE2 MUST generate a
             F5 AIS on the related ATM ACs towards CE2.
          d. The termination point of the ATM VCC or VPC in the far-
             end, i.e., CE2, generates a F5 RDI in response to the
             received F5 AIS. PE2 MUST terminate the F5 RDI since it is
             sourcing a AIS over the same AC towards CE2.
  
     For an L2TP-IP, the following procedures MUST be performed when
     PE1 detects a defect in locations (a) or (b) as a result of any of
     the conditions described in Section 4.5:
  
          a. PE1 MUST change the state of the corresponding FR ACs to
             DOWN.
          b. PE1 MUST send an L2TP Set-Link Info (LSI) message with a
             Circuit Status AVP indicating "inactive".
          c. On reception of the L2TP LSI message, PE2 MUST generate a
             F5 AIS on the related ATM ACs towards CE2.
          d. The termination point of the ATM VCC or VPC in the far-end
             CE, i.e., CE2, generates a F5 RDI in response to the
             received F5 AIS. PE2 MUST terminate the F5 RDI since it is
             sourcing a AIS over the same AC towards CE2.
  
  
   5.1.2 ATM PW with cell-mode encapsulation
  
     If the PW type is ATM cell (N:1 or 1:1), the following procedures
     MUST be performed:
  
          a. PE1 MUST change the state of the corresponding FR ACs to
             DOWN.
          b. PE1 MUST generate an F5 AIS message and send it over the
             PW to PE2.
          c. PE2 MUST forward the received F5 AIS message over the ATM
             AC.
          d. The termination point of the ATM VCC in the far-end CE,
             i.e., CE2, generates a F5 RDI in response to the F5 AIS.
             PE2 MUST forward the RDI over the PW.
          e. PE1 MUST terminate and MUST not reply to the received F5
             RDI message.
  
  
  
  
  Aissaoui, et al.         Expires January 2005                 [Page 9]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt      July 2004
  
   5.2 ATM Network and Attachment Circuit Defects
  
  
   5.2.1 FR PW and ATM PW with AAL5-mode encapsulation
  
     For a MPLS PSN and a MPLS-IP PSN, the following procedures MUST be
     followed when PE2 detects a defect in locations (e) or (f) as a
     result of any of the conditions described in Section 4.4:
  
          a. PE2 MUST change the state of the corresponding ATM ACs to
             DOWN.
          b. PE2 MUST send a PW Status message indicating "AC Receive
             Fault" for a received F5 AIS.
          c. PE2 MUST send a PW status message indicating "AC Transmit
             Fault" for a received F5 RDI only if it is not sourcing a
             F5 AIS over the same AC towards CE2.
          d. PE2 MUST generate a F5 RDI on the related ACs towards CE2
             in response to a received F5 AIS only.
          e. On reception of the PW status message, PE1 MUST generate a
             full status report with the Active bit = 0 (and optionally
             in the asynchronous status message), as per Q.933 annex A,
             into N1 for the corresponding FR ACs.
  
     For an L2TP-IP, the following procedures MUST be performed when
     PE2 detects a defect in locations (a) or (b) as a result of any of
     the conditions described in Section 4.4:
  
          a. PE2 MUST change the state of the corresponding ATM ACs to
             DOWN.
          b. PE1 MUST send an L2TP Set-Link Info (LSI) message with a
             Circuit Status AVP indicating "inactive".
          c. PE2 MUST generate a F5 RDI on the related ACs towards CE2
             in response to a received F5 AIS only.
          d. On reception of the L2TP LSI message, PE1 MUST generate a
             full status report with the Active bit = 0 (and optionally
             in the asynchronous status message), as per Q.933 annex A,
             into N1 for the corresponding FR ACs.
  
  
   5.2.2 ATM PW with cell-mode encapsulation
  
     If the PW type is ATM cell (N:1 or 1:1), the following procedures
     MUST be performed:
  
          a. PE2 MUST transparently carry the F5 AIS or RDI cells
             received on the corresponding ATM AC (defect e) or the F5
             AIS generated locally (defect f) over the corresponding
             ATM PW.
          b. On reception of the F5 AIS or RDI message, PE1 MUST
             generate a full status report with the Active bit = 0 (and
             optionally in the asynchronous status message), as per
             Q.933 annex A, into N1 for the corresponding FR ACs.
  
  
  
  
  Aissaoui, et al.         Expires January 2005                [Page 10]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt      July 2004
  
          c. PE1 MUST terminate a received F5 RDI message. PE1 MUST
             generate a F5 RDI in response to a F5 AIS only and MUST
             forward it over the PW.
          d. On its reception, PE2 MUST forward the F5 RDI message on
             the corresponding AC. CE2 does not reply to a received F5
             RDI message.
  
  
   5.3 PW Defects
  
  
   5.3.1 FR PW and ATM PW with AAL5-mode encapsulation
     For PWE3 over MPLS AND MPLS-IP, the following operations MUST be
     performed when PE1 detects a defect in locations (c) or (d) as a
     result of any of the conditions described in Section 4.3.1:
  
          a. PE1 MUST change the state of the affected PWs to DOWN.
          b. PE1 MUST generate a full status report with the Active bit
             = 0 (and optionally in the asynchronous status message),
             as per Q.933 annex A, into N1 for the corresponding FR
             ACs.
          c. If both directions of the PW are down, PE1 MUST generate a
             PW status message indicating ôPW not forwardingö.
          d. If only the Receive direction of the PW is down, PE1 MUST
             generate a PW status message indicating ôLocal PSN-facing
             PW (ingress) Receive Faultö.
          e. On reception of the PW status message, PE2 MUST generate a
             F5 AIS on the affected ACs to convey this status to the
             ATM network (N2) and CE2.
          f. CE2 replies with a F5 RDI. PE2 MUST terminate the F5 RDI
             since it is sourcing a AIS over the same AC towards CE2.
  
     For PWE3 over L2TP-IP, the following operations MUST be performed
     when PE1 detects a defect in locations (c) or (d) as a result of
     any of the conditions described in Section 4.3.1:
  
          a. PE1 MUST change the state of the affected PWs to DOWN.
          b. PE1 MUST generate a full status report with the Active bit
             = 0 (and optionally in the asynchronous status message),
             as per Q.933 annex A, into N1 for the corresponding FR
             ACs.
          c. If both directions of the PW are down, or if only the
             Receive direction of the PW is down, PE1 MUST send an
             L2TPv3 CDN message or a StopCCN message.
          d. On reception of the CDN or StopCCN message, PE2 MUST
             generate a F5 AIS on the affected ACs to convey this
             status to the ATM network (N2) and CE2.
          e. CE2 replies with a F5 RDI. PE2 MUST terminate the F5 RDI
             since it is sourcing a AIS over the same AC towards CE2.
  
     If only the PW Transmit direction is DOWN at PE1, this is
     generally detected by PE2 through a PSN or a PW continuity
     checking or connectivity verification mechanism as explained in
     Section 4.3.1. PE1 is notified through the return path of that
  
  Aissaoui, et al.         Expires January 2005                [Page 11]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt      July 2004
  
     specific mechanism. In this case, PE2 will follow the procedures
     described below for a defect in the PW detected a PE2.
  
     When the PW state changes back to UP, a PE MUST cease the
     generation of the F5 messages on the ATM AC towards the CE.
     It MUST also generate a full status report (and optionally in the
     asynchronous status message), indicating a ôactiveö status for the
     corresponding FR AC.
     In addition, it MUST generate a PW Status message indicating
     ôPseudo Wire forwarding (clear all failures)ö for PWE3 over a MPLS
     PSN and a MPLS-IP PSN. For PWE3 or an L2TP-IP, the PE actions are
     TBD.
     This will result in clearing the alarm states in the remote PE, in
     CE1, and in CE2.
  
     The above procedures also apply if PE2 detects a defect in
     locations (c) or (d) as a result of any of the conditions
     described in Section 4.3.1. PE2 performs the same actions on the
     PW side as PE1 in the text above but will use the ATM AC
     procedures on the AC side instead.
  
  
   5.3.2 ATM PW with cell-mode encapsulation
  
     The following operations MUST be performed when PE1 detects a
     defect in locations (c) or (d) as a result of any of the
     conditions described in Section 4.3.1:
  
     a. PE 1 MUST change the state of the affected PWs to DOWN.
     b. If both directions of the PW are down or if only the Receive
        direction of the PW is down, PE1 MUST generate a full status
        report with the Active bit = 0 (and optionally in the
        asynchronous status message), as per Q.933 annex A, into N1 for
        the corresponding FR ACs.
     c. PE1 MUST generate a F5 RDI and forward it over the PW.
     d. PE2 will receive the F5 RDI message only if the forward
        direction of the PW, i.e., PE1-to-PE2, is not affected by the
        defect. In this case, PE2 MUST forward the RDI message to CE2
        through the ATM network (N2). CE2 terminates the F5 RDI
        message.
  
     If only the PW Transmit direction is DOWN at PE1, this is
     generally detected by PE2 through a PSN or a PW continuity
     checking or connectivity verification mechanism as explained in
     Section 4.3.1. PE1 is notified through the return path of that
     specific mechanism. In this case, PE2 will follow the procedures
     described below for a defect in the PW detected a PE2.
  
     When the PW state changes back to UP, PE1 MUST cease the
     generation of the F5 RDI messages on the AC towards CE1. It MUST
     also generate a full status report (and optionally in the
     asynchronous status message), indicating a ôactiveö status for the
  
  
  
  Aissaoui, et al.         Expires January 2005                [Page 12]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt      July 2004
  
     corresponding FR AC. This will result in clearing the alarm states
     in PE1, in CE1, and in CE2.
  
     The following procedures MUST be performed when PE2 detects a
     defect in locations (c) or (d) as a result of any of the
     conditions described in Section 4.3.1:
  
     a. PE2 MUST change the state of the affected PWs to DOWN.
     b. If both directions of the PW are down or if only the Receive
        direction of the PW is down, PE2 MUST generate a F5 AIS on the
        affected ACs to convey this status to the ATM network (N2) and
        CE2. CE2 will reply with a F5 RDI messages towards PE2.
     c. On reception of the F5 AIS message, PE1 MUST carry it over the
        PW towards PE1.
     d. PE1 will receive the F5 RDI message only if the forwards
        direction of the PW, i.e., PE2-to-PE1, is not affected by the
        defect. In this case, PE1 MUST generate a full status report
        with the Active bit = 0 (and optionally in the asynchronous
        status message), as per Q.933 annex A, into N1 for the
        corresponding FR ACs.
  
     When the PW state changes back to UP, PE2 MUST cease the
     generation of the F5 AIS messages over the AC towards CE2. This
     will result in clearing the alarm state at CE2 and PE1. PE1 MUST
     then generate a full status report (and optionally in the
     asynchronous status message), indicating a ôactiveö status for the
     corresponding FR AC. This will result in clearing the alarm state
     in CE1.
  
   6 OAM Procedures for Ethernet Interworking VPWS
  
     The Ethernet interworking VPWS consists of interworking FR, ATM,
     and Ethernet ACs over the PSN when the PW is of Ethernet type only
     [L2VPN-IW].
  
  
   6.1 FR Network and Attachment Circuit Defects
     The procedures are the same as those described in Section 5.1.1
     when the remote AC is ATM. When the remote AC is Ethernet, the
     same procedures apply with the exception that this document does
     not specify procedures the remote PE performs on the Ethernet AC
     once it is notified of the defect.
  
  
   6.2 ATM Network and Attachment Circuit Defects
     The procedures are the same as those described in Section 5.2.1
     when the remote AC is FR. When the remote AC is Ethernet, the same
     procedures apply with the exception that this document does not
     specify procedures the remote PE performs on the Ethernet AC once
     it is notified of the defect.
  
  
  
  
  
  
  Aissaoui, et al.         Expires January 2005                [Page 13]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt      July 2004
  
   6.3 Ethernet Network and Attachment Circuit Defects
     The following procedures MUST be followed when PE2 detects a
     defect in locations (a), (b), (c), or (d), as a result of any of
     the conditions described in Section 4.6:
  
     a. PE1 MUST change the state of the corresponding Ethernet ACs to
        DOWN.
     b. PE1 MUST notify PE2 of the defect using the same PW procedures
        described in Section 5.1.1 for a MPLS PSN, a MPLS-IP PSN, and
        L2TP-IP PSN.
     c. PE2 MUST follow the procedures in Section 5.1.1 for a remote
        ATM AC or the procedures in Section 5.2.1 for a remote FR AC.
  
  
   6.4 PW Defects
     When a PE detects a defect in location (c) or (d) as a result of
     any of the conditions described in Section 4.3.1, it MUST follow
     the procedures described in Section 5.3.1 for the PW, the ATM AC,
     and the FR AC. Note that this document does not specify procedures
     a PE performs on a Ethernet AC once it detects or is notified of
     the defect in the PW.
  
  
   7 OAM Procedures for IP Interworking VPWS
  
     The IP interworking VPWS consists of interworking FR, ATM, and
     Ethernet ACs over the PSN when the PW is of IP type only [ARP-
     MEDIATION].
  
     The OAM procedures for this VPWS type are the same as those for
     the Ethernet Interworking VPWS. See Section 6 for details.
  
   8 Security Considerations
  
     This draft does not introduce any new security considerations to
     VPWS. Though, it is worth mentioning that in the heterogeneous
     VPWS OAM model, a flooding of alarms on the ACs may result in a
     large number of PW status signaling messages generated. This may
     have an impact on the performance of the MPLS control plane. This
     issue should be investigated and solutions should be provided if
     required. A method for aggregating PW status messages is one
     possible solution.
  
   9 Intellectual Property Disclaimer
  
     This document is being submitted for use in IETF standards
     discussions.
  
   10 References
  
     [L2VPN-FRMK] Andersson, L. et. al., "L2VPN Framework", draft-ietf-
          l2vpn-l2-framework-05.txt, June 2004.
  
  
  Aissaoui, et al.         Expires January 2005                [Page 14]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt      July 2004
  
     [FRF8.2] Frame Relay Forum, ôFRF 8.2 - Frame Relay / ATM PVC
          Service Interworking Implementation Agreementö, February
          2004.
  
     [L2VPN-IW] Sajassi, A., et al., ôL2VPN Interworkingö, draft-
          sajassi-l2vpn-interworking-01.txt, March 2003.
  
     [ARP-MEDIATION] Shah, H., et al., ôARP Mediation for IP
          interworking of Layer 2 VPNö, draft-shah-l2vpn-arp-mediation-
          03.txt, October 2003.
  
     [I.610] ôB-ISDN operation and maintenance principles and
          functionsö, ITU-T Recommendation I.610, February 1999.
  
     [OAM-MSG] Nadeau, T., et al., ôPseudo Wire (PW) OAM Message
          Mappingö, draft-ietf-pwe3-oam-msg-map-00.txt, July 2004.
  
     [PWE3-ATM] Martini, L., et al., ôEncapsulation Methods for
          Transport of ATM Over IP and MPLS Networksö, draft-ietf-pwe3-
          atm-encap-05.txt, April 2004.
  
     [PWE3-CONTROL] Martini, L., et al., ôPseudowire Setup and
          Maintenance using LDPö, draft-ietf-pwe3-control-protocol-
          08.txt, July 2004.
  
     [PWE3-FR] Kawa, C., et al., ôFrame Relay over Pseudo-Wiresö,
          draft-ietf-pwe3-frame-relay-02.txt, February 2004.
  
     [Q933AnnexA] ITU-T, ôAdditional procedures for Permanent Virtual
          Connection (PVC) status managementö, ITU-T Q.933 Annex A,
          February 2003.
  
     [FRF.19] Frame Relay Forum, ôFrame Relay Operations,
          Administration, and Maintenance Implementation Agreementö,
          March 2001.
  
     [L2TPv3] Lau, J., et.al. " Layer Two Tunneling Protocol (Version
          3", Internet Draft <draft-ietf-l2tpext-l2tp-base-14.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-05.txt, February 2004.
  
     [Y.1711] ôOAM Mechanisms for MPLS Networksö, ITU-T Recommendation
          Y.1711, November 2002.
  
     [VCCV] Nadeau, T., et al., ôPseudo Wire (PW) Virtual Circuit
          Connection Verification (VCCV)ö, draft-ietf-pwe3-vccv-03.txt,
          June 2004.
  
  
  Aissaoui, et al.         Expires January 2005                [Page 15]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt      July 2004
  
     [PWE3-ETH] Martini, L., et al., ôEncapsulation Methods for
          Transport of Ethernet Frames Over IP/MPLS Networksö, draft-
          ietf-pwe3-ethernet-encap-06.txt, April 2004.
  
   11 Authors' Addresses
  
     Mustapha Aissaoui
     Alcatel
     600 March Rd
     Kanata, ON, Canada. K2K 2E6
     Email: mustapha.aissaoui@alcatel.com
  
     Matthew Bocci
     Alcatel
     Voyager Place, Shoppenhangers Rd
     Maidenhead, Berks, UK SL6 2PJ
     Email: matthew.bocci@alcatel.co.uk
  
     David Watkinson
     Alcatel
     600 March Rd
     Kanata, ON, Canada. K2K 2E6
     Email: david.watkinson@alcatel.com
  
     Hamid Ould-Brahim
     Nortel Networks
     P O Box 3511 Station C
     Ottawa ON K1Y 4H7 Canada
     Phone: +1 (613) 765 3418
     Email: hbrahim@nortelnetworks.com
  
     Mike Loomis
     Nortel Networks
     600 Technology Park Dr.
     Billerica, MA 01821
     Phone: +1-978-288-6322
     Email: mloomis@nortelnetworks.com
  
     Thomas D. Nadeau
     Cisco Systems, Inc.
     300 Beaverbrook Drive
     Boxborough, MA
     Phone: +1-978-936-1470
     Email: tnadeau@cisco.com
  
     Monique Morrow
     Cisco Systems, Inc.
     Glatt-com
     CH-8301 Glattzentrum
     Switzerland
     Email: mmorrow@cisco.com
  
     John Yu
  
  Aissaoui, et al.         Expires January 2005                [Page 16]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-01.txt      July 2004
  
     Hammerhead Systems, Inc.
     640 Clyde Court
     Mountain View, CA 94043 USA
     Phone: +1 650 210 3312
     Email: john@hammerheadsystems.com
  
     Himanshu Shah
     Ciena Networks
     35 Nagog Park,
     Acton, MA 01720
     Email: hshah@ciena.com
  
     Paul Doolan
     Mangrove Systems
     10 Fairfield Blvd.,
     Wallingford, CT 06492
     Email: pdoolan@mangrovesystems.com
  
     Peter B. Busschbach
     Lucent Technologies
     67 Whippany Road
     Whippany, NJ, 07981
     Email: busschbach@lucent.com
  
   12 Full Copyright Statement
  
     "Copyright (C) The Internet Society (2004). Except as set forth
     below, authors retain all their rights.
  
     This document and translations of it may be copied and furnished
     to others, and derivative works that comment on or otherwise
     explain it or assist in its implementation may be prepared,
     copied, published and distributed, in whole or in part, without
     restriction of any kind, provided that the above copyright notice
     and this paragraph are included on all such copies and derivative
     works.  However, this document itself may not be modified in any
     way, such as by removing the copyright notice or references to the
     Internet Society or other Internet organizations, except as needed
     for the purpose of developing Internet standards in which case the
     procedures for rights in submissions defined in the IETF Standards
     Process must be followed, or as required to translate it into
     languages other than English.
  
     The limited permissions granted above are perpetual and will not
     be revoked by the Internet Society or its successors or assigns.
  
     This document and the information contained herein is provided on
     an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
     REPRESENTS (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
     ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
     IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
     THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  
  Aissaoui, et al.         Expires January 2005                [Page 17]
  

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