WG ACTION: Pseudo Wire Emulation Edge to Edge (pwe3)

[The IESG <iesg-secretary@ietf.org>]

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
 
 Chair(s):
     Danny McPherson <danny@ambernetworks.com>
     Luca Martini <luca@level3.net>
 
 Transport Area Director(s): 
     Scott Bradner  <sob@harvard.edu>
     Allison Mankin  <mankin@isi.edu>
 
 Transport Area Advisor: 
     Allison Mankin  <mankin@isi.edu>
 
 Mailing Lists: 
     General Discussion:pwe3@ietf.org
     To Subscribe:      pwe3-request@ietf.org
         In Body:       subscribe your_email_address
     Archive:           http://www.ietf.org/mail-archive/working-groups/pwe3/
 
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.

Assumptions

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

   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,
   where required.

   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
   inter-administration technology.

Deliverables

  General documents:

    Requirements Document

    Framework Document

    Common Edge-to-Edge Emulation/Maintenance Protocol
 
    Requirements for PW Traceroute (if distinct from tunnel-specific or 
    CCAMP traceroute).

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)

     Frame Relay

     ATM

     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 
                deliverables                                                   

   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