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

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

      L2VPN Working Group                                Mustapha Aissaoui
      Internet Draft                                         Matthew Bocci
      Expiration Date: August 2004                         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
  
                                                             February 2004
  
  
                    OAM Procedures for VPWS Interworking
                   draft-aissaoui-l2vpn-vpws-iw-oam-00.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 Virtual Private
     Wire Service (VPWS).
  
  
  
  
  Aissaoui, et al.         Expires August 2004                 [Page 1]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt  February 2004
  
  Table of Contents
  
     Status of this Memo.............................................1
     Abstract........................................................1
     Table of Contents...............................................2
     1 Conventions used in this document.............................2
     2 Introduction..................................................2
     3 General OAM Procedures........................................3
      3.1 Defect Locations...........................................3
      3.2 VPWS OAM Interworking Models...............................4
      3.3 PW Status..................................................5
      3.4 ATM AC Status..............................................5
      3.5 FR AC Status...............................................5
      3.6 Ethernet AC Status.........................................5
     4 OAM Procedures for VPWS with homogeneous ACs..................6
      4.1 ATM VPWS...................................................6
      4.2 FR VPWS....................................................7
      4.3 Ethernet VPWS..............................................7
     5 OAM Procedures for VPWS with heterogeneous ACs................8
      5.1 FR-ATM Interworking VPWS...................................8
         5.1.1 Heterogeneous VPWS OAM Model..........................8
         5.1.2 Homogeneous VPWS OAM Model............................9
      5.2 Ethernet Interworking VPWS.................................9
      5.3 IP Interworking VPWS......................................10
     6 Security Considerations......................................11
     7 Intellectual Property Disclaimer.............................11
     8 References...................................................11
     9 Authors' Addresses...........................................12
     10 Full Copyright Statement....................................13
  
  
   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      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 homogeneous attachment circuits (ACs) of ATM, FR, or
        Ethernet types.
  
  
  
  Aissaoui, et al.         Expires August 2004                 [Page 2]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt  February 2004
  
     2. 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.1] 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ö.
  
     3. 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ö.
  
     4. 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ö.
  
     The following topics are not covered and may be addressed in a
     future revision of this document:
  
     1.   ATM ILMI Interworking
  
     2.   Handling of Loopback and CC OAM cells for ATM [I.610].
  
     3.   The use of an inband PW method to notify the remote PE of the
     status of the PW.
  
   3      General OAM Procedures
  
   3.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| (L2N1)   |    |                  |    | (L2N2)   |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:
  
  
  
  Aissaoui, et al.         Expires August 2004                 [Page 3]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt  February 2004
  
     (a)  Defect in the first L2 network (L2N1). This covers any defect
          in the L2N1 which impacts all or a subset of ACs terminating
          in PE1. The defect is conveyed to PE1 and to the remote L2
          network (L2N2) 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 (L2N2). This covers any
          defect in L2N2 which impacts all or a subset of ACs
          terminating in PE2. The defect is conveyed to PE2 and to the
          remote L2 network (L2N1) using a L2 specific OAM defect
          indication.
     (f)  Defect on a PE2 AC interface.
  
   3.2        VPWS OAM Interworking Models
  
     There are two different OAM interworking models which are dictated
     by the type of VPWS.
  
     In a homogeneous VPWS, the link layer of the AC is not terminated
     at a PE. 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 OAM model. An example of this is ATM VPWS OAM
     procedures as specified in [PWE3-ATM]. However, it is acknowledged
     that some PE implementations may not be capable of generating
     and/or passing native service OAM messages over a PW. For those
     situations, an optional procedure based on terminating the native
     service OAM and conveying the corresponding status using out-of-
     band PW status signaling messages [PWE3-CONTROL] is proposed. This
     method is also proposed for the FR VPWS and the Ethernet VPWS for
     different reasons. Frame Relay link management protocol is widely
     used on FR UNI links but there is no known deployment of FR OAM
     standard [FRF.19]. Finally, Ethernet link management and OAM
     standards are at their early development stage.
  
     In a heterogeneous VPWS, 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 status using out-of-band PW status signaling
     messages. This model is referred to as the heterogeneous VPWS OAM
     model. As always, there is an exception to this. The FR-ATM
     interworking VPWS can be achieved by extending a ATM PW, instead
     of a FR PW, to the remote PE. Therefore, one can use the
     homogeneous VPWS OAM model and rely on the native ATM OAM inband.
  
  
  
  Aissaoui, et al.         Expires August 2004                 [Page 4]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt  February 2004
  
   3.3        PW Status
  
     A PW is declared DOWN if any of the following conditions are met:
     (i)    A physical layer alarm is detected on the PSN interface.
  
     (ii)   The status of the PSN tunnel over which the PW is riding
             is DOWN. In the case of a MPLS PSN, this status can be the
             result of running a MPLS specific OAM mechanism such as
             LSP-Ping [LSP-Ping] 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 status can be the result of a PE
             receiving a RSVP-TE PathErr message.
  
     (iii)  A remote PW status message [PWE3-CONTROL] is received
             indicating that one or both directions of the PW are down.
  
     (iv)   An inband PW OAM connectivity verification, such as VCCV
             [VCCV] or Y.1711 CV, or the receipt of a Y.1711 FDI/BDI
             indicates that one or both directions of the PW are down.
  
     Note that a PW is a bidirectional entity. A defect in one of the
     directions is treated as a defect in the entire PW.
  
   3.4        ATM AC Status
  
     An ATM AC is declared DOWN if any of the following conditions are
     met:
     (i)    A physical layer alarm is detected on the ATM interface.
     (ii)   PE2 receives an F4/F5 AIS/RDI OAM cell indicating that the
             ATM VP/VC is down in the L2N2 ATM network.
  
   3.5        FR AC Status
  
     A FR AC is declared 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 PE1 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.
  
   3.6        Ethernet AC Status
  
  
  
  Aissaoui, et al.         Expires August 2004                 [Page 5]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt  February 2004
  
     An Ethernet AC is declared DOWN if any of the following conditions
     are met:
     (i)    A physical layer alarm is detected on the Ethernet
             interface.
  
   4      OAM Procedures for VPWS with homogeneous ACs
  
     Note: it has been pointed out at time of publication that Section
     4 of this document and revision 4 of draft-nadeau-pwe3-oam-msg-map
     [OAM-MSG] converged on many aspects. It is the intent of the
     authors of the two drafts to fully align these sections and move
     the result into the next revision of draft-nadeau-pwe3-oam-msg-
     map.
  
   4.1        ATM VPWS
  
     The ATM VPWS is based on the PWE3 ATM PW specification [PWE3-ATM].
     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].
  
     In normal, i.e., defect-free, operation, all the above types of
     ATM OAM cells are either terminated at the PE, for OAM segments
     terminating in the AC endpoint, or transparently carried over the
     PSN tunnel [PWE3-ATM]. In other words, the ATM VPWS makes use of
     the homogeneous VPWS OAM model.
  
     Defects in locations (a) or (b) should be conveyed to the remote
     ATM network L2N2 [PWE3-ATM]. In this case, PE1 should
     transparently carry the AIS/RDI cells received on the
     corresponding AC (defect a) or generated locally (defect b) over
     the corresponding ATM PW.
  
     Optionally, if PE1 cannot generate and/or transmit ATM OAM cells
     over the ATM PW, it may use the heterogeneous OAM model. PE1
     should change the status of the corresponding ATM ACs to DOWN and
     generate PW status signaling messages [PWE3-CONTROL] to notify PE2
     of the defect. PE2 will in turn generate AIS messages on the
     corresponding ACs towards L2N2.
  
     Defects in locations (c) or (d) will result in changing the status
     of the PSN tunnel and the corresponding PWs (both directions) to
     DOWN in PE1. Note that PE1 will only know that the transmit
     direction of the PSN tunnel is down. The receive direction for
     that same PSN tunnel can terminate on any other PSN interface and
     its status at PE1 is unknown. PE1 should generate AIS on the
     affected ACs to convey this status to L2N1 [PWE3-ATM]. Given that
     the transmit direction of the PSN tunnel is down, PE1 cannot use
     an ATM AIS inband to notify PE2 and L2N2. Therefore, an out-of-
     band notification may be used here. PE1 may generate PW status
     signaling messages to notify PE2 of the defect. Also, in the case
     of a MPLS PSN, PE2 may be able to detect the defect on its own by
  
  Aissaoui, et al.         Expires August 2004                 [Page 6]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt  February 2004
  
     running LSP-Ping [LSP-Ping] or Y.1711 CV [Y.1711] over the tunnel
     LSP. Also, PE2 may receive a RSVP-TE PathErr message if the other
     direction of the PSN tunnel has failed. In any case, PE2 should in
     turn generate AIS messages on the corresponding ACs towards L2N2.
  
     The handling of a defect in locations (e) and (f) is similar to
     that of locations (a) and (b) respectively.
  
   4.2        FR VPWS
  
     The FR VPWS is based on the PWE3 FR PW specification [PWE3-FR].
     Frame relay networks make use of PVC management over a FR UNI.
     This is based on Q.933 Annex A. A more extensive FR OAM capability
     set has subsequently been specified by the FR Forum [FRF.19] but
     this has little known deployments. Based on that, it is proposed
     to use the heterogeneous VPWS OAM model.
  
     In order to provide end-to-end defect notification in a FR VPWS,
     the following procedures should be followed.
  
     Defects in locations (a) or (b) will result in changing the status
     of the corresponding FR ACs to DOWN in PE1. In this case, PE1
     should generate a PW status message on each of the corresponding
     FR PWs to convey this status to the remote PE (PE2). PE2 should in
     turn generate a full status report with the Active bit = 0 (and
     optionally in the asynchronous status message), as per Q.933 annex
     A, into L2N2 for the corresponding FR ACs.
  
     A FR AC is declared DOWN if any of the conditions described in
     Section 3.5 are met.
  
     Defects in locations (c) or (d) will result in changing the status
     of the corresponding PWs (both directions) to DOWN in PE1. In this
     case, PE1 should translate this status by sending Active bit = 0
     in the full status report (and optionally in the asynchronous
     status message), as per Q.933 annex A, into L2N1 and for the
     corresponding FR ACs. In addition, PE1 should send a PW status
     signaling message to the remote PE to convey the status of the
     affected PWs. PE2 should in turn generate a full status report
     with the Active bit = 0 (and optionally in the asynchronous status
     message), as per Q.933 annex A, into L2N2 for the corresponding FR
     ACs.
  
     A PW is declared DOWN if any of the conditions described in
     Section 3.3 are met.
  
     The handling of a defect in locations (e) and (f) is similar to
     that of locations (a) and (b) respectively.
  
   4.3        Ethernet VPWS
  
  
  
  Aissaoui, et al.         Expires August 2004                 [Page 7]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt  February 2004
  
     The Ethernet VPWS is based on the PWE3 Ethernet PW specification
     [PWE3-ETH]. Ethernet link layer management and service OAM
     standards are at their early development stage. Therefore, the
     determination of Ethernet AC status is based on the status of the
     physical interface. In addition, Ethernet AC status change can
     only be conveyed to a management system. Based on that, it is
     proposed to use the heterogeneous VPWS OAM model.
  
     In order to provide end-to-end defect notification in an Ethernet
     VPWS, the following procedures should be followed.
  
     Defects in locations (a) or (b) will result in changing the status
     of the corresponding Ethernet ACs to DOWN in PE1. In this case,
     PE1 should generate a PW status message on each of the
     corresponding Ethernet PWs to convey this status to the remote PE
     (PE2). PE2 should in turn change the status of the corresponding
     Ethernet ACs to DOWN.
  
     An Ethernet AC is declared DOWN if any of the conditions described
     in Section 3.6 are met.
  
     Defects in locations (c) or (d) will result in changing the status
     of the corresponding PWs (both directions) to DOWN in PE1. In this
     case, PE1 should translate this status by changing the status of
     the corresponding Ethernet ACs to DOWN. In addition, PE1 should
     send a PW status signaling message to the remote PE to convey the
     status of the affected PWs. PE2 should in turn change the status
     of the corresponding Ethernet ACs to DOWN.
  
     A PW is declared DOWN if any of the conditions described in
     Section 3.3 are met.
  
     The handling of a defect in locations (e) and (f) is similar to
     that of locations (a) and (b) respectively.
  
   5      OAM Procedures for VPWS with heterogeneous ACs
  
   5.1        FR-ATM Interworking VPWS
  
     The FR-ATM interworking VPWS consists of interworking FR and ATM
     ACs over the PSN. Frame relay networks make use of PVC management
     over a FR UNI. This is based on Q.933 Annex A. ATM networks make
     use of the ATM OAM capabilities as specified in [I.610].
  
   5.1.1         Heterogeneous VPWS OAM Model
  
     In order to provide end-to-end defect notification in a FR-ATM
     interworking VPWS, the following procedures should be followed.
     For clarity of the text, it is assumed that the ACs attached to
     PE1 in Figure 2 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
  
  
  Aissaoui, et al.         Expires August 2004                 [Page 8]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt  February 2004
  
     FRF.8.1 [FRF.8.1] interworking function resides in PE1. The PW
     type is FR if it resides in PE2.
  
     Defects in locations (a) or (b) will result in changing the status
     of the corresponding FR ACs to DOWN in PE1. In this case, PE1
     should generate a PW status message on each of the corresponding
     FR PWs to convey this status to the remote PE (PE2). PE2 should in
     turn translate this status into an ATM AIS message to be sent in
     each of the corresponding ATM ACs.
  
     A FR AC is declared DOWN if any of the conditions described in
     Section 3.5 are met.
  
     Defects in locations (c) or (d) will result in changing the status
     of the corresponding PWs (both directions) to DOWN in PE1. In this
     case, PE1 should translate this status by sending Active bit = 0
     in the full status report (and optionally in the asynchronous
     status message), as per Q.933 annex A, into the local Frame Relay
     network and for the corresponding FR ACs. In addition, PE1 should
     send a PW status signaling message to the remote PE to convey the
     status of the affected PWs. PE2 should in turn translate this
     status into an ATM AIS message to be sent in each of the
     corresponding ATM ACs.
  
     A PW is declared DOWN if any of the conditions described in
     Section 3.3 are met.
  
     Defects in location (e) or (f) will result in changing the status
     of the corresponding ATM ACs to DOWN in PE2. In this case, PE2
     should generate a PW status message on each of the corresponding
     PWs to convey this status to PE1. PE1 should in turn translate
     this status by sending Active bit = 0 in the full status report
     (and optionally in the asynchronous status message), as per Q.933
     annex A, into the local Frame Relay network and for the
     corresponding FR ACs.
  
     An ATM AC is declared DOWN if any of the conditions described in
     Section 3.4 are met.
  
   5.1.2          Homogeneous VPWS OAM Model
  
     When the PW type is ATM, the homogeneous VPWS OAM procedures may
     be used instead. These are described in Section 4.1 for a ATM
     VPWS.
  
   5.2        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]. The heterogeneous VPWS OAM model is used here.
  
  
  
  Aissaoui, et al.         Expires August 2004                 [Page 9]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt  February 2004
  
     In order to provide end-to-end defect notification in a Ethernet
     interworking VPWS, the following procedures should be followed.
     For clarity of the text, it is assumed that the ACs attached to
     PE1 in Figure 2 are of FR type. It is also assumed that the ACs
     attached to PE2 are either of ATM type or of a Ethernet type.
  
     Defects in locations (a) or (b) will result in changing the status
     of the corresponding FR ACs to DOWN in PE1. In this case, PE1
     should generate a PW status message on each of the corresponding
     PWs to convey this status to the remote PE (PE2). PE2 should in
     turn translate this status into an ATM AIS message to be sent in
     each of the corresponding ATM ACs. Also, PE2 should change the
     status of the corresponding Ethernet ACs to DOWN.
  
     A FR AC is declared DOWN if any of the conditions described in
     Section 3.5 are met.
  
     Defects in locations (c) or (d) will result in changing the status
     of the corresponding PWs (both directions) to DOWN in PE1. In this
     case, PE1 should translate this status by sending Active bit = 0
     in the full status report (and optionally in the asynchronous
     status message), as per Q.933 annex A, into the local Frame Relay
     network (L2N1) and for the corresponding FR ACs. In addition, PE1
     should send a PW status signaling message to the remote PE to
     convey the status of the affected PWs. PE2 should in turn
     translate this status into an ATM AIS message to be sent in each
     of the corresponding ATM ACs. Also, PE2 should change the status
     of the corresponding Ethernet ACs to DOWN.
  
     A PW is declared DOWN if any of the conditions described in
     Section 3.3 are met.
  
     Defects in location (e) or (f) will result in changing the status
     of the corresponding ATM ACs or Ethernet ACs to DOWN in PE2. In
     this case, PE2 should generate a PW status message on each of the
     corresponding PWs to convey this status to PE1. PE1 should in turn
     translate this status by sending Active bit = 0 in the full status
     report (and optionally in the asynchronous status message), as per
     Q.933 annex A, into the local Frame Relay network and for the
     corresponding FR ACs.
  
     An ATM AC is declared DOWN if any of the conditions described in
     Section 3.4 are met.
  
     An Ethernet AC is declared DOWN if any of the conditions described
     in Section 3.6 are met.
  
   5.3        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 heterogeneous VPWS OAM model is used here.
  
  Aissaoui, et al.         Expires August 2004                [Page 10]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt  February 2004
  
  
     The OAM procedures for this VPWS type are the same as those for
     the Ethernet Interworking VPWS. See Section 5.2 for details.
  
   6      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.
  
   7      Intellectual Property Disclaimer
  
     This document is being submitted for use in IETF standards
     discussions.
  
   8      References
  
     [L2VPN-FRMK] Andersson, L. et. al., "L2VPN Framework", draft-ietf-
          l2vpn-l2-framework-03.txt, October 2003.
  
     [FRF8.1] Frame Relay Forum, ôFRF 8.1 - Frame Relay / ATM PVC
          Service Interworking Implementation Agreementö, February
          2000.
  
     [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-nadeau-pwe3-oam-msg-map-04.txt, January 2004.
  
     [PWE3-ATM] Martini, L., et al., ôEncapsulation Methods for
          Transport of ATM Over IP and MPLS Networksö, draft-ietf-pwe3-
          atm-encap-04.txt, December 2003.
  
     [PWE3-CONTROL] Martini, L., et al., ôPseudowire Setup and
          Maintenance using LDPö, draft-ietf-pwe3-control-protocol-
          05.txt, December 2003.
  
     [PWE3-FR] Kawa, C., et al., ôFrame Relay over Pseudo-Wiresö,
          draft-ietf-pwe3-frame-relay-01.txt, July 2003.
  
  
  Aissaoui, et al.         Expires August 2004                [Page 11]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt  February 2004
  
     [FRF.19] Frame Relay Forum, ôFrame Relay Operations,
          Administration, and Maintenance Implementation Agreementö,
          March 2001.
  
     [LSP-Ping] Kompella, K., et al., ôDetecting MPLS Data Plane
          Livenessö, draft-ietf-mpls-lsp-ping-04.txt, October 2003.
  
     [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-01.txt,
          October 2003.
  
     [PWE3-ETH] Martini, L., et al., ôEncapsulation Methods for
          Transport of Ethernet Frames Over IP/MPLS Networksö, draft-
          ietf-pwe3-ethernet-encap-05.txt, December 2003.
  
   9      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
  
  Aissaoui, et al.         Expires August 2004                [Page 12]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt  February 2004
  
     Cisco Systems, Inc.
     300 Beaverbrook Drive
     Boxborough, MA
     Phone: +1-978-936-1470
     Email: tnadeau@cisco.com
  
     Monique Morrow
     Cisco Systems, Inc.
     Glatt-com
     CH-8301 Glattzentrum
     Switzerland
     Email: mmorrow@cisco.com
  
     John Yu
     Hammerhead Systems, Inc.
     640 Clyde Court
     Mountain View, CA 94043 USA
     Phone: +1 650 210 3312
     Email: john@hammerheadsystems.com
  
     Himanshu Shah
     Ciena Networks
     35 Nagog Park,
     Acton, MA 01720
     Email: hshah@ciena.com
  
     Paul Doolan
     Mangrove Systems
     10 Fairfield Blvd.,
     Wallingford, CT 06492
     Email: pdoolan@mangrovesystems.com
  
     Peter B. Busschbach
     Lucent Technologies
     67 Whippany Road
     Whippany, NJ, 07981
     Email: busschbach@lucent.com
  
   10       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
  
  Aissaoui, et al.         Expires August 2004                [Page 13]


  Internet Draft draft-aissaoui-l2vpn-vpws-iw-oam-00.txt  February 2004
  
     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 August 2004                [Page 14]
  

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