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

Versions: 00 01 02 03 04                                                
Network Working Group                      Thomas D. Nadeau
Internet Draft                               Monique Morrow
Expires: October 2003                   Cisco Systems, Inc.

                                                 April 2003




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



Status of this Memo

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

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.
  Copyright (C) The Internet Society (2001). All rights
reserved.



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

Abstract
1. Scope....................................................2
2. Terminology..............................................2
3. Introduction.............................................3
4. Overview of ATM and Frame Relay Management functions.....7
5. Like-to-Like Scenarios..................................10
6. L2TPv3 Message Mapping..................................11
7. Ethernet Interworking Mapping...........................11



Nadeau et al.              Expires October 2003              [Page 1]


Internet Draft       PWE3 OAM Message Mapping       April 1, 2003



8. VPLS....................................................11
9. Security Considerations.................................11
10. Intellectual Property Rights Notices...................14
11. Full Copyright Statement...............................14



1. Scope

L2TPV3 OAM message mapping will be added to this document in a
future version. OAM message mapping related to Ethernet
interworking will be added to this document in a future
version.


2. Terminology

AIS  Alarm Indication Signal
AOM  Administration, Operation and Maintenance
CC   Continuity Check
CE   Customer Edge
CPCS  Common Part Convergence Sublayer
FRBS  Frame Relay Bearer Service
IWF   Interworking Function
LB    Loopback
NE   Network Element
OAM  Operations and Maintenance
PE   Provider Edge
PW   Pseudowire
PSN  Packet Service Node
RDI  Remote Defect Indicator
SDU  Service Data Unit
VCC  Virtual Channel Connection
VPC  Virtual Path Connection



3. Introduction


This document describes the mapping to/from of faults detected
in pseudo-wires carrying emulated services to OAM messages
native to those services. This includes multiple networks
involving ATM, MPLS, IP and Frame-Relay either in a like-to-
like (ATM-MPLS-ATM) or an interworking configuration (i.e: FR-
MPLS-ATM). While management interworking is well defined for
ATM/Frame Relay [FRF.8, ITU-T I.555], the mapping of PW
failures to the equivalent ATM/Frame Relay OAM messages when
pseudo wires are used to interconnect these technologies is
not well defined.



Nadeau et al.              Expires October 2003              [Page 2]


Internet Draft       PWE3 OAM Message Mapping       April 1, 2003




For example, in the case of ATM like-to-like pseudowire, the
transport of OAM cells depends on the defined modes, but
interworking with packet services node failures is not
defined. A summary of these modes and OAM transport
capabilities will be shown TBD.

Since local OAM termination interpretation and reporting is in
some cases optional, certain failures may be detected by the
customer edge without the knowledge of the carrier.


                 |<--ATM-->|      |<-MPLS-->|     |<-ATM->|
                  |        |      |         |     |       |
               ATMv        v ATM  v         v ATM v       V
 ATM           UNI           UNI              UNI        UNI
+----+    |  |        | NNI  |         | NNI |       |  |   +----+
|ATM |----|..................|         |................|---|ATM |
| CPE|    |  |        |      |         |     |       |  |   |CPE |
|    |----|..................|         |................|---|    |
+----+    |  |        |      |         |     |       |  |   +----+
Customer^                                                 ^Customer
 Edge 1|          <-ATMoMPLS->                            | Edge 2
       |<-----------ATM PVC----------->|<-----ATM PVC------>|


              Figure 1   ATM Like-to-Like over MPLS


The mapping of MPLS data-plane failures can also be useful in
some deployment scenarios where the provider edge terminates
OAM messages and no means are defined to transport them across
the pseudowire, management interworking will be lost. Such an
application exists when transporting services over MPLS in an
any-to-any interworking configuration. This involves two
provider edge devices interconnected by a pseudowire using
MPLS as a transport. One provider edge might terminate a Frame
Relay service and another provider edge terminates an ATM
service. In this case Frame Relay and ATM OAM is terminated
locally without transport over the pseudo-wire. Thus a data-
plane failure in the pseudowire is neither detected nor
reported to the ATM/Frame Relay networks which view the pseudo-
wire as if it were a native interface. For more details on
this application please see [SAJASSI]. Even though this
application has some merits as described in the aforementioned
draft, the lack of management interworking is a major
drawback. However, with the introduction of LSP ping
[LSPPING], VCCV [VCCV] and additional techniques described
herein, it is possible to support management interworking at
same level as described in [FRF 8.1].



Nadeau et al.              Expires October 2003              [Page 3]


Internet Draft       PWE3 OAM Message Mapping       April 1, 2003




The following figures are provided to illustrate the above
point.


               |<--FR-->|                    |<-ATM->|
               |        |                    |       |
            FR v        v FR     IWF     ATM v       v ATM
            UNI           UNI  +----+    UNI           UNI
   +----+   |  |        | NNI  |    |    NNI |       |  |    +---+
   | FR |---|......... ........|    |...................|---|ATM |
   | CPE|   |  |        |      |    |        |       |  |   |CPE |
   |    |---|..................|    |...................|---|    |
   +----+   |  |        |      |    |        |       |  |   +----+
Customer^                      +----+                      ^Customer
  Edge 1|                                                   | Edge 2
        |<---------FR PVC-------->| |<------- ATM PVC------>|
        |                         | |                       |
        |<-Q933-><-Q933-> <-Q933->| |<- F5/F4 end to end -->|
        |            <------------| |---------------------->|
        |        Interworking Q933| |Interworking OAM cells |
        |                         | |                       |
        |                         | |             --------->|
        |                         | |               AIS     |
        |                         | |<----------------------|
        |                         | |       RDI             |
        |                         | |<--------------------->|
        |                         | |       CC              |
        |                         | |                       |
        |------------------------>| |---------------------->|
        |<------------------------v |<----------------------v
           Loopback (ITU-T I.620)              Loopback

   Figure 2: Basic Frame Relay/ATM interworking without
             IP/MPLS


Frame Relay/ATM IWF is performed at one of the provider edges,
and management interworking is transported/extended across the
Frame Relay pseudowire.  Figure 3 is an example of Frame Relay
extended across the MPLS network.

             |<--FR-->|      |<-MPLS-->|     |<-ATM->|
             |        |      |         |     |       |
          FR V        v FR   v         v ATM v       V ATM
          UNI           UNI              UNI           UNI
 +----+   |  |        | NNI  |         | NNI |       |  |   +----+
 | FR |---|......... ........|         |................|---|ATM |
 | CPE|   |  |        |      |         |     |       |  |   |CPE |
 |    |---|..................|         |................|---|    |



Nadeau et al.              Expires October 2003              [Page 4]


Internet Draft       PWE3 OAM Message Mapping       April 1, 2003



 +----+   |  |        |      |         |     |       |  |   +----+
 Customer^                                                  ^Customer
 Edge1|                       <-FRoMPLS->                  |Edge2
      |<-----------FR PVC------------>|<-----ATM PVC------>|
             Figure 3 FR/ATM interworking with IP


Frame Relay/ATM Interworking function is performed at one of
the provider edges and management interworking is transported
and extended across the Frame Relay pseudowire. Figure 4
depicts ATM extended across the MPLS network

            |<--FR-->|    |<-MPLS->|     |<-ATM->|
            |        |    |        |     |       |
         FR V        v FR   v       v ATM v       V ATM
         UNI           UNI            UNI           UNI
+----+    |        | NNI  |       | NNI |        | |   +----+
| FR |-|......... ........|       |................|---|ATM |
| CPE| |  |        |      |       |     |        | |   |CPE |
|    |-|..................|       |................|---|    |
+----+ |  |        |      |       |     |        | |   +----+
Customer^                                              ^Customer
  Edge 1 |               <ATMoMPLS->                   | Edge 2
         |<-----------FR PVC--->|<--------ATM PVC----->|

        Figure 4: Frame Relay/ATM Interworking with IP/MPLS


Frame Relay/ATM Interworking function is performed at one of
the provider edges and management interworking is transported
and extended across the ATM pseudowire.

When extending Frame Relay or ATM across the MPLS network, the
mapping of OAM functionality between ATM and Frame Relay is
the same as in the basic Frame Relay/ATM interworking without
ATM case. Nevertheless, in the MPLS cloud, when Frame Relay
(resp. ATM) extends across the MPLS network it is necessary to
define Frame Relay OAM (resp. ATM OAM) mapping to MPLS OAM on
this "segment".
In Figure 5 MPLS AOM is performed by MPLS LSP PING and Tunnel
trace functions.


                  |<FR>|      |<-MPLS->|     |<ATM>|
                  |    |      |        |     |     |
              FR  v    v  FR  v        v ATM v     vATM
              UNI         UNI            UNI        UNI
+---+   |  |      | NNI|         | NNI |     |     |   +----+
|FR |---|..............|         |.................|---|ATM |
|CPE|   |  |      |    |         |     |     |     |   |CPE |



Nadeau et al.              Expires October 2003              [Page 5]


Internet Draft       PWE3 OAM Message Mapping       April 1, 2003



|   |---|..............|         |.................|---|    |
+---+   |  |      |    |         |     |     |     |   +----+
 Cust^                                                 ^Cust
Edge1|                                                 |Edge2
     |<----FR PVC----> |<MPLS>   |<----ATM PVC-------->|
     |                 |         |                     |
     |<Q933,Q933,Q933> |<MPLSOAM>|< F5/F4 end to end>  |
     |   <------------ |         |-------------------->|
     |InterworkingQ933 |         |Interworking OAM cell|
     |                 |         |                     |
     |                 |         |         --------->  |
     |                 |         |               AIS   |
     |                 |         |<--------------------|
     |                 |         |       RDI           |
     |                 |         |<------------------->|
     |                 |         |       CC            |
     |                 |         |                     |
     |---------------> |         |-------------------->|
     |<--------------- |         |<--------------------|
    Loopback (ITU-T I.620)               Loopback

           Figure 5: FR/ATM interworking with IP/MPLS


4. Overview of ATM and Frame Relay Management functions


4.1.  Frame Relay Management

The management of Frame Relay Bearer Service (FRBS)[ITU-T
I.555] 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. However, from the perspective
of ATM/Frame Relay interworking, Q.933 messages are used and
mapped to the corresponding ATM OAM when possible.




Nadeau et al.              Expires October 2003              [Page 6]


Internet Draft       PWE3 OAM Message Mapping       April 1, 2003



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.

Note that in contrast to ATM, monitoring the status of Frame
Relay PVC end-to-end requires coordination with management
systems since Q.933 messages are link-to-link between nodes.
Frame Relay/ATM management interworking is defined in FRF.8.1
and ITU-T I.555


4.2.  ATM management

ATM management and AOM 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. The document scope
is to focus on fault management interworking between Frame
Relay, ATM and MPLS, we will therefore concentrate on ATM
fault management functions. [ITU-T I.610] 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 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



Nadeau et al.              Expires October 2003              [Page 7]


Internet Draft       PWE3 OAM Message Mapping       April 1, 2003



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

Please note that in Frame Relay/ATM service interworking
specified in FRF.8.1 and ITU-T I.555 only some of the above
functions are mapped, but not loopback. Other functions are
not simple to map due to lack of equivalent procedures and
functions.


4.3.  Mapping of Management Messages

In general, fault management interworking between Frame Relay
and ATM may be summarized as down to STATUS "up" or "down" on
the frame relay side and AIS on the ATM side. Although on the
ATM side fault management and localization is much more
advanced than that of Frame Relay, at the service interworking
level the limitation is the least common denominator (FR). In
cases where OAM is terminated at the PEs and the PW is not
capable of transporting OAM VCCV[VCCV] proposes a mechanism
that supports this function.


4.4.  Mapping of MPLS data-plane failures

MPLS LSP Ping and VCCV failure handling and the associated OAM
messages at both ATM and Frame Relay network sides is
illustrated below. Since MPLS ping detects various kinds of
data-plane problems, it is assumed that the L2-circuit-ID
option would be used to detect failure of the PW before any
drastic measure is taken (Vc label withdraw). Also it is
recommended to try multiple LSP pings before tearing down all
the associated PW and impacting all the associated attachment
circuits. Ideally the number of ping failures that triggers
the PW break up would be user configured (1-x). Once the
failure is confirmed and the associated PW are torn down, the
PE attached to the ATM network must generate AIS on all the
corresponding PVCs at a nominal rate of one AIS/sec/Vc. The PE



Nadeau et al.              Expires October 2003              [Page 8]


Internet Draft       PWE3 OAM Message Mapping       April 1, 2003



that is attached the Frame Relay network can optionally send
asynchronous STATUS messages indicating inactive state of all
the corresponding DLCIs, or STATUS messages could be sent as
response to STATUS ENQUIRY messages.

Please note that even thought the fault condition is, in this
case, external to the ATM and Frame Relay networks, this will
not be known to the downstream ATM or FR NEs. This ambiguity
is also present in the case of ATM/Frame Relay interworking
[FRF.8.1, I.555] without MPLS.

There are two possible mechanisms to resolve this issue:

   1) Use optional codepoint in the defect location or defect
      type fields in the AIS/RDI OAM cells to indicate external
      defect source.

   2) Use new type of interworking OAM cells.


4.5.  Mapping of ATM PVC management procedures

In this section it is assumed that both Frame Relay and MPLS
networks are in working order, and the problem is initiated
from the ATM network.
The fault management functions considered include:
1) AIS/RDI OAM cells
2) End-to-end CC cells, if this option is supported.
3) Loopback cells, under System Management control.

For items 1 and 2, these fault conditions should trigger PW
tear down without the involvement of MPLS ping.

However, Loopback may be used to initiate automatic MPLS Ping.

Each of the above conditions is discussed below.


4.6.  Mapping of AIS/RDI

ATM network faults leading to AIS/RDI cells being received at
the PE's ATM interface will result in the tear down of the
associated PWs.
It is recommended to allow user configurable trigger (1-X,
AIS/RDI cells) before PW is torn down to prevent transient
failures from tearing down the PW. The ATM PVC is considered
inactive "down" when it is not deleted from the ATM network
and ASI/RDI cells are received.

In order to take the appropriate action at the Frame Relay



Nadeau et al.              Expires October 2003              [Page 9]


Internet Draft       PWE3 OAM Message Mapping       April 1, 2003



side, the tear down of the PW is used as the trigger. The PE
connected to Frame Relay network must send Active bit = 0 in
the full status report for the corresponding Frame Relay PVCs
if configured. Optionally this status update could use the
async status message for the corresponding FR PVCs.

Recovery from the AIS state is initiated by one of the
following conditions:

  1. No AIS/RDI Cells are received for 2.5+ - 0.5 sec, while no
     user-data or CC cells are received during the period. [ITU-T,
     I.610]
  2. User-data cells are received.
  3. CC cells are received.

After recovery on the ATM side, the following steps are taken:

Re-establish PW by the PE at the ATM side.

PE at the FR side must send "active" STATUS messages for the
corresponding DLCIs.


4.7.  Mapping of Continuity Check

Continuity check, if supported, can be mapped as described in
the AIS/RDI case. In this case, the absence of CC cells or
user data cells for the specified period (3.5 + - 0.5 sec
nominally) indicates the ATM PVC is "down" [ITU-T I.610].


4.8.  Mapping of Loopback

Loopback procedure is typically initiated under the control of
NE Management system or the end user management system for in-
service or pre-service connectivity verification and fault
localization. The ATM PVC is considered inactive if loopback
test is unsuccessful, i.e. cells are not received back to the
originating point within 5 seconds (nominally). The mapping of
LB tests on the ATM side to Frame Relay side is not typically
done since I.620 (Frame Relay loopback) is not widely
deployed. However, in FRF.8.1, unsuccessful LB tests are
mapped into STATUS inactive for the corresponding FR DLCI(s).
Thus, similar functionality can be achieved, if the PE on the
ATM side tears down the associated PW, which will result in
similar treatment to the AIS/RDI or CC faults.[ITU-T I.620,
FRF.8.1]
Some potential improvements can be achieved if ATM LB test
happens to be successful, but the PE at the ATM side uses the
LB test to trigger automatic MPLS ping. In this case, if we



Nadeau et al.              Expires October 2003             [Page 10]


Internet Draft       PWE3 OAM Message Mapping       April 1, 2003



assume that the ATM network is functional but there is a
problem in the MPLS data-plane, then invoking ATM LB test will
result in successful LB, but the PE at the ATM side will
generate AIS if the MPLS ping fails.

2.5  Mapping of Frame Relay PVC management procedures

This is the simplest case, since only STATUS "up" or "down"
are relevant.


5. Like-to-Like Scenarios

In the case of like-to-like PWs, MPLS ping can also be useful
in detecting and reporting problems. The following sections
will use ATMoMPLS as an example. Even though mechanisms for
transporting ATM AOM cells over the PW are well defined, as
described in the introduction, the support of such function is
optional. If OAM transport is supported and enabled, MPLS data-
plane failures may not be detected in time unless CC or
loopback OAM cells are used.  Thus, MPLS ping can be very
useful, especially if the PE routers do not support transport
of OAM.


5.1.  Mapping of MPLS Data Plane Failures

MPLS LSP Ping and VCCV failure can be used to generate the
appropriate alarms at the edges as shown below. In this case,
it is assumed that either the PEs do not support OAM transport
or that they do, but CC/LB is not enabled. Otherwise, if the
PEs support OAM transport and CC is enabled, it is likely that
MPLS data-plane failure will be detected within 3.5 - 0.5 sec
(CC timeout).


5.2.  Mapping of Continuity Check

If PEs do not support transport of OAM cells, and segment CC
is supported/enabled but terminated at the PEs, then MPLS data-
plane failure can be detected by MPLS ping. Ping failure
should be used to trigger AIS States at the two PEs. i.e.
generate AIS on the corresponding PW PVCs at a rate of 1 AIS
per sec per VC.


5.3.  Mapping of Loopback
As described in section 2.4.3 some potential improvements can
be achieved if ATM segment LB tests happen to be successful,
but the PEs use the ATM LB test to trigger automatic MPLS



Nadeau et al.              Expires October 2003             [Page 11]


Internet Draft       PWE3 OAM Message Mapping       April 1, 2003



ping. In this case, if we assume that the ATM network is
functional but there is a problem in the MPLS data-plane, then
invoking ATM segment LB test will result in successful LB, but
the PE at the ATM side will generate AIS if the MPLS ping
fails.

6. L2TPv3 Message Mapping
[TBD]


7. Ethernet Interworking Mapping
[TBD]


8. VPLS
[TBD]


9. Security Considerations

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

10. Acknowledgments

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


11. References

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

[PWREQ]    Xiao, X., McPherson, D., Pate, P., Gill, V.,
           Kompella, K., Nadeau, T., White, C., "Requirements
           for Pseudo Wire Emulation
           Edge-to-Edge (PWE3)", <draft-ietf-pwe3-requirements-
           02.txt>, November 2001.

[PWE3FW]   Prayson Pate, et al., Internet draft, Framework for
           Pseudo Wire Emulation Edge-to-Edge (PWE3), draft-
           ietf-pwe3-framework-01.txt, work in progress.

[PWEARCH]  Bryant, S., Pate, P., Johnson, T., Kompella, K.,
           Malis, A., McPherson, D., Nadeau, T., So, T.,



Nadeau et al.              Expires October 2003             [Page 12]


Internet Draft       PWE3 OAM Message Mapping       April 1, 2003



           Townsley, W., Systems, White., C., Wood, L.,
           Xiao, X., Internet draft, Framework for
           Pseudo Wire Emulation Edge-to-Edge (PWE3), draft-
           ietf-pwe3-framework-01.txt, work in progress.

[L2SIG]    Rosen, E., LDP-based Signaling for L2VPNs,
           Internet Draft <draft-rosen-ppvpn-l2-signaling-02.txt>,
           September 2002.

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

[GTTP]     Bonica, R., Kompella, K., Meyer, D., "Generic
           Tunnel Tracing
           Protocol (GTTP) Specification", Internet Draft
           <draft-bonica-tunproto-01.txt>, April, 2003

[FRF 8.1]  Frame Relay Forum, Frame Relay / ATM PVC Service
           Interworking Implementation Agreement,February 2000

[ITU-T]    "Draft Recommendation Y.17fw" (MPLS Management
           Framework), July 2002.

[ITU-T]    "Frame Relay Bearer Service Interworking," I.555,
           September 2997.

[ITU-T],   "Frame Relay Operations Principles and Functions, "
           I.620, October, 1996.

[ITU-T]    Q.933, ISDN Digital Subscriber Signalling System
           No. 1 (DSS 1) - Signalling specification for
           frame mode basic call control,
           November 1995.

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

[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-00.txt>, October 2002

[MPLSOAMREQS] Nadeau, T., et al, OAM Requirements for MPLS
              Networks, Internet Draft <draft-nadeau-ietf-oam-
              requirements-00.txt>, February 2003.

[PWE3CONTROL] L.Martini et al., Transport of Layer 2 Frames



Nadeau et al.              Expires October 2003             [Page 13]


Internet Draft       PWE3 OAM Message Mapping       April 1, 2003



              over MPLS, Internet Draft, <draft-ietf-pwe3-control-
              protocol-01.txt>, May 2003

[PPVPNFW] Callon, R., Suzuki, M., Gleeson, B., Malis, A.,
          Muthukrishnan, K., Rosen, E., Sargor, C., and J.
          Yu, "A Framework for Provider Provisioned Virtual
          Private Networks", Internet Draft
          <draft-ietf-ppvpn-framework-01.txt>, July 2001.

[SAJASSI]  A.Sajassi et al., "L2VPN Interworking," Internet
           Draft <draft-sajassi-l2vpn-interworking-00.txt>,
           November 2002.

[RFC3031]  Rosen, E., Viswanathan, A., and R. Callon,
           "Multiprotocol Label Switching Architecture",
           RFC 3031, January 2001.



  Author's Addresses

  Thomas D. Nadeau
  Cisco Systems, Inc.
  250 Apollo Drive
  Chelmsford, MA 01824
  Email: tnadeau@cisco.com

  Monique Morrow
  Cisco Systems, Inc.
  Glatt-com
  CH-8301 Glattzentrum
  Switzerland
  Email: mmorrow@cisco.com


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



Nadeau et al.              Expires October 2003             [Page 14]


Internet Draft       PWE3 OAM Message Mapping       April 1, 2003




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.

13.   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 October 2003             [Page 15]


Internet Draft       PWE3 OAM Message Mapping       April 1, 2003

























































Nadeau et al.              Expires October 2003             [Page 16]