wdiff draft-ietf-pwe3-requirements-00.txt draft-ietf-pwe3-requirements-01.txt

Internet Draft XiPeng Xiao
Document: draft-ietf-pwe3-requirements-00.txt draft-ietf-pwe3-requirements-01.txt Photuris Inc.
Expires: November 17, 2001 January 2002 Danny McPherson
Amber Networks
Prayson Pate
Overture Networks, Inc.
Craig White
Level 3 Communications, LLC.
Kireeti Kompella
Juniper Networks, Inc.
Vijay Gill
Metromedia Fiber Network, Inc.
Thomas D. Nadeau
Cisco Systems, Inc.

Requirements for
Pseudo Wire Pseudo-Wre Emulation Edge-to-Edge (PWE3)
draft-ietf-pwe3-requirements-00.txt
draft-ietf-pwe3-requirements-01.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document describes generic requirements for Pseudo-Wire
Emulation Edge to Edge. Edge (PWE3). It provides guidelines for other
working group documents that will define mechanisms for providing
pseudo-wire emulation of specific services such as Ethernet, PPP, (Cisco) HDLC, ATM,
Frame Relay Relay, TDM, and TDM. MPLS. It should be noted that the PWE3 Working
Group (WG) (PWE3 WG) standardizes mechanisms that can be used to provide
pseudo-wire emulation
PWE3 services, but not the services themselves.

Table of Contents

1 Introduction ................................................. 4
1.1 Reference Model of Pseudo-Wire Emulation Edge to Edge
(PWE3) .................................................... PWE3 .................................... 4
1.2 Terminology ................................................ 5
2 PDU Encapsulation ............................................ 6
2.1 Conveyance of Necessary L2/L1 Header Information ........... 6 7
2.2 Location of the Pseudo-Wire Header ......................... 6
2.3 PDU Length ................................................. 6
2.4 7
2.3 Encapsulation of Signaling Control Messages of the Native Services .................................................. 7
2.5 Timing Information .........................................
........................................................... 7
2.6
2.4 Support for Circuit Multiplexing ........................... 7
2.7
2.5 Packet Ordering ............................................ 7
3
2.6 Packet Transport ............................................. Duplication ......................................... 7
3 Carrying the PW PDUs over a Packet-Switched Network .......... 8
3.1 Setup of Pseudo-Wires ...................................... 7 8
3.2 Pseudo-Wire MTU ............................................ 8
3.3 Transport of Signaling Carrying Control Messages of the Native Services ..... ........... 8
3.4 Transport Efficiency ....................................... PSN Tunnel Header Overhead ................................. 9
4 Faithfulness of Emulated Services ............................ 9
4.1 Characteristics of an Emulated Service ..................... 9
4.2 Service Quality of Emulated Services ....................... 10
4.3 Signaling of Native Services ............................... 10
5 Maintenance of Emulated Services ............................. 10
5.1 Signaling Keep-alive ................................................. 10
5.2 Status Monitoring .......................................... 10
5.3 Notification of Status Changes of an Emulated Service ......... 10
5.1.1 ............................. 11
5.3.1 Up/Down Notification ..................................... 10
5.1.2 11
5.3.2 Misconnection and Payload Mistype ........................ 11
5.3.3 Packet Loss and/or Loss, Corruption, and Out-of-order Delivery ................. ....... 11
5.1.3
5.3.4 Other Status Signaling ................................... Notification ................................ 11
5.1.4
5.3.5 Collective Status Signaling .............................. Notification ........................... 11
5.2
5.4 Clock Recovery ............................................. 12
6 Management of Emulated Services .............................. 12
6.1 MIB ........................................................ MIBs ....................................................... 12
6.2 General MIB Requirements ................................... 12
6.3 Configuration and Provisioning ............................. 13
6.4 Performance Monitoring ..................................... 13
6.5 Fault Management and Notifications ......................... 13
6.6 Pseudo-Wire Traceroute ..................................... 12 13
7 Scalability .................................................. 12 13
8 Other Generic Requirements ................................... 13 14
8.1 RFC 2914 Conformance ....................................... 14
9 Non-Requirements ............................................. 14
10 Quality of Service (QoS) Considerations ..................... 14 15
11 Inter-domain Pseudo-Wires ................................... 15
12 Security Considerations ..................................... 15
12.1 Security Considerations for the Signaling/Control
Channel ................................................... 15
12.2 Security Considerations for the Encapsulated PW PDUs ......... ................... 15
13 Deployment Considerations ................................... 15 16
14 Acknowledgments ............................................. 15 16
15 References .................................................. 15 16
16 Authors' Addresses .......................................... 16 17
17 Full Copyright Section ...................................... 18 19
1. Introduction

1.1. Reference Model of Pseudo-Wire Emulation Edge to Edge (PWE3) PWE3

To provide pseudo-wire emulation, emulation (PWE), two pseudo-wire end-services
(PWESs) of the same type are first configured between each service endpoint (SE) customer
edge (CE) device and the corresponding PWE3 Edge provider edge (PE) device (See
Figure 1). An end-service A PWES is either:
- an Ethernet link between two ports or two VLANs, or
- a PPP link, or
- a (Cisco) HDLC link, VLAN link between two ports, or
- an ATM VC or VP, or
- a Frame Relay VC, or
- a TDM circuit. circuit, or
- an MPLS LSP.
A connection is then set up between the two PEs to connect these two
end-services.
PWESs. This connection is called a pseudo-wire (PW) in the PWE3
context. During the setup of a pseudo-wire, PW, the two pseudo-wire
endpoints PEs will be configured or
will automatically exchange information about the service to be
emulated so that later they know how to handle process packets coming from
the other
end of the pseudo-wire. end. After the pseudo-wire PW is set up, layer-2 (e.g. Ethernet, ATM and ATM,
Frame Relay) Relay and MPLS) or layer-1 (e.g. SONET/SDH) PDUs
of frames from an end-service a PWES
are encapsulated at the pseudo-wire PW ingress. The encapsulated PDUs are then transported
sent over the pseudo-
wire PW to the egress, where L2 or L1 header information is headers are re-
constructed and the resulted frames are forwarded in their native
format to the other end-service.

|<--------- pseudo-wire -------->|
end- CE.

|<------- Pseudo Wire ------>|
| |
| |<-- PSN Tunnel -->| | end-
PW V V V V PW
End Service+----+ +----+ End Service
+-----+ service +------+ +------+ service | | PE1|==================| PE2| | +-----+
| SE1 |---------| PE1 |..................| PE2 |---------| SE2 |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ +------+ +------+ | | |==================| | | +-----+
service PW endpoint 1 PW endpoint 2 service
endpoint
^ +----+ +----+ | ^
| Provider Edge 1 endpoint Provider Edge 2 |
|
|<---------------- emulated service |
|<-------------- Emulated Service ---------------->|

Customer Customer
Edge 1 Edge 2

Figure 1: Pseudo-Wire PWE3 Reference Model

Different carriers may choose different types of pseudo-wires. For
example, carriers may choose to use GRE tunnels [GRE], L2TP tunnels
[L2TP], or MPLS LSPs [MPLS] as pseudo-wires.

This document does not assume that a particular type of pseudo-wires PWs is used.
Instead, it describes generic requirements that apply to all pseudo-wires, PWs, for
all services including Ethernet, PPP, (Cisco) HDLC, ATM, Frame Relay Relay, TDM and TDM. MPLS.

This document is not an introductory document. Readers are assumed For an architecture
overview of PWE3, readers should refer to
be familiar with the PWE3 framework document [PATE], especially the
architecture assumptions stated in that document.
[PATE].

1.2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.

Below are the definitions for the terms used throughout the document.

End-Service An End-Service

Packet Switched Network
A Packet Switched Network (PSN) is either an Ethernet link
between two ports or two VLANs, or a PPP
link, or a (Cisco) HDLC link, or an ATM VC or
VP, or a Frame Relay VC, network
using IP, MPLS or a TDM circuit.

Pseudo-Wire L2TP as the unit of
switching.

Pseudo Wire Emulation Pseudo-Wire Edge to Edge
Pseudo Wire Emulation is an approach Edge to
emulate Edge (PWE3) is a
mechanism that emulates the essential
attributes of a service
over a packet network so that two remote
end-services appear directly connected by (such as a
wire.

Emulated Service An Emulated Service is T1 leased
line or Frame Relay) over a service that is
provided via pseudo-wire emulation.

Service Endpoint PSN.

Customer Edge A Service Endpoint (SE) Customer Edge (CE) is a device where one end
of an emulated service originates and
terminates.

Pseudo-Wire The CE is not aware that it is
using an emulated service rather than a "real"
service.

Provider Edge A Pseudo-Wire Provider Edge (PE) is a device that provides
PWE3 to a CE.

Pseudo Wire A Pseudo Wire (PW) is a connection between two
end-services.

Pseudo-Wire Endpoint
PEs carried over a PSN. The PE provides the
adaptation between the CE and the PW.

Pseudo Wire PDU A Pseudo-Wire Endpoint Pseudo Wire PDU (PW PDU) is a device where one
end PDU sent on the
PW that contains all of the data and control
information necessary to provide the desired
service.

PSN Tunnel A PSN Tunnel is a pseudo-wire terminates. tunnel inside which multiple
PWs can be nested so that they are transparent
to core network devices.

Path-oriented PW A Path-oriented Pseudo-Wire PW is a pseudo-wire
Pseudo-Wire PW for which core the
network devices of the underlying PSN must
maintain state information, for example, an MPLS LSP. information.

Non-path-oriented PW A Non-path-oriented Pseudo-Wire PW is a
Pseudo-Wire pseudo-wire PW for which core the
network devices of the underlying PSN need not
maintain state information, information.

Service Interworking In Service Interworking, the IWF (Interworking
Function) between two dissimilar protocols
(e.g., ATM & MPLS, Frame Relay & ATM, ATM & IP,
ATM & L2TP, etc.) terminates the protocol used
in one network and translates (i.e. maps) its
Protocol Control Information (PCI) to the PCI
of the protocol used in other network for
example, a L2TP tunnel.

Transport Tunnel A Transport Tunnel is a tunnel inside which
multiple pseudo-wires can User,
Control and Management Plane functions to the
extent possible. In general, since not all
functions may be nested so that
they supported in one or other of
the networks, the translation of PCI may be
partial or non-existent. However, this should
not result in any loss of user data since the
payload is not affected by PCI conversion at
the service interworking IWF.

Network Interworking In Network Interworking, the PCI (Protocol
Control Information) of the protocol and the
payload information used in two similar
networks are transparent transferred transparently by an
IWF of the PE across the PSN. Typically the IWF
of the PE encapsulates the information which is
transmitted by means of an adaptation function
and transfers it transparently to core network devices. the other
network.

2. PDU Encapsulation

Every pseudo-wire edge device PE MUST provide service interfaces to use common service-specific service-
specific techniques for encapsulating PDUs. PDUs from the PWESs. It should
be noted that the PDUs to be encapsulated may or may not contain L2
or L1 header information. This is service specific. Every PWE3
service MUST specify what a the PDU is.

A pseudo-wire header must contain sufficient but not excessive
information so that the other end of the pseudo-wire, aided with
information obtained during the pseudo-wire setup process, knows
exactly how to handle the encapsulated PDUs. A pseudo-wire PW header consists of all the header fields in an encapsulated a PW PDU that are
used by the pseudo-wire PW egress to determine how to handled process the PDU. The header
that is used for transporting sending the encapsulated PW PDUs from the pseudo-wire PW ingress to the
egress (e.g. the tunnel label in
[MART2]) [MARTINI2]) is not considered as
part of the pseudo-wire PW header. It is called transport header instead. It should be noted that transport
headers are totally different from transport-layer headers (e.g.
TCP/UDP headers). PSN tunnel header.

Specific requirements on PDU encapsulation for a PWE3 approach are
listed below.

2.1. Conveyance of Necessary L2/L1 Header Information

Sometimes the

The egress of a pseudo-wire PW needs some information, e.g. which native service
the PW PDUs belong to, and possibly some L2 or L1 header
information information,
in order to know how to process the PDUs received. A PWE3 approach SHOULD
MUST provide some mechanism (e.g. using one or more
control words) for conveying such L2/L1 header information from the
pseudo-wire
PW ingress to the egress. The use of these mechanisms can It should be
REQUIRED or OPTIONAL, depending on services.

2.2. Location of the Pseudo-Wire Header

A pseudo-wire header MUST noted that not all such
information must be between carried in the PDU and PW header of the transport
header. This is necessary for PW PDUs. Some
information (e.g. service type of a PW) can be stored as state
information at the pseudo-wire egress to locate the
pseudo-wire header, and to process the PDU.

2.3. during PW setup.

2.2. PDU Length

A PWE3 approach MUST accommodate variable length PDUs, if variable
length PDUs are allowed by the native service. For example, a PWE3
approach for Frame Relay MUST accommodate variable length frames.

2.4.

2.3. Encapsulation of Signaling Control Messages of the Native Services

PDUs

It is desirable that contain signaling information of the native service SHOULD
be encapsulated in the same way PEs participate as data PDUs. This simplifies
handling at both little as possible in the ingress
signaling and the egress of a pseudo-wire.

2.5. Timing Information

Timing information can be essential for the endpoints maintenance of a service.
If the original frames contain timing information, native services. However, it is up
to each specific PWE3 approach to specify what the encapsulation
mechanism SHOULD not cause loss of such timing information.
Requirements on clock recovery between pseudo-wire endpoints are
further discussed PEs need to do in the "Maintenance of Emulated Services" section.

2.6.
this regard.

2.4. Support for Circuit Multiplexing

If a service in its native form is capable of grouping multiple
circuits into a "trunk", e.g. an ATM VP, some mechanism SHOULD be
provided so that a single pseudo-wire PW can be used to connect two end-trunks.
From encapsulation perspective, the encapsulation header MUST carry
sufficient information, e.g. VCI of each cell, so that the egress of
the pseudo-wire PW can demultiplex individual circuits from the pseudo-wire.

2.7. PW.

2.5. Packet Ordering

When packets carrying the encapsulated PW PDUs traverse a pseudo-wire, PW, they may arrive at
the egress out of order. For some services, the
encapsulated PW PDUs must be
delivered in order. For such services, some mechanism MUST be
provided to ensure that. for ensuring in-order delivery. Providing a sequence number
in the pseudo-wire PW header for each packet is one possible approach. Every specific PWE3 approach

2.6. Packet Duplication

In rare cases, packets traversing a PW may be duplicated. For some
services, packet duplication is not allowed. For such services some
mechanism MUST define be provided to ensure that duplicated packets will not
be delivered. The mechanism may or may not be the same as a the
mechanism if used to ensure in-order PDU delivery is required. packet delivery.

3. Packet Transport Carrying the PW PDUs over a Packet-Switched Network

This section describes requirements on how to transport send packets carrying
the encapsulated PW PDUs over the a packet-switched network (PSN) that provides PWE3
services.

3.1. Setup of Pseudo-Wires

A pseudo-wire PW is a tunnel that connects two end-services. PWESs. After the L2/L1 PDUs of a
service are encapsulated, they must be transported sent over the pseudo-wire PW to the other end-service.
PWES.

Every PWE3 approach MUST define some signaling mechanism for setting
up the pseudo-wires. PWs. During the setup process, the pseudo-wire
endpoints PEs need to exchange some
information (e.g. learn each other's capability). The signaling
mechanism MUST enable the pseudo-wire
endpoints PEs to exchange all necessary information.
For example, both endpoints must agree on an encapsulation method and the MTU size for
the pseudo-wire. method. As
another example, in order to support circuit multiplexing using ATM
VPs, both pseudo-wire endpoints PEs must agree on using the VCIs in the encapsulated PW PDUs to
demultiplex individual VCs from the VP at the pseudo-wire PW egress. Which
signaling protocol to use and what information to exchange are
service specific. Every PWE3 approach MUST specify these. Manual
configuration can be considered as a special kind of signaling and is
explicitly allowed.

This document does not assume

IP tunnels [MPLSINIP], sessions in a particular type of pseudo-wires. GRE
tunnels, L2TP tunnels, [L2TP] tunnel, or MPLS [MPLS] LSPs
can all be used. used as PWs. Selection of a particular type of pseudo-wires PWs is
carrier-dependent and is outside scope of the PWE3 WG.

A pseudo-wire can be either path-oriented or non-path-oriented. The
difference is core network devices need to maintain state information
for path-oriented pseudo-wires (e.g. LSPs) but not for non-path-
oriented ones (e.g. GRE/L2TP tunnels). This has scalability
implication that is further discussed in the "Scalability" section.

3.2. Pseudo-Wire MTU

A pseudo-wire PW MUST be able to be configured with an MTU that is
sufficient PW_MTU. One way to transport packets whose size equals do this
is to set the largest PDU
size of the native service plus the pseudo-wire header and transport
header. PW_MTU to (PW_Path_MTU - PW_header -
PSN_tunnel_header). At a pseudo-wire PW ingress, if a packet's length exceeds the
pseudo-wire MTU,
PW_MTU, it MUST MAY be dropped. In this case, the management plane of the
ingress PE MAY be notified. Alternatively, a fragmentation mechanism
MAY be defined and used. At a pseudo-wire PW egress, if the length of a L2/L1
frame that is restored from a PW PDU exceeds the MTU of destination end-service,
PWES, it MUST MAY be dropped.

3.3. Transport In this case, the management plane of Signaling the
egress PE MAY be notified. Alternatively, a fragmentation mechanism
MAY be defined and used.

3.3. Carrying Control Messages of the Native Services

Some native services use signaling control messages for maintaining the
circuits. These signaling control messages may be in-band, e.g. Ethernet flow
control or ATM performance management, or out-of-band, e.g. the
signaling VC of an ATM VP (from the perspective of other VCs in that
VP). VP. If such signaling control messages are lost,
functionality of the services will be significantly affected.

Therefore, it can be desirable to provide higher reliability for transporting signaling
carrying control messages.

Each PWE3 approach MAY state what approach can be used What mechanisms to ensure that
signaling messages of the native service will be delivered over the
network with high probability. Differentiating signaling packets from
data packets use and giving them preferable forwarding treatment in how to use
those mechanisms for providing higher reliability are outside scope
of the
network is one possible approach. Such approaches NEED not be
defined in a PWE3 approach itself. WG.

3.4. Transport Efficiency PSN Tunnel Header Overhead

In order to reduce transport PSN tunnel header overhead and increase bandwidth
efficiency, overhead, multiple PDUs MAY be
concatenated before a transport PSN tunnel header is added. Each PDU still
carries its own pseudo-wire PW header so that the egress of the pseudo-wire PW knows how to handle
process it. However, the benefit of concatenating multiple PDUs for
header efficiency should be weighed against the resulting larger
penalty incurred by packet loss.

4. Faithfulness of Emulated Services

An emulated service SHOULD be as similar to the native service as
possible, but it is not REQUIRED that they should be identical. Each
difference The
applicability statement of a PWE3 service MUST report any limitations
of the emulated service. All limitations between an emulated service
and the corresponding native
service, if any, service can be classified as either
functional or non-
functional. non-functional. Functional differences limitations are those that
cause some features of the native service to become disabled in the
emulated one. For example, if an emulated Ethernet service introduces
some difference that can cause the Spanning Tree Protocol (STP) to mal-
function,
malfunction, such a difference will be classified as a functional
difference. Other differences are non-functional. For examples,
differences in service quality between an emulated service and the
native one are non-functional. In every PWE3 approach:

- All functional differences and the features disabled MUST be
pointed out;

- Non-functional differences SHOULD be pointed out.

Some basic requirements on faithfulness of an emulated service are
described below.

4.1. Characteristics of an Emulated Service

Functionally, two service endpoints CEs that are connected by an emulated service MUST
SHOULD appear directly connected by a native service, although
service quality of the emulated service may be different from that of
a native one. Specifically, this implies (but is not limited to) the
followings: following requirements MUST be met:

1) It MUST be possible to define type (e.g. Ethernet or PPP, Ethernet, which is
inherited from the native service), speed (e.g. 100Mbps), and MTU
size for an emulated service.

2) From The two endpoints of emulated service #1 and the two endpoints of
emulated service endpoints' #2 may be connected to the same PE at each end,
respectively. As a result, the PWs of these two emulated services
may share the same physical paths between the two PEs. But from
the CEs' perspective, each emulated service MUST appear as unshared.
unshared, that is, a CE MUST NOT be aware of existence of other
CEs or other emulated services.

3) If an emulated service fails (either at one of the end-services PWESs or in the
middle of the pseudo-wire), PW), both service endpoints CEs MUST be notified reasonably timely. in a timely manner,
if they will be notified in the native service. The definition of "reasonable
timeliness"
"timeliness" is service-dependent.

4) Two service endpoints connected by an emulated service MUST be
able to establish If a routing protocol (e.g. IGP) adjacency can be established over the
emulated service. To
a native service, it MUST be clear, the possible to be established over an
emulated service as well. Spanning Tree Protocol (STP) is not
considered as a routing protocol and requirements on
support/non-support support/non-
support of STP is outside scope of this document.

5) When desired, an emulated service MUST be able to appear as a
normal link in the service endpoints' IGP routing table.

6) The TTL fields of the encapsulated PW PDUs, if exist, MUST not be changed
inside an emulated service.

4.2. Service Quality of Emulated Services

It is RECOMMENDED but not REQUIRED that an emulated service provide
as high service quality as the native service. However, the PWE3 WG
only defines mechanisms for providing pseudo-wire PW emulation, not the services
themselves. What quality to provide for a specific emulated service
is a matter between a service provider (SP) and its customers, and is
outside scope of the PWE3 WG. In fact, different SPs can use the same
PWE3 approach but with different QoS approaches mechanisms to provide the same
emulated service with different service quality.

4.3. Signaling of Native Services

A PWE3 approach SHOULD support signaling of the native service. This
is further discussed in the "Maintenance of Emulated Services"
section.

5. Maintenance of Emulated Services

Every PWE3 approach MUST provide mechanisms for maintaining the
working condition of an emulated service.

5.1. Keep-alive

If a native service and has keep-alive mechanism, the corresponding
emulated service MUST define a similar mechanism for keep-alive.

5.2. Status Monitoring

Some native services have mechanisms for signaling any status
changes.

5.1. Signaling monitoring. For
example, ATM supports OAM for this purpose. For such services, the
corresponding emulated services MUST specify how to perform status
monitoring. The mechanisms NEED NOT be defined in this WG. Some
status monitoring mechanisms defined in other WGs, e.g., [LSPPING] or
[MPLSOAM], may be leveraged.

5.3. Notification of Status Changes of an Emulated Service

5.1.1.

5.3.1. Up/Down Notification

With pseudo-wire emulation,

If a native service is bi-directional, the corresponding emulated
service can only be signaled up when the associated PWs, and PSN
tunnels if any, in both directions are functional.

Because the two CEs of an emulated service are not adjacent, a
failure may occur at a remote place such that one or both physical links
between the SEs CEs and PEs remains remain up. For example in Figure 1, if the
physical link between SE1 CE1 and PE1 fails, the physical link between SE2
CE2 and PE2 will not be affected and will remain up. Unless some signaling CE2 is done to notify SE2 of
notified about the remote failure, SE2 it will continue to send traffic
over the emulated service to SE1. CE1. Such traffic will be discarded at
PE1.
Therefore, Some native services have failure notification so that when an emulated service fails (either at an end-service
or in the middle of the pseudo-wire),
services fail, both service endpoints MUST CEs will be notified. Every For such native services,
the corresponding PWE3 approach service MUST provide such a signaling
mechanism. This functionality is equivalent to failure notification
of normal links.
mechanism.

Similarly, every PWE3 approach MUST provide some signaling if a native service has notification mechanism so that
when a network failure is fixed, all the affected emulated services will
change status from "Down" to "Up".

5.1.2. "Up", the corresponding emulated service
MUST provide a similar mechanism for doing so.

5.3.2. Misconnection and Payload Mistype

With PWE3, misconnection and payload mistype can occur. A PWE3
approach MAY define some mechanism for detecting and handling
misconnection and payload mistype.

5.3.3. Packet Loss and/or Loss, Corruption, and Out-of-order Delivery

A pseudo-wire PW can incur packet loss and/or loss, corruption, and out-of-order delivery.
This can significantly impact the working condition of an emulated service. Number of packets lost or delivered out of order in unit
time Packet
loss, corruption, and out-of-order delivery can be considered as two new types of
"generalized bit error
rate" error" of a pseudo-wire. Every PWE3 approach SHOULD provide PW. If a native service has some
mechanism so that if either type of "generalized to deal with bit error rate"
exceeds some configured threshold, error, the pseudo-wire and the emulated corresponding PWE3 service will be signaled down.

5.1.3.
SHOULD provide a similar mechanism.

5.3.4. Other Status Signaling Notification

A PWE3 approach MAY provide mechanism for other status signaling, notification,
if any.

5.1.4.

5.3.5. Collective Status Signaling Notification

Status of a group of emulated services may be affected identically by
a single network incidence. For example, when the physical link
between a SE CE and a PE fails, all the emulated services that go
through that link will fail. It is likely that there exists a group
of emulated services which all terminate at a remote SE. CE. (There can
be multiple such SEs). CEs). Therefore, it is desirable that a single
signaling
notification message can be used to signal the notify failure of the whole group of
emulated services. A PWE3 approach MAY provide some mechanism for signaling
notifying status changes of a group of emulated circuits. One
possible approach is to associate each emulated service with a group
ID when the pseudo-wire PW for that emulated service is set up. Multiple emulated
services can then be grouped by
associated associating them with identical group
ID. In status signaling, notification, that group ID can then be used to refer all
the emulated services in that group.

5.2.

5.4. Clock Recovery

For some services, the pseudo-wire endpoints PEs need to maintain some kind of timing
relationship (e.g. synchronization). A The corresponding PWE3 approach
for such services
MUST provide some mechanism to support that. If time stamps need to
be carried across the PSN, [RTP] MUST be used.

6. Management of Emulated Services

Each PWE3 approach SHOULD provide some mechanisms for network
operators to manage the emulated service. These mechanisms can be in
the forms described below.

6.1. MIB

A pseudo-wire MIB (PW-MIB) MAY MIBs

SNMP MIBs [SMIV2] MUST be provided for managing each emulated
service. The MIB service
as well as pseudo-wire in general. These MIBs SHOULD have be created with
the following requirements:

- The counters in the requirements.

6.2. General MIB SHOULD NOT replicate Requirements

New MIBs MUST augment or extend where appropriate, existing MIB counters.

- Each end-service SHOULD appear tables as an interface
defined in the ifTable.

- The MIB SHOULD describe how the other existing counters are used service-specific MIBs for
pseudo-wire emulation.

- The MIB MAY support row creation to create new end-service pairs.

- The MIB MAY augment existing tables. services
such as MPLS or L2TP. For example, the ifTable
SHOULD as defined in the
Interface MIB [IFMIB] MUST be augmented to provide counts of out-of-order out-of-
order packets.

- The MIB SHOULD define meanings A second example is the extension of the MPLS-TE-MIB
[TEMIB] when emulating circuit services over MPLS. Rather than
redefining the tunnelTable so that PWES can utilize MPLS tunnels, for
example, entries in this table MUST instead be extended to add
additional PWES-specific objects. Doing so facilitates a natural
extension of those objects defined in the standard linkUp and linkDown
traps, existing MIBs in terms of
management, as well as any protocol-specific traps that are needed.

- The leveraging existing agent implementations.

Interfaces implementing a PWES MUST appear as an interface in the
ifTable.

6.3. Configuration and Provisioning

MIB SHOULD Tables MUST be structured in designed to facilitate configuration and
provisioning of the PWES.

The MIB(s) MUST facilitate intra-PSN configuration and monitoring of
PWES connections.

6.4. Performance Monitoring

MIBs MUST collect statistics for performance and fault management.

MIBs MUST provide a hierarchical fashion such that
generic description of how existing counters are used for
PW objects emulation and tables are SHOULD not duplicated for each service.

6.2. replicate existing MIB counters.

6.5. Fault Management and Notifications

Notifications SHOULD be defined where appropriate to notify the
network operators of any interesting situations, including faults
detected in the PWES.

Objects defined to augment existing protocol-specific notifications
in order to add PWES functionality MUST explain how these
notifications are to be emitted.

6.6. Pseudo-Wire Traceroute

It can be desirable to know the exact path of a pseudo-wire, PW, especially for
troubleshooting purpose. A pseudo-wire PW emulation service MAY MUST support pseudo-wire traceroute, even if the pseudo-wire
used PW
traceroute. One tunnel traceroute approach is non-path-oriented. defined in [BONICA].

7. Scalability

Scalability requirements for Pseudo-Wire Emulation Edge to Edge PWE3 are described below.

- Pseudo-wire emulation services SHOULD be transparent to other
packet services (e.g. best effort Internet service).

- Only pseudo-wire endpoints PEs should be aware of existence of pseudo-
wires PWs and PWE3 services.
Core network devices SHOULD NOT be exposed to a large number of pseudo-wires.

Pseudo-wires
PWs.

PWs can be path-oriented or non-path-oriented. For path-
oriented pseudo-wires, path-oriented
PWs, core network devices must maintain state information for them.
If a large number of path-oriented pseudo-
wires PWs are used, core network
devices will have to maintain a large amount of state information.
In order to avoid scalability problem,
transport PSN tunnels between pseudo-wire endpoints PEs can
be introduced.
Pseudo-wires PWs from the same ingress to the same egress are
nested inside the transport PSN tunnel that is from that ingress to that
egress. By creating such a tunnel hierarchy, individual pseudo-
wires PWs are
transparent to the core devices. If a specific PWE3 approach uses
path-oriented pseudo-wires, transport PWs, PSN tunnels SHOULD be used to improve
scalability. However, a transport PSN tunnel is not part of any pseudo-wire. PW.
Signaling of transport PSN tunnels NEED NOT be defined in the PWE3 approach
itself. As an example, if LSPs are used as pseudo-wires PWs in a PWE3 approach,
they can be nested inside a tunnel LSP from the pseudo-wire PW ingress to the pseudo-wire
PW egress. The tunnel LSPs can be signaled by any mechanism
defined in [MPLS].

- Circuit multiplexing: circuit multiplexing SHOULD be supported.

- Collective status signaling: Collective notification: collective status signaling notification
SHOULD be supported.

8. Other Generic Requirements

Other generic requirements for Pseudo-Wire Emulation Edge to Edge
include:

- No New Protocol Operations:

No matter which protocol (e.g. GRE or L2TP or MPLS) is used

8.1. RFC 2914 Conformance

[RFC2914] describes the need for
packet transport, PWE3 SHOULD just be an application of that
protocol. In other words, no new protocol (GRE or L2TP or MPLS)
operations SHOULD be introduced. For example, if an MPLS label
switching operation is performed, a congestion control in the Internet,
and discusses what constitute correct congestion control. Any PWE3
approach SHOULD not
require that the TTL field of the top label remains unchanged.
(Otherwise, this label switching would be different from a normal
MPLS label switching MUST conform to RFC 2914 and would be considered as a new protocol
operation). If any new operations are indeed introduced TCP-friendly in its response
to congestion. The applicability document of a PWE3
approach, they approach MUST be clearly pointed out.

- Minimum configuration work at the pseudo-wire endpoints;

- Easy to maintain and manage.
provide a statement on RFC 2914 conformance.

9. Non-Requirements

Some non-requirements are mentioned in various sections of this
document. Those work items are outside scope of the PWE3 WG. The
non-requirements are listed below:

- Service interworking;

- Point-to-multipoint or multipoint-to-multipoint PWs;

- Selection of a particular type of pseudo-wires; PWs;

- Striving to make the emulated services perfectly match their native
services;

- Defining mechanisms for signaling the transport PSN tunnels;

- Defining how to perform traffic management on packets that carry
encapsulated PW
PDUs;

- Providing security for the encapsulated PW PDUs;

- Providing any multicast service that is not native to the emulated
medium.

To illustrate this point, Ethernet transmission to a multicast
IEEE-48 address is considered in scope, while multicast services
like [MARS] that are implemented on top of the medium are out of
scope;

10. Quality of Service (QoS) Considerations

In this document, QoS means satisfactory service quality. It should
not be confused with QoS mechanisms such as Weighted Fair Queueing Queuing
(WFQ) or Random Early Detection (RED).

QoS is essential for ensuring that the emulated services are similar
(but not necessarily identical) to their native forms. It is up to
network operators to decide how to provide QoS - They can choose to
rely on over-provisioning and/or deploy some QoS mechanisms.

In order to take advantage of some QoS mechanisms defined in other working
groups, e.g. the traffic management schemes defined in DiffServ WG,
it is desirable that some mechanisms exists for differentiating the
packets resulted from PDU encapsulation. These mechanisms need not be
defined in the PWE3 approaches themselves. For example, if the resulted
packets are MPLS or IP packets, their EXP or DSCP fields can be used
for marking and differentiating,
respectively. Every differentiating. A PWE3 approach SHOULD MAY provide
guidelines for marking and differentiating, e.g. what fields in the
original L2 or L1 headers should be used for determining the EXP/DSCP
value. But the exact procedure on of how to perform marking and
differentiating, e.g. specifying the mapping function from Ethernet
.1P field to EXP field, is out of scope.

11. Inter-domain Pseudo-Wires

The PWE3 WG will determine the requirements for having a pseudo-wire PW pass
across an administrative boundary. An edge could be a native
hand-off hand-
off or hand-off to a further pseudo-wire. PW. The working group may analyze
requirements for both security and performance for the
inter-administration inter-
administration technology. This topic is for further study.

12. Security Considerations

12.1. Security Considerations for the Signaling/Control Channel

If a signaling/control channel is used in a PWE3 approach, some
security mechanism SHOULD MUST be provided to ensure integrity of the
information transmitted across the signaling/control channel.

12.2. Security Considerations for the Encapsulated PW PDUs

Providing security for the encapsulated PW PDUs is outside scope of the PWE3 WG.

13. Deployment Considerations

Transition from using separate networks for TDM, ATM, Frame Relay and
IP services to using a single network for multiple services requires
careful planning and execution. This is an important topic for
further study.

14. Acknowledgments

Some requirements specified in this document were originally
articulated in a number of documents including [MART1], [MART2], [MARTINI1],
[MARTINI2], [CES], and [SFBS]. The authors would like to acknowledge
authors of those documents. The authors would also like to
acknowledge the input and comments from T. So. Eric Rosen, Tricci So and Ron
Cohen.

15. References

[BONICA] R. Bonica, K. Kompella, and D. Meyer, "Tracing Requirements
for Generic Tunnels", <draft-bonica-tunneltrace-01.txt>,
work in progress, Feb. 2001.

[CES] A. Malis et al, "SONET/SDH Circuit Emulation Service Over
MPLS (CEM) Encapsulation" <draft-malis-sonet-ces-mpls-
04.txt>, , work in progress, April 2001.

[GRE] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, "Generic
Routing Encapsulation (GRE)", RFC2784, March 2000.

[IFMIB] K. McCloghrie, and F. Kastenholtz, "The Interfaces Group MIB
using SMIv2", RFC 2233, Nov. 1997.

[L2TP] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall, G.
Zorn, B. Palter, "Layer Two Tunneling Protocol (L2TP)", RFC
2661, August 1999.

[LSPPING] P. Pan, N. Sheth, and D. Cooper, "Detecting Data Plane
Liveliness in RSVP-TE", <draft-pan-lsp-ping-00.txt>, work in
progress, July 2001.

[MARS] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based
ATM Networks", RFC2022, November 1996

[MART1]

[MARTINI1] L. Martini et al, "Transport of Layer 2 Frames Over MPLS",
<draft-martini-l2circuit-trans-MPLS-06.txt>, work in
progress, May 2001.

[MART2]

[MARTINI2] L. Martini et al, "Encapsulation Methods for Transport of
Layer 2 Frames Over MPLS", <draft-martini-l2circuit-encap-
MPLS-02.txt>, work in progress, May 2001.

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

[MPLSINIP] P. Doolan, Y. Katsube, A. Malis, R. Wilder, T. Worster,
"MPLS Label Stack Encapsulation in IP", <draft-worster-
mpls-in-ip-04.txt>, work in progress, Feb. 2001.

[MPLSOAM] N. Harrison, P. Willis, S. Davari, B. Mack-Crane, H. Ohta,
"OAM Functionality for MPLS Networks", <draft-harrison-
mpls-oam-00.txt>, work in progress, Feb. 2001.

[TEMIB] C. Srinivasan, A. Viswanathan, and T. Nadeau, "MPLS Traffic
Engineering Management Information Base Using SMIv2",
<draft-ietf-mpls-te-mib-05.txt>, work in progress, November
2000.

[PATE] P. Pate, X. Xiao, T. So, C. White, and K. Kompella,
"Framework for Pseudo Wire Pseudo-Wire Emulation Edge-to-Edge (PWE3)",
<draft-pate-pwe3-framework-00.txt>, work in progress, May
2001.

[RFC2914] S.Floyd, "Congestion Control Principles", RFC 2914, Sept.
2000.

[RTP] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC1889, January 1996.

[SFBS] B. St-Denis, D. Fedyk, A. Bhatnagar, A. Siddiqui, R.
Hartani, and T. So So, "Multi-service over MPLS", <draft-
stdenis-ms-over-mpls-00.txt>, work in progress, Nov. 2000.

[SMIV2] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser,
"Structure of Management Information for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.

16. Authors' Addresses

XiPeng Xiao
Photuris, Inc.
2025 Stierlin Court
Mountain View, CA 94043
Email: xxiao@photuris.com

Danny McPherson
Amber Networks, Inc.
48664 Milmont Drive
Fremont, CA 94538
Email: danny@ambernetworks.com

Prayson Pate
Overture Networks
P. O. Box 14864
RTP, NC, USA 27709
Email: prayson.pate@overturenetworks.com

Craig White
Level 3 Communications, LLC.
1025 Eldorado Blvd.
Broomfield, CO, 80021
e-mail: Craig.White@Level3.com

Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
Email: kireeti@juniper.net

Vijay Gill
Metromedia Fiber Network Inc.
8075 Leesburg Pike, Suite 300
Vienna, VA 22182
Email: vgill@mfnx.net

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

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.