Internet DRAFT - draft-aissaoui-l2vpn-vpws-iw-oam

draft-aissaoui-l2vpn-vpws-iw-oam



   
   
      L2VPN Working Group                                Mustapha Aissaoui 
      Internet Draft                                         Matthew Bocci 
      Expiration Date: March 2006                          David Watkinson 
                                                                   Alcatel 
      Hamid Ould-Brahim                                                    
      Mike Loomis                                            Himanshu Shah 
      David Allan                                                    Ciena 
      Nortel                                                               
                                                               Paul Doolan 
      Thomas D. Nadeau                                    Mangrove Systems 
      Monique Morrow                                                       
      Cisco Systems                                       Peter Busschbach 
                                                       Lucent Technologies 
      John Z. Yu                                                           
      Hammerhead Systems                                      Simon Delord 
                                                            France Telecom 
      Vasile Radoaca                                                       
      West Ridge Networks                                   September 2005 
   
      
                    OAM Procedures for VPWS Interworking 
                   draft-aissaoui-l2vpn-vpws-iw-oam-04.txt 
      
      
      
   Status of this Memo 
      
     By submitting this Internet-Draft, each author represents that any 
     applicable patent or other IPR claims of which he or she is aware 
     have been or will be disclosed, and any of which he or she becomes 
     aware will be disclosed, in accordance with Section 6 of BCP 79.  
     This document may 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 March 2006                  [Page 1]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 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 Status Notifications....................................9 
      4.5 L2TPv3 Control Connection Messages.........................9 
      4.6 BFD Fault Detection and Notification......................10 
     5 PW Entry/Exit Criteria.......................................11 
         5.1.1 PW Forward Defect Entry..............................11 
         5.1.2 PW Reverse Defect Entry..............................12 
         5.1.3 PW reverse defects that require PE state synchronization
          ...........................................................12 
         5.1.4 PW Forward Defect Exit...............................13 
         5.1.5 PW Reverse Defect Exit...............................13 
     6 AC Defect Entry/Exit Criteria................................13 
      6.1 ATM AC Defect Entry/Exit Criteria.........................13 
         6.1.1 Forward Defect Entry.................................13 
         6.1.2 Forward Defect Exit..................................14 
         6.1.3 Reverse Defect Entry.................................14 
         6.1.4 Reverse Defect Exit..................................14 
      6.2 FR AC Defect Entry/Exit...................................14 
         6.2.1 Forward Defect Entry Criteria........................14 
         6.2.2 Forward Defect Exit Criteria.........................14 
      6.3 Ethernet AC Defect Entry/Exit Criteria....................15 
         6.3.1 Forward Defect State Entry...........................15 
         6.3.2 Forward Defect State Exit............................15 
     7 AC Defect Entry/Exit Procedures..............................15 
      7.1 AC Forward defect entry:..................................15 
         7.1.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs......15 
         7.1.2 Procedures for ATM cell PWs..........................15 
         7.1.3 Additional procedures for ATM ACs....................15 
      7.2 AC Reverse defect entry...................................16 
         7.2.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs......16 

    
  Aissaoui, et al.          Expires March 2006                  [Page 2]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
         7.2.2 Procedures for ATM cell PWs..........................16 
      7.3 AC Forward Defect Exit....................................16 
         7.3.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs......16 
         7.3.2 Procedures for ATM cell PWs..........................16 
         7.3.3 Additional procedures for ATM ACs....................17 
      7.4 AC Reverse Defect Exit....................................17 
         7.4.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs......17 
         7.4.2 Procedures for ATM cell PWs..........................17 
     8 PW Forward Defect Entry/Exit procedures......................17 
      8.1 PW Forward Defect Entry Procedures........................17 
         8.1.1 FR AC procedures.....................................17 
         8.1.2 Ethernet AC Procedures...............................18 
         8.1.3 ATM AC procedures....................................18 
         8.1.4 Additional procedures for FR, ATM AAL5, IP or Ethernet 
         PWs........................................................18 
         8.1.5 Additional procedures for ATM Cell PWs...............18 
      8.2 PW Forward Defect Exit Procedures.........................19 
         8.2.1 FR AC procedures.....................................19 
         8.2.2 Ethernet AC Procedures...............................19 
         8.2.3 ATM AC procedures....................................19 
         8.2.4 Additional procedures for FR, ATM AAL5, IP or Ethernet 
         PWs........................................................19 
         8.2.5 Additional procedures for ATM Cell PWs...............19 
      8.3 PW Reverse Defect Entry Procedures........................19 
         8.3.1 FR AC procedures.....................................19 
         8.3.2 Ethernet AC Procedures...............................20 
         8.3.3 ATM AC procedures....................................20 
      8.4 PW Reverse Defect Exit Procedures.........................20 
         8.4.1 FR AC procedures.....................................20 
         8.4.2 Ethernet AC Procedures...............................20 
         8.4.3 ATM AC procedures....................................20 
     9 Security Considerations......................................20 
     10 Intellectual Property Disclaimer............................20 
     11 References..................................................21 
     12 Authors' Addresses..........................................22 
     13 Full Copyright Statement....................................24 
      
      
   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 
    
  Aissaoui, et al.          Expires March 2006                  [Page 3]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
     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 
     [MPLS-in-IP], with a MPLS shim header used as PW demultiplexer, 
     will be referred to as MPLS-IP PSN. A PSN, which makes use of 
     L2TPv3 [L2TPv3] as the tunneling technology, will be referred to 
     as L2TP-IP PSN. 
      
     A PE interworks or adapts an AC onto a PW (depending on whether it 
     terminates the attachment circuit or the AC corresponds to the NS 
     for the PW). The other PE that terminates the PW is the "peer" PE 
     and the attachment circuit associated with the far end PW 
     termination is the "remote AC".  
      
     Defects are discussed in the context of defect states, and the 
     criteria to enter and exit the defect state. 
      
     The direction of defects is discussed from the perspective of the 
     observing PE and what the PE may explicitly know about information 
     transfer capabilities of the VPWS service. 
      
     A forward defect is one that impacts information transfer to the 
     observing PE. It impacts the observing PEÆs ability to receive 
     information. A forward defect MAY also imply impact on information 
     sent or relayed by the observer (and as it cannot receive is 
     therefore unknowable) and so the forward defect state is 
     considered to be a superset of the two defect states. 
      
     A reverse defect is one that uniquely impacts information sent or 
     relayed by observer.  
      
     At the present time code points for forward defect and reverse 
     defect notifications have not been specified for BFD and LDP PW 
     Status signaling. These are referred to as "forward defect" and 
     "reverse defect" indications as placeholders for code point 
     assignment. A crude mapping may be performed between current code 
     points in [PWE3-IANA]: 
      
          Forward defect - corresponds to the logical OR of 
                  Local Attachment Circuit (ingress) Receive Fault 
                                  AND 
                  Local PSN-facing PW (egress) Transmit Fault 
    
  Aissaoui, et al.          Expires March 2006                  [Page 4]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
      
          Reverse defect - corresponds to the logical OR of 
                  Local Attachment Circuit (egress) Transmit Fault 
                                  AND  
                  Local PSN-facing PW (egress) Transmit Fault 
       
   3 Introduction 
      
     This draft augments OAM message mapping [OAM-MSG] with OAM 
     procedures for scenarios when the attachment circuit does not 
     correspond to the pseudo wire. When combined with procedures 
     defined in [OAM-MSG], comprehensive OAM interworking can be 
     defined for VPWS services. VPWS services are defined in the L2 VPN 
     framework [L2VPN-FRMK]. 
      
     The following VPWS types are covered in this document: 
      
     1. VPWS with heterogeneous ACs of ATM and FR types, and in which 
        the PW type is ATM or FR. In this case, FR-ATM service 
        interworking [FRF8.2] is performed in PE1 (or PE2) and a FR (or 
        ATM) PW is extended to the remote PE. This VPWS type will be 
        referred to as "FR-ATM Interworking VPWS". 
   
     2. VPWS with heterogeneous ACs of ATM, FR, and Ethernet types, and 
        in which the PW type is Ethernet. This VPWS type will be 
        referred to as "Ethernet Interworking VPWS". 
   
     3. VPWS with heterogeneous ACs of ATM, FR, and Ethernet types, and 
        in which the PW type is IP [ARP-Mediation]. This VPWS type will 
        be referred to as "IP Interworking VPWS". 
      
     OAM procedures for homogeneous VPWS circuits of ATM, FR, or 
     Ethernet types are described in [OAM-MSG]. 
   
   4 General OAM Procedures 

   4.1 Defect Locations 
      
     Figure 1 illustrates a VPWS network model with an indication of 
     the possible defect locations. This model will be referenced in 
     the remainder of this document for describing the OAM procedures.               
                                            
                    ACs           PSN tunnel           ACs 
                        +----+                  +----+ 
        +----+          | PE1|==================| PE2|          +----+ 
        |    |---(a)---(b)  (c)......PW1...(d).(c)..(f)--(e)----|    |               
        | CE1|   (N1)   |    |                  |    |   (N2)   |CE2 | 
        |    |----------|............PW2.............|----------|    | 
        +----+          |    |==================|    |          +----+ 
             ^          +----+                  +----+          ^ 
             |      Provider Edge 1         Provider Edge 2     | 
             |                                                  | 
    
  Aissaoui, et al.          Expires March 2006                  [Page 5]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
             |<-------------- Emulated Service ---------------->| 
       Customer                                                Customer 
        Edge 1                                                  Edge 2 
      
                     Figure 1: VPWS Defect Locations 
      
     In all interworking scenarios described in this document, it is 
     assumed that at PE1 the AC does not correspond to the PW. The 
     procedures described in this document exclusively apply to PE1.  
     PE2 either implements the procedures described in this document or 
     those in [OAM-MSG]. The notifications received from PE2 and 
     consequent actions taken at PE1 will be common to both scenarios. 
      
     The following is a brief description of the defect locations: 
      
     (a)  Defect in the first L2 network (N1). This covers any defect 
          in the N1 which impacts all or a subset of ACs terminating in 
          PE1. The defect is conveyed to PE1 and to the remote L2 
          network (N2) using a L2 specific OAM defect indication.  
     (b)  Defect on a PE1 AC interface. 
     (c)  Defect on a PE PSN interface. 
     (d)  Defect in the PSN network. This covers any defect in the PSN 
          which impacts all or a subset of the PSN tunnels and PWs 
          terminating in a PE. The defect is conveyed to the PE using a 
          PSN and/or a PW specific OAM defect indication. 
     (e)  Defect in the second L2 network (N2). This covers any defect 
          in N2 which impacts all or a subset of ACs terminating in PE2 
          (which is considered a "remote AC defect" in the context of 
          procedures outlined in this draft). The defect is conveyed to 
          PE2 and to the remote L2 network (N1) using a L2 specific OAM 
          defect indication.  
     (f)  Defect on a PE2 AC interface (which is also considered a 
          "remote AC defect" in the context of this draft). 

   4.2 Abstract Defect States 
     PE1 is obliged to track four abstract defect states that reflect 
     the observed state of both directions of the VPWS service on both 
     the AC and the PW sides. Faults may impact only one or both 
     directions of the PW.  
      
     The observed state is a combination of faults directly detected by 
     PE1, or faults it has been made aware of via notifications. 
      
                                +-----+ 
             ----AC forward---->|     |-----PW reverse----> 
       CE1                      | PE1 |                       PE2/CE2 
             <---AC reverse-----|     |<----PW forward----- 
                                +-----+  
      
       (arrows indicate direction of user traffic impacted by a defect) 

    
  Aissaoui, et al.          Expires March 2006                  [Page 6]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
               Figure 2: Forward and Reverse Defect States 
     PE1 will directly detect or be notified of AC forward and PW 
     forward defects as they occur upstream of PE1 and impact traffic 
     being sent to PE1.  
     In Error! Reference source not found., PE1 may be notified of a 
     forward defect in the AC by receiving a Forward Defect indication, 
     e.g., ATM AIS, from CE1. This defect impacts the ability of PE1 to 
     receive user traffic from CE1 on the AC. PE1 can also directly 
     detect this defect if it resulted from a failure of the receive 
     side in the local port or link over which the AC is configured.  
     Similarly, PE1 may detect or be notified of a forward defect in 
     the PW by receiving a Forward Defect indication from PE2. This 
     notification can either be a "Local PSN-facing PW (egress) 
     Transmit Fault" or a "Local Attachment Circuit (ingress) Receive 
     Fault". This defect impacts the ability of PE1 to receive user 
     traffic from CE2.  
     Note that the AC or PW Forward Defect notification is sent in the 
     same direction as the user traffic impacted by the defect. 
      
     PE1 will only be notified of AC reverse and PW reverse defects as 
     they universally will be detected by other devices and only impact 
     traffic that has already been relayed by PE1. In Error! Reference 
     source not found., PE1 may be notified of a reverse defect in the 
     AC by receiving a Reverse Defect indication, e.g., ATM RDI, from 
     CE1. This defect impacts the ability of PE1 to send user traffic 
     to CE1 on the AC. Similarly, PE1 may be notified of a reverse 
     defect in the PW by receiving a Reverse Defect indication from 
     PE2. This notification can either be a "Local PSN-facing PW 
     (ingress) Receive Fault" or a "Local Attachment Circuit (egress) 
     Transmit Fault". This defect impacts the ability of PE1 to send 
     user traffic to CE2. 
     Note that the AC or PW Reverse Defect notification is sent in the 
     reverse direction to the user traffic impacted by the defect. 
      
     The procedures outlined in this document define the entry and exit 
     criteria for each of the four states with respect to the set of 
     potential ACs and PWs within the document scope and the consequent 
     actions that PE1 must perform to properly interwork those 
     notifications. The abstract defect states used by PE1 are common 
     to all potential interworking combinations of PWs and ACs. 

   4.3 VPWS OAM Interworking Models 
      
     There are two different OAM interworking models which are dictated 
     by the type of VPWS.  
      
     In a homogeneous VPWS circuit, the AC link layer is emulated by 
     the PW by extending it across the PSN. This has the implication 
     that the native service OAM has to operate transparently across 
     the PSN. In this case, the default OAM procedures are to use the 
     native service OAM for both the AC and PW defect indications. This 

    
  Aissaoui, et al.          Expires March 2006                  [Page 7]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
     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 notification [PWE3-CONTROL]. If the PEs 
     have negotiated the use of VCCV-BFD for PW fault detection and 
     AC/PW fault notifications as explained in [VCCV] then BFD is the 
     preferred mechanism. The interaction of BFD and PW status is 
     explained in more details in Section 4.5. 
      
     For a IP PSN using L2TPv3, i.e., a L2TP-IP PSN, StopCCN and CDN 
     messages are used for conveying defects in the PSN and PW 
     respectively, while the Set-Link-Info (SLI) messages are used to 
     convey status and defects in the AC and local L2 network as 
     detailed in [OAM-MSG].  
      
     Finally, it may be desirable to operate ATM OAM inband in the case 
     of the FR-ATM interworking VPWS. This document proposes to use the 
     homogeneous OAM circuit model together with an ATM cell mode PW to 
     achieve this. 
      
     Table 1 summarizes the OAM model used with each type of VPWS 
     covered in this document. 
     ------------------------------------------------------------------ 
     |VPWS Type              | Homogeneous Circuit | Heterogeneous    |              
     |                       | OAM Model           | Circuit OAM Model| 
     ------------------------------------------------------------------ 
     |FR-ATM Interworking    |                     |                  | 
     |- ATM cell mode PW     |          X          |                  | 
     ------------------------------------------------------------------ 
     |FR-ATM Interworking    |                     |                  | 
     |- FR or AAL5 PDU/SDU PW|                     |        X         | 
     ------------------------------------------------------------------              
     |Ethernet Interworking  |                     |        X         | 
     ------------------------------------------------------------------ 
     |IP Interworking        |                     |        X         | 
     ------------------------------------------------------------------ 

    
  Aissaoui, et al.          Expires March 2006                  [Page 8]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
                 Table 1: Summary of VPWS OAM Interworking 

   4.4 PW Status Notifications 
      
     PW status signaling is the default mechanism for conveying the 
     status of a PW and ACs between PEs in a MPLS PSN and a IP PSN 
     using MPLS-in-IP (MPLS-IP PSN). 
      
     [PWE3-IANA] defines the following valid PW status codepoints: 
     0x00000000 - Pseudo Wire forwarding (clear all failures) 
     0x00000001 - Pseudo Wire Not Forwarding 
     0x00000002 - Local Attachment Circuit (ingress) Receive Fault 
     0x00000004 - Local Attachment Circuit (egress) Transmit Fault 
     0x00000008 - Local PSN-facing PW (ingress) Receive Fault 
     0x00000010 - Local PSN-facing PW (egress) Transmit Fault 
      
     [PWE3-CONTROL] specifies that "Pseudo Wire forwarding" is used to 
     clear all faults and that "Pseudo Wire Not Forwarding" is used to 
     convey any other defects that cannot be represented by the other 
     codepoints. The remaining codepoints map to the "forward defect" 
     and "reverse defect" defined in this document as follows:
      
          Forward defect - corresponds to the logical OR of 
                  Local Attachment Circuit (ingress) Receive Fault 
                                  AND 
                  Local PSN-facing PW (egress) Transmit Fault 
      
          Reverse defect - corresponds to the logical OR of 
                  Local Attachment Circuit (egress) Transmit Fault 
                                  AND  
                  Local PSN-facing PW (ingress) Receive Fault 
      
     Note that there are a couple of situations which require PW label 
     withdrawal as opposed to a PW status notification by the PE. The 
     first one is when the PW is taken administratively down in 
     accordance to [PWE3-CONTROL]. The second one is when the Target 
     LDP session established between the two PEÆs is lost. In the 
     latter case, the PW labels will need to be re-signaled when the 
     Targeted LDP session is re-established. 

   4.5 L2TPv3 Control Connection Messages 
      
     For a L2TP-IP PSN, StopCCN and CDN messages are used for conveying 
     defects which impact one or many PWs controlled by a given control 
     connection.  
      
     A StopCCN message indicates that the control connection has been 
     shut down by the remote PE [L2TPv3]. This is typically used for 
     defects in the PSN which impact both the control connection and 
     the individual data plane sessions. On reception of this message, 
     a PE closes the control connection and will clear all the sessions 
    
  Aissaoui, et al.          Expires March 2006                  [Page 9]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
     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. 
      
     Finally, the Set-Link-Info (SLI) messages are used to convey 
     status and defects in the AC and local L2 network 

   4.6 BFD Fault Detection and Notification 
      
     BFD is a mechanism which can be used to detect defects in the PW 
     data path. This document specifies two uses of BFD. When used for 
     PW fault detection only, a PE will continue to use PW status to 
     report defects other than those detected by BFD. When used for 
     both PW fault detection and all PW/AC fault notifications, PW 
     status should not be used. This section describes the behavior of 
     the PE nodes in both use cases. 
      
     For a MPLS-PSN, the PEÆs negotiate the use of the VCCV 
     capabilities when the label mapping messages are exchanged to 
     establish the two directions of the PW. A new OAM capability TLV 
     is signaled as part of the PW FEC interface parameters TLV.  
      
     The CV Type Indicators field in this TLV defines a bitmask used to 
     indicate the specific OAM capabilities that the PE can make use of 
     over the PW being established. The defined values are: 
          0x01  ICMP Ping 
          0x02  LSP Ping (VCCV-Ping over a MPLS PSN and MPLS-IP PSN) 
          0x04  BFD for PW Fault Detection only 
          0x08  BFD for PW Fault Detection and AC/PW Fault Notification 
      
     A CV type of 0x04 is part of the VCCV-BFD capability. It indicates 
     that BFD is used for PW fault detection only. A BFD message will 
     notify the remote PE of the fault and the latter enters into the 
     proper PW defect state and triggers the appropriate actions as 
     explained in the subsequent sections. All other PW and AC defects 
     are indicated using PW status signaling. 
      
     A CV type of 0x08 is also part of the VCCV-BFD capability. It 
     indicates that BFD is used for both PW fault detection and AC/PW 
     Fault Notification, even if the fault was not detected via BFD. In 
     this case, PW status signaling messages should not be used. 
      
     Similarly, [VCCV] describes a L2TPv3 VCCV Capability AVP which 
     provides the equivalent means to signal OAM capabilities between 
     PEÆs for PWÆs over a L2TP-IP PSN.  
      
     [BFD] defined the following diagnostic codes:  
      
    
  Aissaoui, et al.          Expires March 2006                 [Page 10]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
     Code         Message   
     ----   ------------------------------ 
     0            No Diagnostic 
     1            Control Detection Time Expired 
     2            Echo Function Failed 
     3            Neighbor Signaled Session Down 
     4            Forwarding Plane Reset 
     5            Path Down (Alarm Suppression) 
     6            Concatenated Path Down 
     7            Administratively Down 
     8            Reverse Concatenated Path Down 
     9-31         Reserved for future use 
          
     [VCCV] states that, when used over PWs, the asynchronous mode of 
     BFD should be used. Of these, 0 is used when the PW is up and 2 is 
     not applicable to asynchronous mode. 3 is used as explained below. 
     6 and 8 are used to signal AC forward and reverse defect states 
     respectively when the PE's negotiated the use of BFD as the 
     mechanism for AC and PW fault detection and notification. 
          
     The following are the BFD procedures for PW fault detection (valid 
     for both CV types 0x04 and 0x08):  
          
     When the downstream PE (PE1) does not receive control messages 
     from the upstream PE (PE2) during a certain number of transmission 
     intervals (a number provisioned by the operator), it declares that 
     the PW in its receive direction is down. In other word, PE1 enters 
     the "forward defect" state for this PW. PE1 sends a message to PE2 
     with H=0 (i.e. "I do not hear you") and with diagnostic code 1. In 
     turn, PE2 declares the PW is down in its transmit direction and it 
     uses diagnostic code 3 in its control messages to PE1. PE2 enters 
     the "reverse defect" state for this PW.  
       
     When a PW is taken administratively down, the PEs will withdraw 
     the PW labels or will send L2TP CDN messages with code "Session 
     disconnected for administrative reasons". In addition, exchange of 
     BFD control messages MUST be suspended. To that end, the PEs MUST 
     send control messages with H=0 and diagnostic code 7 
      
   5 PW Entry/Exit Criteria 

   5.1.1 PW Forward Defect Entry 
      
     PE1 enters the forward defect state if any of the following 
     conditions are met: 
      
     (i)    It detects or is notified of a defect upstream of PE1 in 
             the PSN tunnel over which the PW is riding.  
   
             Defects detected explicitly include the loss of 
             connectivity, label swapping errors and label merging 
             errors. In the case of a MPLS PSN and a MPLS-IP PSN, these 
    
  Aissaoui, et al.          Expires March 2006                 [Page 11]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
             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". 
   
     (iii)  It detects a loss of PW connectivity, including label 
             errors, via an inband PW OAM connectivity verification, 
             such as VCCV. 
      
     Note that if the PW control session between the PEs fails, the PW 
     is torn down and needs to be re-established. However, the 
     consequent actions towards the ACs are the same as if the PW state 
     were DOWN.   

   5.1.2 PW Reverse Defect Entry 
     For PWE3 over a MPLS PSN and a MPLS-IP PSN, PE1 enters the PW 
     reverse defect state when the following conditions are true:  
          
     (i)    The status communicated by PE2 via BFD or LDP status TLV 
             indicates a reverse defect. This indicates PE2 detected or 
             was notified of a PW/PSN fault upstream of it or that 
             there was a remote AC fault and it is not already in the 
             PW forward defect state. 
          
     For a PWE3 over a L2TP-IP PSN, the PW reverse defect state is not 
     valid and a PE can only enter the PW forward defect state. 

   5.1.3 PW reverse defects that require PE state synchronization 
     Some PW mechanisms will result in PW defects being detected by or 
     notified to PE1 when PE1 is upstream of the fault but the 
     notification did not originate with PE2. The resultant actions are 
     identical to that of entering the PW reverse defect state with the 
     addition that PE1 needs to synchronize state with PE2 and the PW 
     state communicated from PE1 to PE2 needs to indicate state 
     accordingly. 
       
     When the PSN uses RSVP-TE or proactively uses LSP-PING as a PW 
     fault detection mechanism, PE1 must enter the AC forward defect. 
       


    
  Aissaoui, et al.          Expires March 2006                 [Page 12]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
     The exit criteria being when, the RSVP fault state or the LSP-PING 
     fault state exit criteria has been met, indicating no PW reverse 
     defects.   

   5.1.4 PW Forward Defect Exit 
     For PWE3 over a MPLS PSN and a MPLS-IP PSN, PE1 exits the PW 
     Forward state when the following conditions are true:  
          
     (ii)   The status communicated by PE2 via BFD or LDP status TLV 
             no longer indicates a forward defect AND 
     Local indications (BFD processing etc.) indicate that PW and PSN 
     connectivity is working in the forward direction. Note that this 
     may result in a transition to the PW working or PW reverse defect 
     states. 
          
     For a PWE3 over a L2TP-IP, a PE exits the PW DOWN state when the 
     following conditions are true: 
      
     (i)    All defects it had previously detected have disappeared, 
             and  
     (ii)   A L2TPv3 session is successfully established to carry the 
             PW packets. 

   5.1.5 PW Reverse Defect Exit 
     For PWE3 over a MPLS PSN and a MPLS-IP PSN, PE1 exits the PW 
     Reverse defect state when the following conditions are true:  
          
     (i)    The status communicated by PE2 via BFD or LDP status TLV 
             no longer indicates a reverse defect or, 
     (ii)   PE1 has entered the PW forward defect state. 
   
    
   6 AC Defect Entry/Exit Criteria  

   6.1 ATM AC Defect Entry/Exit Criteria 

   6.1.1 Forward Defect Entry 
     PE1 enters the AC forward defect state if any of the following 
     conditions are met: 
      
     (i)    It detects a physical layer alarm on the ATM interface. 
     (ii)   It receives an F5 AIS OAM cell indicating that the ATM 
             VP/VC is down in the adjacent L2 ATM network (e.g., N1 for 
             PE1). 
     (iii)  It detects loss of connectivity on the ATM VPC/VCC while 
             running ATM continuity checking (ATM CC) with the local 
             ATM network and CE. 
      
     Note that all interworking VPWS referred to in this document make 
     use of ATM VCCs as the AC. ATM VPC cannot be terminated directly 

    
  Aissaoui, et al.          Expires March 2006                 [Page 13]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
     on an interworking VPWS. Therefore only F5 OAM messages are 
     relevant. 

   6.1.2 Forward Defect Exit 
     PE1 exits the AC forward defect state when all defects it had 
     previously detected have disappeared. The exact conditions under 
     which a PE exits AIS or declares that connectivity is restored via 
     ATM CC are explained in I.610 [I.610]. Note that it is possible to 
     transition directly from the forward to the reverse defect states. 

   6.1.3 Reverse Defect Entry 
     PE1 enters the AC reverse defect state if: 
      
     (i)    It terminates the ATM layer and it receives an F5 RDI OAM 
             cell indicating that the ATM VP/VC is down in the adjacent 
             L2 ATM network (e.g., N1 for PE1). 

   6.1.4 Reverse Defect Exit 
     PE1 exits the AC reverse defect state if: 
      
        (i)    It enters the forward defect state OR 
      
        (ii)   All defects it had previously detected have 
                disappeared. The exact conditions under which a PE 
                exits the RDI state are explained in I.610 [I.610]. 

   6.2 FR AC Defect Entry/Exit 
     Note that the FR AC "inactive" state, as communicated by the FR 
     LMI, does not indicate direction but is assumed to be the 
     equivalent of a forward defect and is translated to same. The 
     reverse defect state is not valid for an FR AC. 

   6.2.1 Forward Defect Entry Criteria 
     PE1 enters the AC forward defect state if any of the following 
     conditions are met: 
      
     (i)    A PVC is not ædeletedÆ from the Frame Relay network and 
             the Frame Relay network explicitly indicates in a full 
             status report (and optionally by the asynchronous status 
             message) that this Frame Relay PVC is æinactiveÆ. In this 
             case, this status maps across the PE to the corresponding 
             PW only. 
     (ii)   The LIV indicates that the link from the PE to the Frame 
             Relay network is down. In this case, the link down 
             indication maps across the PE to all corresponding PWs. 
     (iii)  A physical layer alarm is detected on the FR interface. In 
             this case, this status maps across the PE to all 
             corresponding PWs. 



    
  Aissaoui, et al.          Expires March 2006                 [Page 14]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
   6.2.2 Forward Defect Exit Criteria 
     A PE exits the FR AC Down state when all defects it had previously 
     detected have disappeared. 

   6.3 Ethernet AC Defect Entry/Exit Criteria 
     Ethernet AC failures are translated directly into AC forward 
     defects. The reverse defect state is not valid for Ethernet ACs.  

   6.3.1 Forward Defect State Entry 
     PE1 enters the AC forward defect state if any of the following 
     conditions are met: 
      
     (i)    A physical layer alarm is detected on the Ethernet 
             interface. 

   6.3.2 Forward Defect State Exit 
     A PE exits the Ethernet AC Down state when all defects it had 
     previously detected have disappeared. 
      
   7 AC Defect Entry/Exit Procedures 

   7.1 AC Forward defect entry: 
     On entry to the forward defect state, PE1 may need to perform 
     procedures on both the PW and the AC. 

   7.1.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs 
     On entry to the AC forward defect state, PE1 notifies PE2 of a 
     forward defect: 
      
     For PW over MPLS PSN or MPLS-IP PSN 
     (i)    A PW Status message indicating "forward defect", or  
     (ii)   A VCCV-BFD diagnostic code of "forward defect" if the 
             optional use of VCCV-BFD notification has been negotiated. 
      
     For PW over L2TP-IP PSN 
     (i)    An L2TP Set-Link Info (LSI) message with a Circuit Status 
             AVP indicating "inactive", or  
     (ii)   A VCCV-BFD diagnostic code of "forward defect" if the 
             optional use of VCCV-BFD notification has been negotiated. 

   7.1.2 Procedures for ATM cell PWs 
     On entry to the AC forward defect state, PE1 MUST:  
          a. Commence insertion of ATM AIS cells into the corresponding 
             PW. 
          b. If PE1 is originating F5 I.610 CC cells, PE1 will suspend 
             CC generation for the duration of the defect state. 


    
  Aissaoui, et al.          Expires March 2006                 [Page 15]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
   7.1.3 Additional procedures for ATM ACs 
     On entry to the AC forward defect state PE1 will commence RDI 
     insertion into the AC as per I.610. 

  7.2 AC Reverse defect entry  

   7.2.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs 
     On entry to the AC reverse defect state, PE1 notifies PE2 of a 
     reverse defect: 
      
     For PW over MPLS PSN or MPLS-IP PSN 
     (iii)  A PW Status message indicating "reverse defect", or  
     (iv)   A VCCV-BFD diagnostic code of "reverse defect" if the 
             optional use of VCCV-BFD notification has been 
             negotiated.. 
      
     For PW over L2TP-IP PSN 
     (iii)  An L2TP Set-Link Info (LSI) message with a Circuit Status 
             AVP indicating "inactive", or  
     (iv)   A VCCV-BFD diagnostic code of "reverse defect" if the 
             optional use of VCCV-BFD notification has been negotiated. 

   7.2.2 Procedures for ATM cell PWs 
     ATM AC would be the only potential source of AC reverse defect 
     state within the scope of this document. However, There are no 
     procedures in this case as the AC reverse defect state is not 
     valid for PE1 with a ATM AC and a ATM cell mode PW. 

   7.3 AC Forward Defect Exit 

   7.3.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs 
      
     On exit from the AC forward defect state PE1 notifies PE2 that the 
     forward defect state has cleared (note that this may be a direct 
     state transition to either the working state or the reverse defect 
     state): 
      
     For PW over MPLS PSN or MPLS-IP PSN 
     (i)    A PW Status message with forward defect clear and the 
             remaining indicators showing either working or reverse 
             defect state, or 
     (ii)   A VCCV-BFD diagnostic code with the same attributes as (i) 
             if the optional use of VCCV-BFD notification has been 
             negotiated. 
      
     For PW over L2TP-IP PSN 
     (i)    An L2TP Set-Link Info (LSI) message with a Circuit Status 
             AVP indicating "active", or  


    
  Aissaoui, et al.          Expires March 2006                 [Page 16]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
     (ii)   A VCCV-BFD diagnostic code with the same attributes as (i) 
             if the optional use of VCCV-BFD notification has been 
             negotiated. 

   7.3.2 Procedures for ATM cell PWs 
     On exit from the AC forward defect state, PE1 MUST:  
     (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. 

   7.3.3 Additional procedures for ATM ACs 
     On exit from the AC forward defect state PE1 will cease RDI 
     insertion into the AC as per I.610. 

   7.4 AC Reverse Defect Exit 

   7.4.1 Procedures for FR, ATM AAL5, IP or Ethernet PWs 
     On exit from the AC reverse defect state, PE1 notifies PE2 that 
     the reverse defect state has cleared (note that this may be a 
     direct state transition to either the working state or the forward 
     defect state). Depending on the negotiated notification mechanism 
     this will be one of: 
      
     For PW over MPLS PSN or MPLS-IP PSN 
     (i)    A PW Status message with the "reverse defect" indicator 
             cleared and the remaining indicators showing either 
             working or a transition to the "forward defect" state, or 
     (ii)   A VCCV-BFD diagnostic code with the same information as 
             (i) if the optional use of VCCV-BFD notification has been 
             negotiated. 
      
     For PW over L2TP-IP PSN 
     (i)    An L2TP Set-Link Info (LSI) message with a Circuit Status 
             AVP indicating "active", or 
     (ii)   A VCCV-BFD diagnostic code with the same information as 
             (i) if the optional use of VCCV-BFD notification has been 
             negotiated. 

   7.4.2 Procedures for ATM cell PWs 
     ATM AC would be the only potential source of AC reverse defect 
     state within the scope of this document. However, there are no 
     procedures in this case as the AC reverse defect state is not 
     valid for PE1 with a ATM AC and a ATM cell mode PW. 
      



    
  Aissaoui, et al.          Expires March 2006                 [Page 17]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
   8 PW Forward Defect Entry/Exit procedures 

   8.1 PW Forward Defect Entry Procedures 

   8.1.1 FR AC procedures  
     These procedures are applicable only if the transition from the 
     working state to the PW Forward defect state. A transition from PW 
     reverse defect state to the forward defect state does not require 
     any additional notification procedures to the FR AC as it has 
     already been told the peer is down. 
     (i)    PE1 MUST generate a full status report with the Active bit 
             = 0 (and optionally in the asynchronous status message), 
             as per Q.933 annex A, into N1 for the corresponding FR 
             ACs. 

   8.1.2 Ethernet AC Procedures 
     No procedures are currently defined. 

   8.1.3 ATM AC procedures 
     On entry to the PW Forward Defect State 
     (i)    PE1 MUST commence F5 AIS insertion into the corresponding 
             AC. 
     (ii)   PE1 MUST terminate any F5 CC generation on the 
             corresponding AC. 

   8.1.4 Additional procedures for FR, ATM AAL5, IP or Ethernet PWs 
     If the PW failure was explicitly detected by PE1, it MUST assume 
     PE2 has no knowledge of the defect and MUST notify PE2 in the form 
     of a reverse defect notification: 
      
     For PW over MPLS PSN or MPLS-IP PSN 
     (i)    A PW Status message indicating a "reverse defect", or 
     (ii)   A VCCV-BFD diagnostic code indicating a "reverse defect" 
             if the optional use of VCCV-BFD notification has been 
             negotiated. 
      
     For PW over L2TP-IP PSN 
      
     (i)    An L2TP Set-Link Info (LSI) message with a Circuit Status 
             AVP indicating "active", or  
     (ii)   A VCCV-BFD diagnostic code with the same attribute as (i) 
             if the optional use of VCCV-BFD notification has been 
             negotiated. 
      
     Otherwise the entry to the defect state was the result of a 
     notification from PE2 (indicating that PE2 already had knowledge 
     of the fault) or loss of the control adjacency (similarly visible 
     to PE2). 


    
  Aissaoui, et al.          Expires March 2006                 [Page 18]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
   8.1.5 Additional procedures for ATM Cell PWs 
     If the PW failure was explicitly detected, by PE1 by entering to 
     the ATM AIS state or loss of CC, PE1 MUST also commence RDI 
     insertion into the reverse direction of the PW. 

   8.2 PW Forward Defect Exit Procedures 

   8.2.1 FR AC procedures  
     On transition from the PW forward defect state to the reverse 
     defect state PE1 takes no action with respect to the AC. 
      
     On exit from the PW Forward defect state 
     (i)    PE1 MUST generate a full status report with the Active bit 
             = 1 (and optionally in the asynchronous status message), 
             as per Q.933 annex A, into N1 for the corresponding FR 
             ACs. 

   8.2.2 Ethernet AC Procedures 
     No procedures are currently defined 

   8.2.3 ATM AC procedures 
     On exit from the PW Forward Defect State 
     (i)    PE1 MUST cease F5 AIS insertion into the corresponding AC. 
     (ii)   PE1 MUST resume any F5 CC generation on the corresponding 
             AC. 

   8.2.4 Additional procedures for FR, ATM AAL5, IP or Ethernet PWs 
     If the PW failure was explicitly detected by PE1, it MUST notify 
     PE2 in the form of clearing the reverse defect notification: 
      
     For PW over MPLS PSN or MPLS-IP PSN 
     (i)    A PW Status message with the "reverse defect" indication 
             clear, and the remaining indicators showing either working 
             or a transition to the "forward defect" state, or 
     (ii)   A VCCV-BFD diagnostic code with the same attribute as in 
             (i) if the optional use of VCCV-BFD notification has been 
             negotiated. 
      
     For PW over L2TP-IP PSN 
     (i)    An L2TP Set-Link Info (LSI) message with a Circuit Status 
             AVP indicating "active", or  
     (ii)   A VCCV-BFD diagnostic code with the same attributes as (i) 
             if the optional use of VCCV-BFD notification has been 
             negotiated. 

   8.2.5 Additional procedures for ATM Cell PWs 
     On exit from the PW forward defect state, PE1 will cease F5 RDI 
     generation into the corresponding PW. 

    
  Aissaoui, et al.          Expires March 2006                 [Page 19]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
   8.3 PW Reverse Defect Entry Procedures 

   8.3.1 FR AC procedures  
     On transition from the PW forward defect state to the reverse 
     defect state PE1 takes no action with respect to the AC. 
      
     On entry to the PW Forward defect state 
     (i)    PE1 MUST generate a full status report with the Active bit 
             = 0 (and optionally in the asynchronous status message), 
             as per Q.933 annex A, into N1 for the corresponding FR 
             ACs. 

   8.3.2 Ethernet AC Procedures 
     No procedures are currently defined 

   8.3.3 ATM AC procedures 
     On entry to the PW Reverse Defect State 
     (i)    PE1 MUST commence F5 RDI insertion into the corresponding 
             AC. 

   8.4 PW Reverse Defect Exit Procedures 

   8.4.1 FR AC procedures  
     On transition from the PW reverse defect state to the PW forward 
     defect state PE1 takes no action with respect to the AC. 
      
     On exit from the PW Reverse defect state 
     (i)    PE1 MUST generate a full status report with the Active bit 
             = 1 (and optionally in the asynchronous status message), 
             as per Q.933 annex A, into N1 for the corresponding FR 
             ACs. 

   8.4.2 Ethernet AC Procedures 
     No procedures are currently defined 

   8.4.3 ATM AC procedures 
     On exit from the PW Reverse Defect State 
     (i)    PE1 MUST cease F5 RDI insertion into the corresponding AC. 
      
   9 Security Considerations 
      
     This draft does not introduce any new security considerations to 
     VPWS. Though, it is worth mentioning that in the heterogeneous 
     VPWS OAM model, a flooding of alarms on the ACs may result in a 
     large number of PW status signaling messages generated. This may 
     have an impact on the performance of the MPLS control plane. This 
     issue should be investigated and solutions should be provided if 
     required. A method for aggregating PW status messages is one 
     possible solution. 

    
  Aissaoui, et al.          Expires March 2006                 [Page 20]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
      
   10 Intellectual Property Disclaimer 
      
     The IETF takes no position regarding the validity or scope of any 
     intellectual property or other rights that might be claimed to 
     pertain to the implementation or use of the technology described 
     in this document or the extent to which any license under such 
     rights might or might not be available; neither does it represent 
     that it has made any effort to identify any such rights.  
     Information on the IETF's procedures with respect to rights in 
     standards-track and standards-related documentation can be found 
     in BCP-11. Copies of claims of rights made available for 
     publication and any assurances of licenses to be made available, 
     or the result of an attempt made to obtain a general license or 
     permission for the use of such proprietary rights by implementers 
     or users of this specification can be obtained from the IETF 
     Secretariat.  
           
     The IETF invites any interested party to bring to its attention 
     any copyrights, patents or patent applications, or other 
     proprietary rights which may cover technology that may be required 
     to practice this standard.  Please address the information to the 
     IETF Executive Director. 
      
   11 References 
      
     [ARP-MEDIATION] Shah, H., et al., "ARP Mediation for IP 
          interworking of Layer 2 VPN", draft-ietf-l2vpn-arp-mediation-
          03.txt, August 2005. 
      
     [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection", 
          Internet Draft <draft-ietf-bfd-base-03.txt>, July 2005  
      
     [FRF8.2] Frame Relay Forum, "FRF 8.2 - Frame Relay / ATM PVC 
          Service Interworking Implementation Agreement", February 
          2004. 
      
     [FRF.19] Frame Relay Forum, "Frame Relay Operations, 
          Administration, and Maintenance Implementation Agreement", 
          March 2001. 
      
     [I.610] "B-ISDN operation and maintenance principles and 
          functions", ITU-T Recommendation I.610, February 1999. 
      
     [L2TPv3] Lau, J., et.al. " Layer Two Tunneling Protocol (Version 
          3", RFC 3931, March 2005. 
      
     [L2VPN-FRMK] Andersson, L. et. al., "L2VPN Framework", draft-ietf-
          l2vpn-l2-framework-05.txt, June 2004. 
      
     [LSP-BFD] Aggarwal, R., et al., "BFD For MPLS LSPs", draft-ietf-
          bfd-mpls-02.txt, July 2005. 
      
    
  Aissaoui, et al.          Expires March 2006                 [Page 21]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
     [LSP-Ping] Kompella, K., et al., "Detecting MPLS Data Plane 
          Liveness", draft-ietf-mpls-lsp-ping-09.txt, May 2005. 
      
     [MPLS-in-IP] Worster. T., et al., "Encapsulating MPLS in IP or 
          Generic Routing Encapsulation (GRE)", RFC 4023, March 2005. 
      
     [OAM-MSG] Nadeau, T., et al., "Pseudo Wire (PW) OAM Message 
          Mapping", draft-ietf-pwe3-oam-msg-map-03.txt, September 2005. 
      
     [PWE3-ATM] Martini, L., et al., "Encapsulation Methods for 
          Transport of ATM Over IP and MPLS Networks", draft-ietf-pwe3-
          atm-encap-09.txt, June 2005. 
      
     [PWE3-CONTROL] Martini, L., et al., "Pseudowire Setup and 
          Maintenance using LDP", draft-ietf-pwe3-control-protocol-
          17.txt, June 2005. 
      
     [PWE3-ETH] Martini, L., et al., "Encapsulation Methods for 
          Transport of Ethernet Frames Over IP/MPLS Networks", draft-
          ietf-pwe3-ethernet-encap-10.txt, June 2005. 
      
     [PWE3-FR] Kawa, C., et al., "Frame Relay over Pseudo-Wires", 
          draft-ietf-pwe3-frame-relay-05.txt, April 2005. 
      
     [PWE3-IANA] Martini, L. et.al., "IANA Allocations for pseudo Wire 
          Edge to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-
          allocation-07.txt, October 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-05.txt, 
          August 2005. 
       
     [Y.1711] "OAM Mechanisms for MPLS Networks", ITU-T Recommendation 
          Y.1711, November 2002. 
      
   12 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 
      
    
  Aissaoui, et al.          Expires March 2006                 [Page 22]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
     David Watkinson 
     Alcatel 
     600 March Rd 
     Kanata, ON, Canada. K2K 2E6 
     Email: david.watkinson@alcatel.com 
      
     Hamid Ould-Brahim  
     Nortel Networks   
     P O Box 3511 Station C  
     Ottawa ON K1Y 4H7 Canada                        
     Phone: +1 (613) 765 3418                    
     Email: hbrahim@nortelnetworks.com 
      
     Mike Loomis 
     Nortel Networks 
     600 Technology Park Dr. 
     Billerica, MA 01821 
     Phone: +1-978-288-6322  
     Email: mloomis@nortelnetworks.com 
      
     David Allan 
     Nortel Networks 
     3500 Carling Ave., 
     Ottawa, Ontario, CANADA 
     Email: dallan@nortelnetworks.com 
      
     Thomas D. Nadeau 
     Cisco Systems, Inc. 
     300 Beaverbrook Drive 
     Boxborough, MA  
     Phone: +1-978-936-1470 
     Email: tnadeau@cisco.com 
      
     Monique Morrow 
     Cisco Systems, Inc. 
     Glatt-com 
     CH-8301 Glattzentrum 
     Switzerland 
     Email: mmorrow@cisco.com 
      
     John Yu                                       
     Hammerhead Systems, Inc.                      
     640 Clyde Court                               
     Mountain View, CA 94043 USA           
     Phone: +1 650 210 3312                        
     Email: john@hammerheadsystems.com 
      
     Himanshu Shah  
     Ciena Networks  
     35 Nagog Park,  
     Acton, MA 01720  
     Email: hshah@ciena.com 
      
    
  Aissaoui, et al.          Expires March 2006                 [Page 23]  
   
  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-03.txt September 2005 
   
     Paul Doolan 
     Mangrove Systems 
     10 Fairfield Blvd., 
     Wallingford, CT 06492 
     Email: pdoolan@mangrovesystems.com 
      
     Peter B. Busschbach  
     Lucent Technologies  
     67 Whippany Road              
     Whippany, NJ, 07981           
     Email: busschbach@lucent.com 
      
     Simon Delord 
     France Telecom 
     2 av, Pierre Marzin 
     22300 LANNION, France 
     E-mail: simon.delord@francetelecom.com 
      
     Vasile Radoaca 
     West Ridge Networks  
     Littleton, MA 01460 
     Email: vradoaca@westridgenetworks.com 
      
   13 Full Copyright Statement 
      
     "Copyright (C) The Internet Society (2005). 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 March 2006                 [Page 24]