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]