[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
WG ACTION: Pseudo Wire Emulation Edge to Edge (pwe3)
- To: IETF-Announce: ;
- Subject: WG ACTION: Pseudo Wire Emulation Edge to Edge (pwe3)
- From: The IESG <email@example.com>
- Date: Mon, 14 May 2001 15:56:14 -0400
- Delivery-date: Mon, 14 May 2001 23:32:29 +0300
- Envelope-to: firstname.lastname@example.org
- Sender: email@example.com
A new working group has been formed in the Transport Area of the IETF.
For additional information, contact the Area Directors
or the WG Chair.
Pseudo Wire Emulation Edge to Edge (pwe3)
Current Status: Active Working Group
Danny McPherson <firstname.lastname@example.org>
Luca Martini <email@example.com>
Transport Area Director(s):
Scott Bradner <firstname.lastname@example.org>
Allison Mankin <email@example.com>
Transport Area Advisor:
Allison Mankin <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: subscribe your_email_address
Description of Working Group:
Service providers (SP) are seeking to offer multiple services across
a common packet switched network (PSN), such that the result is
emulations of e.g. Frame Relay or ATM circuits, or SONET/SDH.
Multiple services on common infrastructure can be offered using
pairwise conversions, so for instance, if the native link is
ATM, FR could be offered over it by having modules that convert
FR to ATM going in and ATM into FR coming out.
An alternative approach is to provide multiple services, each
as an emulation in a tunnel over an IP packet switched network.
There are many proprietary service-specific implementations in
in the market now that use this approach. The PSN can transport PDUs
for multiple services, and the conversion/interworking functions per
service pair are not needed. We term the tunnels used in this approach
"pseudo wires" (with no implication that what is emulated is copper
or otherwise is restricted to real world wires, but rather with
the commonly used metaphorical sense of wire, as when a mobile
device designer speaks of the "on the wire" packet formats!)
The basic idea of this working group is to develop standards for
the encapsulation and service emulation of pseudo wires: encapsulating
service-specific PDUs arriving at an ingress logical port and carrying
them across a tunnel, managing their timing, order or other aspects
entering and leaving the tunnel, to emulate the behavior and
characteristics of the service as well as possible. Applicability
statements for each service will describe expected shortfalls of
the emulation's faithfulness.
>From the customer perspective, the pseudo wire is perceived as an
unshared link or circuit (or the appropriate unit) of the chosen
service (although it will not be a perfect emulation of the service).
Pseudo wires require the edge devices providing service interfaces
to use common service-specific techniques for encapsulating PDUs and
maintaining the service characteristics and behavior in the data flow.
The purpose of the WG is to pursue standardization of the framework and
the service-specific techniques for pseudo wires.
PWE3 protocols and implementation focus on the edge-to-edge
emulation and maintenance of service-specific pseudo-wires.
Creation and placement of the tunnels is outside of the scope.
Tunnels for PWE3 encapsulations will use IP (both versions), L2TP,
or MPLS. PWE3 will coordinate closely with the L2TP WG and its
technologies. PWE3 pseudo wires will have the same specification
for all underlying PSNs (i.e. there will not be specific adaptation
of a pseudo wire technology for MPLS that is distinct from what is
used for IP and L2TP, or differences will be the minimum necessary
and will be called out clearly).
PWE3 will not exert controls on the underlying PSN, but only
function at the endpoints of the pseudo wire, though the endpoints
may be configured to set diffserv codepoints in the tunneling
PWE3 will use RTP where necessary to perform clock recovery and
other real-time signaling functions. This work will be
coordinated with the AVT WG and payloads will follow RFC 2736.
PWE3 will not strive for pseudo wires to perfectly emulate the
characteristics of the native service. For each type of pseudo
wire, an applicability statement will describe the degree of
similarity of a pseudo wire to the native service it emulates.
WG Objectives (in order of priority):
Develop a requirements document to define the specific services and
technology to be defined by the working group.
Specify methods with RTP (and possibly using header compression
where needed) to ensure in-order final PDU delivery, perform clock
recovery inband emulation and maintenance functions across the PSN,
Research the statistics and other network management information
needed for tunnel operation and management, for example, to be able
to determine when a circuit's up/down state has changed. Coordinate
closely with the CCAMP WG on this.
Specify the security mechanisms to be used to protect the control of
the PWE3 technology. These are likely to be security mechanisms that
are part of the tunnel creation technology and not be developed by
PWE3, but cited by PWE3 specifications. Requirements may be
ommunicated to the PPVPN, L2TPEXT and CCAMP WGs. The protection of
the encapsulated content of the pseudo wire is outside of scope.
The WG will determine the requirements for having a pseudo wire pass
across an administrative boundary. An edge could be a native
hand-off or hand-off to a further pseudo-wire. The WG may
analyze requirements for both security and performance for the
Common Edge-to-Edge Emulation/Maintenance Protocol
Requirements for PW Traceroute (if distinct from tunnel-specific or
Individual encapsulation and emulation/maintenance document(s) for each
of the following transported protocols, as well as applicability
statements for each:
Ethernet (DIX Ethernet (100M, 1G, 10G), IEEE 802.3, 802.1q (VLAN)
TDM (e.g. DS1, DS3, SONET)
MPLS (over IP or L2TP only)
Out of Scope
Any multicast service not native to the emulated medium.
Thus, Ethernet transmission to a "multicast" IEEE-48 address is in
scope, while multicast services like MARS that are implemented on top
of the medium are out of scope.
Methods to signal underlying network.
Other Working Groups We Will Coordinate With
L2TPEXT, DIFFSERV, AVT, CCAMP, PPVPN, MPLS, TEWG, ROHC
Goals and Milestones:
May 01 PWE3 WG started, organize editing teams.
May 01 Hold interim meeting, including discussion of priority of
service-specific documents and consider pruning some
Jun 01 Requirements Document Last Call
Jul 01 Framework Documents Last Call
Aug 01 Produce first draft of PWE3 MIB and review MIBs for specific
services to determine if they can be used for the pseudo wire
services, or whether additional deliverables will be needed
Oct 01 Frame Relay Documents Last Call
Oct 01 First drafts of service-specific documents
Oct 01 Ethernet Documents Last Call
Mar 02 ATM Documents Last Call
Mar 02 SONET Documents Last Call
Mar 02 Other TDM Circuit Documents Last Call
Jul 02 PWE3 WG Charter Review, Additional Work or Ends