Request for Comments: 3916 Riverstone Networks
Category: Informational D. McPherson, Ed.
Arbor Networks
P. Pate, Ed.
Overture Networks
September 2004
Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes base requirements for the Pseudo-Wire
Emulation Edge to Edge Working Group (PWE3 WG). It provides
guidelines for other working group documents that will define
mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and
Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e.,
"synchronous bit streams at rates defined by ITU G.702") are defined
in another document. It should be noted that the PWE3 WG
standardizes mechanisms that can be used to provide PWE3 services,
but not the services themselves.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. What Are Pseudo Wires?. . . . . . . . . . . . . . . . . 2
1.2. Current Network Architecture. . . . . . . . . . . . . . 3
1.3. PWE3 as a Path to Convergence . . . . . . . . . . . . . 4
1.4. Suitable Applications for PWE3. . . . . . . . . . . . . 4
1.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Reference Model of PWE3 . . . . . . . . . . . . . . . . . . . 6
4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Encapsulation . . . . . . . . . . . . . . . . . . . . . 7
4.2. Frame Ordering. . . . . . . . . . . . . . . . . . . . . 8
4.3. Frame Duplication . . . . . . . . . . . . . . . . . . . 8
4.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . 8
4.5. Consideration of Per-PSN Packet Overhead. . . . . . . . 9
5. Maintenance of Emulated Services. . . . . . . . . . . . . . . 9
5.1. Setup and Teardown of Pseudo-Wires. . . . . . . . . . . 9
5.2. Handling Maintenance Message of the Native Services . . 10
5.3. PE-initiated Maintenance Messages . . . . . . . . . . . 10
6. Management of Emulated Services . . . . . . . . . . . . . . . 12
6.1. 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 Connection Verification and Traceroute. . . 13
7. Faithfulness of Emulated Services . . . . . . . . . . . . . . 13
7.1. Characteristics of an Emulated Service. . . . . . . . . 14
7.2. Service Quality of Emulated Services. . . . . . . . . . 14
8. Non-Requirements. . . . . . . . . . . . . . . . . . . . . . . 14
9. Quality of Service (QoS) Considerations . . . . . . . . . . . 15
10. Inter-domain Issues . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
13. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References. . . . . . . . . . . . . . . . . . 17
13.2. Informative References. . . . . . . . . . . . . . . . . 17
14. Authors’ Addresses. . . . . . . . . . . . . . . . . . . . . . 18
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19
1. Introduction
1.1. What Are Pseudo Wires?
Pseudo Wire Emulation Edge-to-Edge (PWE3) is a mechanism that
emulates the essential attributes of a service such as ATM, Frame
Relay or Ethernet over a Packet Switched Network (PSN). The required
functions of PWs include encapsulating service-specific PDUs arriving
at an ingress port, and carrying them across a path or tunnel,
managing their timing and order, and any other operations required to
emulate the behavior and characteristics of the service as faithfully
as possible.
From the customer perspective, the PW is perceived as an unshared
link or circuit of the chosen service. However, there may be
deficiencies that impede some applications from being carried on a
PW. These limitations should be fully described in the appropriate
service-specific documents and Applicability Statements.
1.2. Current Network Architecture
The following sections give some background on where networks are
today and why they are changing. It also talks about the motivation
to provide converged networks while continuing to support existing
services. Finally, it discusses how PWs can be a solution for this
dilemma.
1.2.1. Multiple Networks
For any given service provider delivering multiple services, the
current infrastructure usually consists of parallel or "overlay"
networks. Each of these networks implements a specific service, such
as Frame Relay, Internet access, etc. This is expensive, both in
terms of capital expense and operational costs. Furthermore, the
presence of multiple networks complicates planning. Service
providers wind up asking themselves these questions:
- Which of my networks do I build out?
- How many fibers do I need for each network?
- How do I efficiently manage multiple networks?
A converged network helps service providers answer these questions in
a consistent and economical fashion.
1.2.2. Transition to a Packet-Optimized Converged Network
In order to maximize return on their assets and minimize their
operating costs, service providers often look to consolidate the
delivery of multiple service types onto a single networking
technology.
As packet traffic takes up a larger and larger portion of the
available network bandwidth, it becomes increasingly useful to
optimize public networks for the Internet Protocol. However, many
service providers are confronting several obstacles in engineering
packet-optimized networks. Although Internet traffic is the fastest
growing traffic segment, it does not generate the highest revenue per
bit. For example, Frame Relay traffic currently generates higher
revenue per bit than native IP services do. Private line TDM
services still generate even more revenue per bit than does Frame
Relay. In addition, there is a tremendous amount of legacy equipment
deployed within public networks that does not communicate using the
Internet Protocol. Service providers continue to utilize non-IP
equipment to deploy a variety of services, and see a need to
interconnect this legacy equipment over their IP-optimized core
networks.
1.3. PWE3 as a Path to Convergence
How do service providers realize the capital and operational benefits
of a new packet-based infrastructure, while leveraging the existing
equipment and also protecting the large revenue stream associated
with this equipment? How do they move from mature Frame Relay or ATM
networks, while still being able to provide these lucrative services?
One possibility is the emulation of circuits or services via PWs.
Circuit emulation over ATM and interworking of Frame Relay and ATM
have already been standardized. Emulation allows existing services
to be carried across the new infrastructure, and thus enables the
interworking of disparate networks.
Implemented correctly, PWE3 can provide a means for supporting
today’s services over a new network.
1.4. Suitable Applications for PWE3
What makes an application suitable (or not) for PWE3 emulation? When
considering PWs as a means of providing an application, the following
questions must be considered:
- Is the application sufficiently deployed to warrant emulation?
- Is there interest on the part of service providers in providing an
emulation for the given application?
- Is there interest on the part of equipment manufacturers in
providing products for the emulation of a given application?
- Are the complexities and limitations of providing an emulation
worth the savings in capital and operational expenses?
If the answer to all four questions is "yes", then the application is
likely to be a good candidate for PWE3. Otherwise, there may not be
sufficient overlap between the customers, service providers,
equipment manufacturers and technology to warrant providing such an
emulation.
1.5. Summary
To maximize the return on their assets and minimize their operational
costs, many service providers are looking to consolidate the delivery
of multiple service offerings and traffic types onto a single IP-
optimized network.
In order to create this next-generation converged network, standard
methods must be developed to emulate existing telecommunications
formats such as Ethernet, Frame Relay, and ATM over IP-optimized core
networks. This document describes requirements for accomplishing
this goal.
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.
Some terms used throughout this document are listed below.
Attachment Circuit (AC)
The physical or virtual circuit attaching a CE
to a PE. An AC can be a Frame Relay DLCI, an
ATM VPI/VCI, an Ethernet port, a VLAN, a HDLC
link, a PPP connection on a physical interface,
a PPP session from an L2TP tunnel, an MPLS LSP,
etc.
Customer Edge (CE) A device where one end of a service originates
and/or terminates. The CE is not aware that it
is using an emulated service rather than a
native service.
Packet Switched Network (PSN)
Within the context of PWE3, this is a network
using IP or MPLS as the mechanism for packet
forwarding.
Provider Edge (PE) A device that provides PWE3 to a CE.
Pseudo Wire (PW) A mechanism that carries the essential elements
of an emulated circuit from one PE to another
PE over a PSN.
Pseudo Wire Emulation Edge to Edge (PWE3)
A mechanism that emulates the essential
attributes of a service (such as a T1 leased
line or Frame Relay) over a PSN.
Pseudo Wire PDU A Protocol Data Unit (PDU) sent on the PW that
contains all of the data and control
information necessary to emulate the desired
service.
PSN Tunnel A tunnel across a PSN inside which one or more
PWs can be carried.
3. Reference Model of PWE3
A pseudo-wire (PW) is a connection between two provider edge (PE)
devices which connects two attachment circuits (ACs). An AC can be a
Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, a HDLC
link, a PPP connection on a physical interface, a PPP session from an
L2TP tunnel, an MPLS LSP, etc.
|<------- Pseudo Wire ------>|
| |
| |<-- PSN Tunnel -->| |
V V V V
+----+ +----+
+-----+ | PE1|==================| PE2| +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | |==================| | +-----+
^ | +----+ +----+ ^
| | Provider Edge 1 Provider Edge 2 |
| | |
| Attachment Circuit |
| |
|<-------------- Emulated Service ---------------->|
Customer Customer
Edge 1 Edge 2
Figure 1: PWE3 Reference Model
During the setup of a PW, the two PEs will be configured or will
automatically exchange information about the service to be emulated
so that later they know how to process packets coming from the other
end. After a PW is set up between two PEs, frames received by one PE
from an AC are encapsulated and sent over the PW to the remote PE,
where native frames are re-constructed and forwarded to the other CE.
For a detailed PWE3 architecture overview, readers should refer to
the PWE3 architecture document [PWE3_ARCH].
This document does not assume that a particular type of PWs (e.g.,
[L2TPv3] sessions or [MPLS] LSPs) or PSNs (e.g., IP or MPLS) is used.
Instead, it describes generic requirements that apply to all PWs and
PSNs, for all services including Ethernet, ATM, and Frame Relay, etc.
4. Packet Processing
This section describes data plane requirements for PWE3.
4.1. Encapsulation
Every PE MUST provide an encapsulation mechanism for PDUs from an AC.
It should be noted that the PDUs to be encapsulated may or may not
contain L2 header information. This is service specific. Every PWE3
service MUST specify what the PDU is.
A PW header consists of all the header fields in a PW PDU that are
used by the PW egress to determine how to process the PDU. The PSN
tunnel header is not considered as part of the PW header.
Specific requirements on PDU encapsulation are listed below.
4.1.1. Conveyance of Necessary L2 Header Information
The egress of a PW needs some information, e.g., which native service
the PW PDUs belong to, and possibly some L2 header information, in
order to know how to process the PDUs received. A PWE3 encapsulation
approach MUST provide some mechanism for conveying such information
from the PW ingress to the egress. It should be noted that not all
such information must be carried in the PW header of the PW PDUs.
Some information (e.g., service type of a PW) can be stored as state
information at the egress during PW setup.
4.1.2. Support of Variable Length PDUs
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.
4.1.3. Support of Multiplexing and Demultiplexing
If a service in its native form is capable of grouping multiple
circuits into a "trunk", e.g., multiple ATM VCCs in a VPC or multiple
Ethernet 802.1Q interfaces in a port, some mechanism SHOULD be
provided so that a single PW can be used to connect two end-trunks.
From encapsulation perspective, sufficient information MUST be
carried so that the egress of the PW can demultiplex individual
circuits from the PW.
4.1.4. Validation of PW-PDU
Most L2 frames have a checksum field to assure frame integrity.
Every PWE3 service MUST specify whether the frame’s checksum should
be preserved across the PW, or should be removed at the ingress PE
and then be re-calculated and inserted at the egress PE. For
protocols such as ATM and FR, the checksum covers link-local
information such as the circuit identifiers (e.g., FR DLCI or ATM
VPI/VCI). Therefore, such checksum MUST be removed at the ingress PE
and recalculated at the egress PE.
4.1.5. Conveyance of Payload Type Information
Under some circumstances, it is desirable to be able to distinguish
PW traffic from other types of traffic such as IPv4 or IPv6 or OAM.
For example, if Equal Cost Multi-Path (ECMP) is employed in a PSN,
this additional distinguishability can be used to reduce the chance
that PW packets get misordered by the load balancing mechanism. Some
mechanism SHOULD provide this distinguishability if needed. Such
mechanism MAY be defined in the PWE3 WG or other WGs.
4.2. Frame Ordering
When packets carrying the PW PDUs traverse a PW, they may arrive at
the egress out of order. For some services, the frames (either
control frames only or both control and data frames) must be
delivered in order. For such services, some mechanism MUST be
provided for ensuring in-order delivery. Providing a sequence number
in the PW header for each packet is one possible approach to detect
out-of-order frames. Mechanisms for re-ordering frames may be
provided by Native Service Processing (NSP) [PWE3_ARCH] but are out
of scope of PWE3.
4.3. Frame Duplication
In rare cases, packets traversing a PW may be duplicated. For some
services, frame duplication is not allowed. For such services some
mechanism MUST be provided to ensure that duplicated frames will not
be delivered. The mechanism may or may not be the same as the
mechanism used to ensure in-order frame delivery.
4.4. Fragmentation
If the combined size of the L2 payload and its associated PWE3 and
PSN headers exceeds the PSN path MTU, the L2 payload may need to be
fragmented (Alternatively the L2 frame may be dropped). For certain
native service, fragmentation may also be needed to maintain a
control frame’s relative position to the data frames (e.g., an ATM PM
cell’s relative position). In general, fragmentation has a
performance impact. It is therefore desirable to avoid fragmentation
if possible. However, for different services, the need for
fragmentation can be different. When there is potential need for
fragmentation, each service-specific PWE3 document MUST specify
whether to fragment the frame in question or to drop it. If an
emulated service chooses to drop the frame, the consequence MUST be
specified in its applicability statement.
4.5. Consideration of Per-PSN Packet Overhead
When the L2 PDU size is small, in order to reduce PSN tunnel header
overhead, multiple PDUs MAY be concatenated before a PSN tunnel
header is added. Each encapsulated PDU still carries its own PW
header so that the egress PE knows how to process it. However, the
benefit of concatenating multiple PDUs for header efficiency should
be weighed against the resulting increase in delay, jitter and the
larger penalty incurred by packet loss.
5. Maintenance of Emulated Services
This section describes maintenance requirements for PWE3.
5.1. Setup and Teardown of Pseudo-Wires
A PW must be set up before an emulated circuit can be established,
and must be torn down when an emulated circuit is no longer needed.
Setup and teardown of a PW can be triggered by a command from the
management plane of a PE, or by Setup/Teardown of an AC (e.g., an ATM
SVC), or by an auto-discovery mechanism.
Every PWE3 approach MUST define some setup mechanism for establishing
the PWs. During the setup process, the PEs need to exchange some
information (e.g., to learn each other’s capability). The setup
mechanism MUST enable the PEs to exchange all necessary information.
For example, both endpoints must agree on methods for encapsulating
PDUs and handling frame ordering. Which signaling protocol to use
and what information to exchange are service specific. Every PWE3
approach MUST specify them. Manual configuration of PWs can be
considered as a special kind of signaling and is allowed.
If a native circuit is bi-directional, the corresponding emulated
circuit can be signaled "Up" only when the associated PW and PSN
tunnels in both directions are functional.
5.2. Handling Maintenance Message of the Native Services
Some native services have mechanisms for maintenance purpose, e.g.,
ATM OAM and FR LMI. Such maintenance messages can be in-band (i.e.,
mixed with data messages in the same AC) or out-of-band (i.e., sent
in a dedicated control circuit). For such services, all in-band
maintenance messages related to a circuit SHOULD be transported in-