Pseudo-Wire Edge-to-Edge (PWE3)                     Thomas D. Nadeau
Internet Draft                                        Monique Morrow
Expires: July 2004                                Cisco Systems, Inc

                                                    Peter Busschbach
                                                 Lucent Technologies
                                                             Editors


                                                        January 2004


                   Pseudo Wire (PW) OAM Message Mapping
                  draft-nadeau-pwe3-oam-msg-map-04.txt



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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



Abstract

   This document enumerates the OAM message mapping from pseudo wire
   emulated edge-to-edge services over MPLS and IP transport networks to
   their native attached services.



Table of Contents

   1. Scope..........................................................2
   2. Terminology....................................................2
   3. Introduction...................................................3
      3.1 Network Reference Model....................................3
   4. PW Failures....................................................4
      4.1 Failures...................................................4
      4.2 Fault Detection............................................5



Nadeau et al.                Expires July 2004               [Page 1]


Internet Draft            PWE3 OAM MSG MAP           January 26, 2004



      4.3 Alarm Messages and Consequent Actions......................6
      4.4 The Use of PW Status.......................................7
      4.5 The Use of L2TP SCCN and CDN...............................7
      4.6 The Use of BFD Diagnostic Codes............................8
      4.7 PW Failure Entry and Exit Procedures.......................9
   5. Frame Relay Encapsulation.....................................10
      5.1 Frame Relay Management....................................10
      5.2 Mapping PW failures to Frame Relay OAM messages...........11
      5.3 Frame Relay Attachment Circuit Failures...................11
   6. ATM Encapsulation.............................................12
      6.1 ATM Management............................................12
      6.2 Mapping PW Failures to ATM OAM............................13
      6.3 ATM Attachment Circuit Failures...........................13
   7. SONET Encapsulation (CEP).....................................14
   8. TDM Encapsulation.............................................14
   9. Ethernet Encapsulation........................................14
   10. Security Considerations......................................14
   11. Acknowledgments..............................................15
   12. References...................................................15
   13. Intellectual Property Rights Notices.........................16
   14. Full Copyright Statement.....................................17
   Author's Addresses...............................................17


1. Scope

   This document covers the mapping of Pseudo Wire failures to error
   messages in the emulated services and the mapping of failures on
   Attachment Circuits (AC) to PW Status messages.

   This document covers both PWE over MPLS PSN and PWE over IP PSN.

   This document does not cover Service Interworking, i.e. the cases in
   which the native service at one side of the PW is different from the
   native service at the other side.



2. Terminology

   AIS   Alarm Indication Signal
   AOM   Administration, Operation and Maintenance
   BDI   Backward Defect Indication
   CC    Continuity Check
   CE    Customer Edge
   CPCS  Common Part Convergence Sublayer
   DLC   Data Link Connection
   FDI   Forward Defect Indication
   FRBS  Frame Relay Bearer Service
   IWF   Interworking Function



Nadeau et al.                Expires July 2004               [Page 2]


Internet Draft            PWE3 OAM MSG MAP           January 26, 2004



   LB    Loopback
   NE    Network Element
   OAM   Operations and Maintenance
   PE    Provider Edge
   PW    Pseudowire
   PSN   Packet Switched Network
   RDI   Remote Defect Indicator
   SDU   Service Data Unit
   VCC   Virtual Channel Connection
   VPC   Virtual Path Connection

   The rest of this document will follow the following convention:

   If LSP-Ping is run over a PW as described in [VCCV] it will be
   referred to as VCCV-Ping.

   If BFD is run over a PW as described in [VCCV] it will be referred to
   as VCCV-BFD.


3. Introduction

   This document describes how PW failures can be detected; how alarm
   information is exchanged between PEs; and how faults detected in
   pseudo-wires are mapped to OAM messages native to the emulated
   services and vice versa.

   The objective of this document is to standardize the behavior of PEs
   with respects to failures on PWs and ACs, so that there is no
   ambiguity about the alarms generated and consequent actions
   undertaken by PEs in response to specific failure conditions.


3.1 Network Reference Model

   Figure 1 illustrates the network reference model for point-to-point
   PWs.


               |<-------------- Emulated Service ---------------->|
               |                                                  |
               |          |<------- Pseudo Wire ------>|          |
               |          |                            |          |
               |          |    |<-- PSN Tunnel -->|    |          |
               | PW End   V    V                  V    V  PW End  |
               V Service  +----+                  +----+  Service V
         +-----+    |     | PE1|==================| PE2|     |    +----+
         |     |----------|............PW1.............|----------|    |
         | CE1 |    |     |    |                  |    |     |    |CE2 |
         |     |----------|............PW2.............|----------|    |



Nadeau et al.                Expires July 2004               [Page 3]


Internet Draft            PWE3 OAM MSG MAP           January 26, 2004



         +-----+  ^ |     |    |==================|    |     | ^  +----+
               ^  |       +----+                  +----+     | |  ^
               |  |   Provider Edge 1         Provider Edge 2  |  |
               |  |                                            |  |
         Customer |                                            |Customer
         Edge 1   |                                            | Edge 2
                  |                                            |
                  |                                            |
            native service                               native service

                      Figure 1: PWE3 Network Reference Model

   This document discusses scenarios in which a single native service is
   emulated over a Pseudo Wire. Specifically, it discusses how the PEs
   translate PW failures (i.e. failures within PEs or between PEs) to
   error messages of the native service (i.e. between PE and CE)and vice
   versa, in accordance with the guidelines set out in [OAM REQ].



4. PW Failures

   This section describes possible PW failures, ways to detect them and
   consequent actions.


4.1 Failures

   Possible failures that impact PWs are the following.

   . Loss of connectivity between ingress and egress PE

   . Control session failures between ingress and egress PE

   In case of MPLS there are additional failures (see also [ITU-T
   Y.1710]). E.g.

   . PW mislabeling, which could be due to a failure on the ingress PE
     or due to an over-writing of the PW label value somewhere along
     the way

   . Label swapping or LSP mismerge in the PSN network, which could
     result in the termination of a PW at the wrong egress PE.

   . Unintended self-replication (e.g. due to loops or denial-of-
     Service attacks)

4.1.1 Packet Loss

   If PEs use sequence numbers for a specific Pseudo Wire, they have the



Nadeau et al.                Expires July 2004               [Page 4]


Internet Draft            PWE3 OAM MSG MAP           January 26, 2004



   ability to detect packet loss. The question is at which point packet
   loss is so severe that a PW failure should be declared.

   [CONGESTION] discusses possible mechanisms to detect congestion
   between PWs. The translation of packet loss to PW Failure should be
   discussed in the general framework of congestion control and is
   therefore <TBD>.


4.2 Fault Detection

4.2.1 Available Fault Detection Tools

   To detect the failures listed in 4.1, Service Providers have a
   variety of options available:

   PSN Fault Detection Mechanisms:

   For PWE3 over an IP PSN, with L2TP as encapsulation protocol, the
   fault detection mechanisms described in [L2TPv3] apply. Furthermore,
   the tools Ping and Traceroute, based on ICMP Echo Messages (see
   [ICMP] apply.

   For PWE3 over an MPLS PSN, several tools can be used. E.g.: LSP-Ping
   and LSP-Traceroute (as defined in [LSPPING]) and Bi-directional
   Forwarding Detection ([BFD]). Furthermore, if RSVP-TE is used to
   setup the PSN Tunnels between ingress and egress PE, the hello
   protocol can be used to detect loss of connectivity (see [RSVP-TE]).

   PW specific tools:

   [VCCV] describes how LSP-Ping and BFD can be used over individual
   PWs. When used as such, we will refer to them as VCCV-Ping and VCCV-
   BFD respectively.

4.2.2 Tool Applicability

   The discussion below is intended to give some perspective how tools
   mentioned in the previous section can be used to detect failures.

   Observations:

   . Tools like LSP-Ping and BFD can be run periodically or on demand.
     If used for failure detection (as opposed to diagnostic usage),
     they must be run periodically.

   . Control protocol failures (e.g. detected through L2TPÆs Keep-alive
     messages or the Hello messages used in RSVP-TE) can be used to
     detect many network failures. However, control protocol failures
     do not necessarily coincide with data plane failures. Therefore, a



Nadeau et al.                Expires July 2004               [Page 5]


Internet Draft            PWE3 OAM MSG MAP           January 26, 2004



     fault detection mechanism in the data plane is required to protect
     against all potential data plane failures.

   . For PWE3 over an MPLS PSN, it may seem more effective to run a
     fault detection mechanism over a PSN Tunnel instead of over every
     individual PW within that PSN Tunnel. However in case the PSN
     traffic is distributed over Equal Cost Multi Paths (ECMP), it may
     be difficult to guarantee that PSN OAM messages follow the same
     path as a specific PW. A Service Provider might therefore decide
     to focus on fault detection over PWs.

   . In MPLS networks, execution of LSP Ping would detect MPLS label
     errors, since it requests the receiving node to match the label
     with the original FEC that was used in the LSP set up. BFD can
     also be used since it relies on discriminators. A label error
     would result in a mismatch between the expected discriminator and
     the actual discriminator in the BFD control messages.

   . For PWE3 over an MPLS PSN, PEs could detect PSN label errors
     through the execution of LSP-Ping. However, the same can be
     achieved with VCCV-Ping or VCCV-BFD. If, due to a label error in
     the PSN, a PW would be terminated on the wrong egress PE, PEs
     would detect this through the execution of VCCV-Ping and VCCV-BFD.
     In addition, VCCV-ping and VCCV-BFD would detect PW Label errors.


   Based on these observations, it is clear that a Service Provider has
   the disposal of a variety of tools. There are many factors that
   influence which combination of tools best meets its needs.


4.3 Alarm Messages and Consequent Actions

   When a PE detects a PW failure, it SHOULD inform its peer, by using:

   . For PWE3 on MPLS PSN, PW Status messages as defined in [CONTROL].

   . For PWE3 on IP PSN, L2TPv3 messages Stop Control-Connection
     Notification (SCCN) and Call Disconnect Notify (CDN) as defined in
     [L2TPv3]

   Furthermore, in either case, if VCCV-BFD is used, the diagnostic code
   in the VCCV-BFD Control message can be used to exchange alarm
   information.

   In general, PW Status messages or L2TPÆs SCCN and CDN should be used
   to communicate failures. VCCV-BFD alarm indications should only be
   used in specific cases, as explained in 4.6.

   Both PEs will translate the PW alarms to the appropriate failure



Nadeau et al.                Expires July 2004               [Page 6]


Internet Draft            PWE3 OAM MSG MAP           January 26, 2004



   indications on the affected ACs. The exact procedures depend on the
   emulated protocols and will be discussed in the next sections.


4.4 The Use of PW Status

   PW Status messages are used to report the following failures:

   . Failures detected through fault detection mechanisms in the MPLS
     PSN

   . Failures detected through VCCV (except for VCCV-BFD)

   . Failures within the PE that result in an inability to forward
     traffic between ACs and PW

   If the PW failure is related to one forwarding direction only, the PE
   shall either use "PW Receive Fault" or "PW Transmit Fault". In all
   other cases it shall use "PW Not Forwarding".

   Besides reporting PW failures, PW status is used to propagate AC
   failures. When and how to use those messages is dependent on the
   emulated protocol and will be explained in the subsequent paragraphs
   (5.3 and 6.3).


4.5 The Use of L2TP SCCN and CDN

   [L2TPv3] describes the use of SCCN and CDN messages to exchange alarm
   information between PEs. Like PW Status, SCCN and CDN messages shall
   be used to report the following failures:

   . Failures detected through fault detection mechanisms in the IP PSN

   . Failures detected through VCCV (except for VCCV-BFD)

   . Failures within the PE that result in an inability to forward
     traffic between ACs and PW

   In L2TP, the Set-Link-Info (SLI) message is used to convey failures
   on the ACs.



4.6 The Use of BFD Diagnostic Codes

   [BFD] defines a set of diagnostic codes that partially overlap with
   failures that can be communicated through PW Status messages or
   L2TPÆs SCCN and CDN. To avoid ambiguous situations, these messages
   SHOULD be used for all failures that are detected through means other



Nadeau et al.                Expires July 2004               [Page 7]


Internet Draft            PWE3 OAM MSG MAP           January 26, 2004



   than BFD.

   For VCCV-BFD, therefore, only the following diagnostic codes apply:

   0 û- No Diagnostic
   1 û- Control Detection Time Expired
   3 û- Neighbor Signaled Session Down
   7 û- Administratively Down

   [VCCV] states that, when used over PWs, the asynchronous mode of BFD
   should be used. Diagnostic code 2 (Echo Function Failed) does not
   apply to the asynchronous mode, but to the Demand Mode.

   All other BFD diagnostic codes refer to failures that can be
   communicated through PW Status or L2TP SCCN and CDN.

   The VCCV-BFD procedures are as follows:

   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. 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 PE2.

   When a PW is taken administratively down, the PEs will exchange PW
   Status messages with code "Pseudo Wire Not Forwarding" or 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.

   Note: According to [BFD], control messages with an incorrect
   discriminator field must be discarded. However, since such an
   occurrence might be caused by swapped or mismerged LSPs, it would be
   better if a new diagnostic code were introduced to discriminate
   between missing control packets and packets with an incorrect
   discriminator.


4.7 PW Failure Entry and Exit Procedures
   PWs can fail in a single direction or in both directions. PEs SHOULD
   keep track of the status of each individual direction. In other
   words, a PE SHOULD be able to distinguish between the following
   states: "PW UP", "PW Transmit Direction Down", "PW Receive Direction
   Down", "PW Receive and Transmit Down".

   The next two sections discuss under which conditions a PE enters and
   exits these states. To avoid an unnecessarily complicated



Nadeau et al.                Expires July 2004               [Page 8]


Internet Draft            PWE3 OAM MSG MAP           January 26, 2004



   description, only the states "PW UP" and "PW DOWN" are discussed
   without further analysis whether it applies to one or two directions
   of the PW.

4.7.1 PW Down

   A PE will consider a PW down if one of the following occurs

   . It detects a local failure

   . It detects Loss of Connectivity or a Label Error on the PW

   . It receives a message from its peer indicating a PW failure, which
     could be one of the following:

          o PW Status indicating "PW Receive Fault"; "PW Transmit
             Fault"; or "PW not forwarding"

          o An L2TP SCCN or CDN message

          o A BFD Control message with diagnostic code "Neighbor
             Signaled Session Down"

   Note that if the control session between the PEs fails, the PW is
   torn down and needs to be re-established. As a consequence, control
   session failure leads to disappearance of the PW, not to a PW Down
   state.

4.7.2 PW Up

   When a PE determines that all previously existing failures have
   disappeared, it SHOULD send a message to its peer to indicate this.
   E.g. if the original failure was conveyed through a PW Status
   message, the PE should send a PW Status message indicating "PW
   Forwarding"

   When a PE receives a PW Status message indicating "PW Forwarding",
   while it still considers a PW down, and if all previously existing
   failures, if any, have disappeared, it SHOULD respond with a PW
   Status message indicating "PW Forwarding".

   A PE will exit the PW down state when the following conditions are
   true:

   . All failures it had previously detected have disappeared

   . It has received a PW Status message from its peer indicating "PW
     Forwarding".

   [BFD] and [L2TPv3] define the procedures to exit the PW Down state if



Nadeau et al.                Expires July 2004               [Page 9]


Internet Draft            PWE3 OAM MSG MAP           January 26, 2004



   the original failure notification was done through BFD or L2TP
   messages, respectively.

5. Frame Relay Encapsulation

5.1 Frame Relay Management

   The management of Frame Relay Bearer Service (FRBS) connections can
   be accomplished through two distinct methodologies:


   1. Based on ITU-T Q.933 Annex A, Link Integrity Verification
      procedure, where STATUS and STATUS ENQUIRY signaling messages
      are sent using DLCI=0 over a given UNI and NNI physical link.
      [ITU-T Q.933]

   2. Based on FRBS LMI, and similar to ATM ILMI where LMI is
      common in private Frame Relay networks.

      In addition, ITU-T I.620 addresses Frame Relay loopback, but
      the deployment of this standard is relatively limited. [ITU-T
      I.620]

   It is possible to use either, or both, of the above options to manage
   Frame Relay interfaces. This document will refer exclusively to Q.933
   messages.

   The status of any provisioned Frame Relay PVC may be updated through:

   . STATUS messages in response to STATUS ENQUIRY messages, these are
     mandatory.

   . Optional unsolicited STATUS updates independent of STATUS ENQUIRY
     (typically under the control of management system, these updates
     can be sent periodically (continuous monitoring) or only upon
     detection of specific defects based on configuration.


   In Frame Relay, a DLC is either up or down. There is no distinction
   between different directions.


5.2 Mapping PW failures to Frame Relay OAM messages

   In case a PE keeps track of the status of individual Frame Relay PVCs
   (which often, but not necessarily, coincides with the usage of 1-1
   encapsulation mode), the following procedures apply:

   When a PE determines the PW is down it will indicate this on the ACs
   through STATUS messages that indicate that the affected FR PVCs



Nadeau et al.               Expires July 2004               [Page 10]


Internet Draft            PWE3 OAM MSG MAP           January 26, 2004



   linked to that PW are "inactive".

   When the PE determines that the PW is up, it will indicate this on
   the AC through STATUS messages that indicate that the FR PVCs linked
   to that PW are "active".

   In case of pure port mode, STATUS ENQUIRY and STATUS messages are
   transported transparently over the PW. A PW Failure will therefore
   result in timeouts at the Frame Relay devices at one or both sites of
   the emulated interface.


5.3 Frame Relay Attachment Circuit Failures

   As explained in [CONTROL], if a PE detects that a Frame Relay PVC is
   "inactive", as defined in [ITU-T Q933] Annex A.5, it will convey this
   information to its peer. The remote PE SHOULD generate the
   corresponding errors and alarms on the egress Frame Relay PVC

   For PWE3 over MPLS PSN, a PE that detects a failure on its AC shall
   send a PW Status message indicating both "AC Receive Fault" and "AC
   Transmit Fault".

   For PWE3 over IP PSN, a PE that detects a failure on its AC shall
   send an L2TP Set-Link Info (LSI) message with a Circuit Status
   Attribute Value Pair (AVP) indicating "inactive".

6. ATM Encapsulation

6.1 ATM Management

   ATM management and OAM mechanisms are much more evolved than those of
   Frame Relay.  There are five broad management-related categories,
   including fault management (FT), Performance management (PM),
   configuration management (CM), Accounting management (AC), and
   Security management (SM). ITU-T Recommendation I.610 describes the
   functions for the operation and maintenance of the physical layer and
   the ATM layer, that is, management at the bit and cell levels ([ITU-T
   I.610]). Because of its scope, this document will concentrate on ATM
   fault management functions. Fault management functions include the
   following:

      1) Alarm indication signal (AIS)
      2) Remote Defect indication (RDI).
      3) Continuity Check (CC).
      4) Loopback (LB)

   Some of the basic ATM fault management functions are described as
   follows: Alarm indication signal (AIS) sends a message in the same
   direction as that of the signal, to the effect that an error has been



Nadeau et al.               Expires July 2004               [Page 11]


Internet Draft            PWE3 OAM MSG MAP           January 26, 2004



   detected.

   Remote defect indication (RDI) sends a message to the transmitting
   terminal that an error has been detected. RDI is also referred to as
   the far-end reporting failure. Alarms related to the physical layer
   are indicated using path AIS/RDI. Virtual path AIS/RDI and virtual
   channel AIS/RDI are also generated for the ATM layer.

   OAM cells (F4 and F5 cells) are used for the control of virtual paths
   and virtual channels with regard to their performance and
   availability. F4 cells are used to monitor a VPC, F5 cells for a VCC.
   OAM cells in the F4 and F5 flows are used for monitoring a segment of
   the network and end-to-end monitoring. OAM cells in F4 flows have the
   same VPI as that of the connection being monitored. OAM cells in F5
   flows have the same VPI and VCI as that of the connection being
   monitored.  The AIS and RDI messages of the F4 and F5 flows are sent
   to the other network nodes via the VPC or the VCC to which the
   message refers. The type of error and its location can be indicated
   in the OAM cells. Continuity check is another fault management
   function. To check whether a VCC that has been idle for a period of
   time is still functioning, the network elements can send continuity-
   check cells along that VCC.


 6.2 Mapping PW Failures to ATM OAM

   In case a PE keeps track of the status of individual ATM VPCs or
   VCCs, this behavior is specified in [PWEATM]:

   In the VPC case, when a PW Failure is detected, the PE downstream
   from the failure MUST generate F4 AIS on the related ACs. In the VCC
   case, when a PW Failure is detected, the PE downstream from the
   failure SHOULD generate F5 AIS on the related ACs.

   In case of transparent mapping, where the PE does not keep track of
   the status of individual ATM VPCs or VCCs, it is possible that a PE
   does not know which VPCs and/or VCCs are active. In such a case there
   is a need for another fault indication mechanism on the AC. This is
   beyond the scope of this document.


6.3 ATM Attachment Circuit Failures
   When an ingress PE detects a failure on an AC, it SHOULD generate F4
   and/or F5 AIS on the PW towards the egress PE. The far end of the
   affected VC or VP segment will generate RDI, which is transported
   transparently over the PW in the reverse direction.

   As stated in [CONTROL], there MAY exist implementations that do not
   transport OAM cells transparently.




Nadeau et al.               Expires July 2004               [Page 12]


Internet Draft            PWE3 OAM MSG MAP           January 26, 2004



   For PWE3 over MPLS PSN, when an ingress PE detects a failure on an AC
   and it is not able to send OAM cells over the PW, it MUST send a PW
   Status message indicating "AC Receive Fault". On reception of this
   message, the egress PE MUST generate AIS on the related ATM VPCs or
   VCCs.

   The far end of the affected VC or VP segment will generate RDI. When
   the egress PE receives an RDI signal over an AC and it is not able to
   transmit OAM cells, it MUST send a PW Status message indicating "AC
   Transmit Fault". On reception of this message, the ingress PE MUST
   generate RDI cells on the related VPCs and VCCs.

   For PEW3 over IP PSN, when an ingress PE detects a failure on its AC
   and it is not able to send OAM cells over the PW, it MUST send an
   L2TP Set-Link Info (LSI) message with a Circuit Status AVP indicating
   "inactive". On reception of this message, the egress PE MUST generate
   AIS on the related ATM VPCs or VCCs. When the egress PE receives an
   RDI signal over an AC and it is not able to transmit OAM cells, it
   MUST send a L2TP Set-Link Info (LSI) message with a Circuit Status
   AVP indicating "inactive". On reception of this message, the ingress
   PE MUST generate AIS on the related ATM VPCs or VCCs.

    Note: Since the Circuit Status AVP cannot distinguish between forward
   and backward failures, this procedure will result in AIS messages in
   both directions, even if the failure affected only one direction. An
   alternative procedure is the following. When an ingress PE detects a
   failure, it sends an SLI message to its peer AND it generates an RDI
   message on the affected AC in the reverse direction. When the egress
   PE receives RDI from the far end of the affected segment, it will not
   send an SLI message to the ingress PE and ignore the RDI signal.


   In case of transparent mapping, where the PE does not know which VCCs
   and/or VPCs are active, the near-end PE MUST send a PW-STATUS message
   to its peer. How the peer propagates that message on its AC is beyond
   the scope of this document.

7. SONET Encapsulation (CEP)

   [CEP] discusses how Loss of Connectivity and other SONET/SDH protocol
   failures on the PW are translated to alarms on the ACs and vice
   versa. In essence, all fault management procedures are handled
   entirely in the emulated protocol. There is no need for an
   interaction between PW fault management and SONET layer fault
   management.

8. TDM Encapsulation

   <TBD>




Nadeau et al.               Expires July 2004               [Page 13]


Internet Draft            PWE3 OAM MSG MAP           January 26, 2004




9. Ethernet Encapsulation

   At this point in time, Ethernet OAM is not defined. Therefore, the
   procedures for mapping PW failures to Ethernet OAM messages and vice
   versa are currently rudimentary.

   When an ingress PE detects that an Ethernet AC is down (because the
   related ethernet physical interface is down), it SHOULD send a PW
   Status message indicating both "AC Receive Fault" and "AC Transmit
   Fault".

   If an egress PE determines that all ACs on a specific ethernet
   physical interface are affected (either because of ingress AC
   failures or because of PW failures), it MAY propagate these alarms by
   bringing the entire physical interface down.



10. Security Considerations

   The mapping messages described in this document do not change
   the security functions inherent in the actual messages.

11. Acknowledgments

   Hari Rakotoranto, Eric Rosen, Mark Townsley, Michel Khouderchah,
   Bertrand Duvivier, Vanson Lim and Chris  Metz Cisco Systems


12. References


   [BFD]       Katz, D., Ward, D., "Bidirectional Forwarding Detection",
               Internet Draft <draft-katz-ward-bfd-01.txt>, August 2003

   [CEP]       Malis, A., et.al., "SONET/SDH Circuit Emulation over
               Packet (CEP)", Internet Draft <draft-ietf-pwe3-sonet-
               03.txt>, October 2003

   [CONGESTION]Rosen, E., Bryant, S., Davie, B., "PWE3 Congestion
               Control Framework", Internet Draft <draft-rosen-pwe3-
               congestion-00.txt", October 2003

   [CONTROL]   Martini, L., Rosen, E., Smith, T., "Pseudowire Setup and
               Maintenance using LDP", Internet Draft <draft-ietf-pwe3-
               control-protocol-05.txt>, December 2003

   [ICMP]      Postel, J. "Internet Control Message Protocol" RFC 792




Nadeau et al.               Expires July 2004               [Page 14]


Internet Draft            PWE3 OAM MSG MAP           January 26, 2004



   [ITU-T]     Recommendation I.610 "B-ISDN operation and maintenance
               principles and functions", February 1999

   [ITU-T]     Recommendation I.620 "Frame relay operation and
               maintenance principles and functions", October 1996

   [ITU-T]     Recommendation Q.933 " ISDN Digital Subscriber Signalling
               System No. 1 (DSS1) û Signalling specifications for frame
               mode switched and permanent virtual connection control
               and status monitoring" February 2003

   [ITU-T]     Recommendation Y.1710 "Requirements for Operation &
               Maintenance functionality for MPLS networks", November
               2002

   [L2TPv3]    Lau, J., et.al. " Layer Two Tunneling Protocol (Version
               3", Internet Draft <draft-ietf-l2tpext-l2tp-base-11.txt>,
               October 2003

   [LSPPING]   Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow,
               G., Wadhwa, S., Bonica, R., " Detecting MPLS Data Plane
               Failures", Internet Draft < draft-ietf-mpls-lsp-ping-
               04.txt>, October 2003

   [OAM REQ]   T. Nadeau et.al., "OAM Requirements for MPLS Networks",
               Internet Draft <draft-ietf-mpls-oam-requirements-02>,
               June 2003

   [PWEARCH]   Bryant, S., Pate, P., "PWE3 Architecture", Internet
               Draft, < draft-ietf-pwe3-arch-06.txt>, October 2003

   [PWEATM]    Martini, L., et al., "Encapsulation Methods for Transport
               of ATM Cells/Frame Over IP and MPLS Networks", Internet
               Draft <draft-ietf-pwe3-atm-encap-03.txt>, October 2003

   [PWREQ]     Xiao, X., McPherson, D., Pate, P., "Requirements for
               Pseudo Wire Emulation Edge to-Edge (PWE3)", < draft-ietf-
               pwe3-requirements-08.txt>, December 2003

   [RSVP-TE]   Awduche, D., et.al. " RSVP-TE: Extensions to RSVP for LSP
               Tunnels", RFC 3209

   [VCCV]      Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection
               Verification (VCCV)", Internet Draft <draft-ietf-pwe3-
               vccv-01.txt>, October 2003.








Nadeau et al.               Expires July 2004               [Page 15]


Internet Draft            PWE3 OAM MSG MAP           January 26, 2004



13. Intellectual Property Rights Notices

   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.

14. Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights
   Reserved. This document and translations of it may be copied and
   furnished to others, and derivative works that comment on or
   otherwise
   explain it or assist in its implementation may be prepared, copied,
   published and distributed, in whole or in part, without restriction
   of any kind, provided that the above copyright notice and this
   paragraph are included on all such copies and derivative works.
   However, this document itself may not be modified in any way, such
   as by removing the copyright notice or references to the Internet
   Society or other Internet organizations, except as needed for the
   purpose of developing Internet standards in which case the
   procedures for copyrights defined in the Internet 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 INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.



Nadeau et al.               Expires July 2004               [Page 16]


Internet Draft            PWE3 OAM MSG MAP           January 26, 2004




Author's Addresses

   Authors' Addresses

     Thomas D. Nadeau                   Monique Morrow
     Cisco Systems, Inc.                Cisco Systems, Inc.
     250 Apollo Drive                   Glatt-com
     Chelmsford, MA 01824               CH-8301 Glattzentrum
     Email: tnadeau@cisco.com           Switzerland
                                        Email: mmorrow@cisco.com

     Yuichi Ikejiri                     Kenji Kumaki
     NTT Communications Corporation     KDDI Corporation
     1-1-6, Uchisaiwai-cho, Chiyoda-ku  KDDI Bldg. 2-3-2
     Tokyo 100-8019                     Nishishinjuku, Shinjuku-ku
     JAPAN                              Tokyo 163-8003
     Email: y.ikejiri@ntt.com           JAPAN
                                        E-mail : ke-kumaki@kddi.com

     Satoru Matsushima                  Peter B. Busschbach
     Japan Telecom                      Lucent Technologies
     JAPAN                              67 Whippany Road
     Email: satoru@ft.solteria.net      Whippany, NJ, 07981
                                        Email: busschbach@lucent.com




























Nadeau et al.               Expires July 2004               [Page 17]