Current Meeting Report

2.8.11 Pseudo Wire Emulation Edge to Edge (pwe3)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 06/05/2002

Danny McPherson <>
Transport Area Director(s):
Scott Bradner <>
A. Mankin <>
Transport Area Advisor:
A. Mankin <>
Technical Advisor(s):
W. Mark Townsley <>
Mailing Lists:
General Discussion:
To Subscribe:
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 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.


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


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


Goals and Milestones:
Done  PWE3 WG started, organize editing teams.
Done  Hold interim meeting, including discussion of priority of service-specific documents and consider pruning some deliverables
JUN 02  Accept drafts of service-specific documents as WG items
JUN 02  Requirements Document Last Call
JUN 02  Framework Documents Last Call
DEC 02  SONET Documents Last Call
DEC 02  TDM Circuit Documents Last Call
DEC 02  ATM Documents Last Call
DEC 02  Frame Relay Documents Last Call
DEC 02  Ethernet Documents Last Call
MAR 03  PWE3 WG Charter Review, Additional Work or Ends
MAR 03  PWE3 MIBs Last Call
  • - draft-ietf-pwe3-requirements-03.txt
  • - draft-ietf-pwe3-framework-01.txt
  • - draft-ietf-pwe3-protocol-layer-00.txt
  • - draft-ietf-pwe3-pw-mib-00.txt
  • - draft-ietf-pwe3-pw-mpls-mib-00.txt
  • - draft-ietf-pwe3-pw-tc-mib-00.txt
  • No Request For Comments

    Current Meeting Report

    Minutes recorded by Jeremy Brayley

    July 14 PWE3 Working Group meeting (9:00AM - 11:30AM) Yokohama IETF54
    Protocol layering document - Stewart Bryant

    Do we need GRE and IPSEC as tunnel types?
    3 people using GRE, nobody using IPSEC
    Need GRE text from those interested

    Fragmentation section to be updated with draft-malis-pwe3-fragmentation-00.txt

    Payload Type section 3.3 could use some help, MPEG expert needed

    Terminology - many docs have their own terminology section
    Scott Bradner - proposes standalone terminology document

    Work dependencies
    Need to sync up with PPVPN WG

    PWE3 Fragmentation and Reassembly - Andy Malis

    Fragmentation is required to send a frame larger than that supported by the PSN
    Want a single set of Fragmentation/Reassembly procedures rather than specifying
    the procedures in each PWE3 service draft

    Procedures adopted directly from RFC 1990 MLPPP
    Also used by FRF.12 and ATMF FAST
    Bit usage inverted from RFC1490
    Therefore not-fragmented packet looks the same as a packet from a PE that
    doesn't implement fragmentation
    Signaling additions - New VCFEC element parameter ID to signal the ability to
    reassemble fragments
    Two new L2TP AVP pairs

    Scott Bradner - questions why reassembly is optional. He believes it should be
    mandatory or not used at all
    Andy - PSN MTUs are typically limited to 9K bytes
    Scott - The question of whether to signal the ability to fragment and whether to
    implement fragmentation are orthogonal
    If mandatory to implement, you can still use slowpath even if it doesn't work

    [Comments from mailing list]

    I don't think this quite reflected the exchange, although Scott was quoted

    My primary point in the discussion was that I personally had no problem with
    Scott's suggestion that reassembly be made mandatory, even though the specified
    signaling is pretty simple.

    Other speakers disagreed and felt that the ability reassembly shouldn't be
    required, and that the signaling should be retained. As I recall, the conclusion
    was to take the discussion to the list.

    -- Andy Malis

    [End Comments from mailing list]

    Mark Townsley draft-townsley pwe3-l2tpv3-00.txt

    Overview of l2tpv3
    Difference between LAC and LNS
    includes encapsulation (sessionid-cookies-flags- 24bitsequencenumber)

    PWE3 document organization discussion
    Mark proposes that PWE3 should generate the following documents in a hierarchy
    pwe3 requirements --------> pwe3 Framework and
    Protocol layering

    Pseudo wire documents --------> pwe3 mibs
    (fr, eth, hdlc) (fr,etc,hdlc)

    PW over MPLS PW over L2TP/IP
    (fr, eth, hdlc) (fr, eth, hdlc)

    [Clarification from mailing list]

    Just to be precise, the PWE MIB documents fit into the following picture (as
    described in the Framework):

    pwe3 requirements --------> pwe3 Framework and Protocol layering

    Pseudo wire documents --------> pwe3 mibs
    (fr, eth, hdlc) (fr,etc,hdlc)
    PW-VC MIB (for general PW VCs)
    / \
    PW over MPLS PW over L2TP/IP
    (fr, eth, hdlc) (fr, eth, hdlc)
    PW over MPLS MIB PW over l2TPv3 MIB (TBD)

    --Tom Nadeau

    [/end from mailing list]

    ????- how about a single document for MPLS and a single doc for L2TP?
    then PW specific documents can refer to a field defined in these docs like
    "these bits go into the flags field defined in the PW over L2TP doc"
    Luca - ordering should be reversed
    Scott- should PW over MPLS and L2TP have any fr, eth, hdlc specific info at all?

    open issues
    more terminology necessary for TDM emulation
    need specification of CAS and CCS
    Channel associated signaling and common channel signaling
    need synchronization reference model
    should requirements for SONET/SDH emulation be added?

    Danny- This should definitely become a WG document
    Should it be folded into the current requirements document?
    Scott- fundamental question is whether we should try to emulate technology
    exactly or point out what is different
    Emulation is not necessarily useless even if it doesn't meet every application's
    Yaakov - want to fold these requirements into TDM documents since some of these
    requirements are very specific to a particular TDM application

    TDMoIP Real world issues - Yaakov Stein

    RAD - over 9000 TDMoIP ports deployed
    Market wants average of 4 E1/T1 ports per edge device
    Less than 1% of ports were E3/T3
    The point is that T1 level emulation is a more appropriate problem to solve

    School districts began using voice over IP, but they didn't like voice quality
    and delay
    RAD replaced VoIP with TDMoIP

    >90% of access network is CAS (PBX interconnect)

    Kireeti - Makes the comment that Yaakov's presentation is too much
    marketing for his taste
    Scott - Asks Yaakov to concentrate on facts

    AAL1 - requires high reliability
    AAL2 - useful for toll bypass, people don't expect high-reliability -ex. point
    of sale applications

    Cellular telephony
    Requires 50ppb clock accuracy - will RTP really work here?

    Scott - Maybe 50ppb should not be a design group goal, maybe PSN should not be
    used for some applications. It is not the PWE3 group's goal to define procedures
    to support every application.

    Yaakov 50ppb can be done, but requires a lower layer mechanism different from

    Ray Jangar? (PMC Sierra) - TDM over IP is a real requirement - seeing
    requirement heavily in Asia

    CESoPSN update - Sasha Vainshtein

    Control word aligned as much as possible with draft-malis-pwe3-sonet-03
    Structure pointer is always 0

    Will emulated CE to CE service experience prolonged outage if an occasional
    CESoPSN packet is lost?
    No for both structured and unstructured modes, but for different reasons...

    Convergence issues
    Common applicability statement and control word with draft-pate
    (CEP) CESoPSN vs TDMoIP (draft-anavi)

    [Comments from mailing list]

    I have said that both are common with draft-malis (CEP) and draft-pate (CEP-VT),
    and that the commonalities, as well as certain partitioning of the application
    space will be presented by Ron.

    > CESoPSN vs TDMoIP (draft-anavi)

    I have said that merging TDMoIP "unadapted" format (introduced in the latest
    release of draft-anavi) should be simple, but the issue with the AAL1/AAL2-based
    ("adapted") formats remains open.

    -- Sasha Vainshtein

    [End comments from mailing list]

    Extending SONET/SDH CEP for low rate signals - Ron Cohen

    This draft extends draft-malis to SONET VT1.5/2/3/6 and SDH VC-11/12/2 but with
    no extension to its applicability statement
    It adds bandwidth saving modes

    ??? - Why add vt3, vt6 since they are not used in the real world?
    Ron - agrees, but vt3 and vt6 come for free

    [Comments from mailing list]

    TDM Common Applicability Statement - Ron Cohen

    common to:

    -- Ron Cohen

    [End comments from mailing list]

    fidelity of emulated TDM services
    fault isolation and performance monitoring
    PSN considerations - path MTU, bandwidth saving modes

    P2P PDH emulation
    MP2MP SONET/SDH emulation
    draft-malis-pwe3-sonet-01.txt does STS-1 and above
    draft-pate extends to VT level
    MP2P PDH to SONET emulation

    common applicability statement

    Andy Malis - Frame Relay draft
    no slides - We have seen the presentation too many times already
    Have reached agreement on encapsulation
    Must decide how to organize documents (1 doc, 2 docs ?)

    [Comment from mailing list]

    I said that the discussion at this point is strictly editorial on document

    -- Andy Malis

    [End Comment from mailing list]

    ITU developments in ATM encapsulations SG13 -Ghassem Koleyni
    ATM-MPLS Network Interworking
    ITU has agreed on a compromise that allows both "Martini" style encapsulations
    and ATMf style encapsulations

    Two cell modes
    one to one mode (based on ATMF cell mode - includes VCI present bit, PTI,CLP)
    N to one mode (original Martini encap - includes VPI/VCI,PTI,CLP)
    Frame modes
    AAL5 PDU
    AAL5 SDU

    Ghassem shows the encapsulation for each mode

    ITU has produced two documents
    cell modes defined in Y.atmplsC
    frame modes defined in Y.atmplsF

    Stewart - why are the control words different?
    Please repeat part about security
    Ghassem - OAM security cell needs to be sent right away, can't re-order these
    admin cells with user cells
    Danny - wants to see compromise encapsulations posted to mailing list
    Ghassem - people involved should get together this week to combine drafts
    Scott - it has been a problem in the past when multiple standards bodies come up
    with solutions to the same problem - random movement of bits is not a good idea

    Discussion of Martini ATM and Ethernet drafts - Luca Martini
    changes since 00
    merged draft-martini-atm-encap-mpls-00 and draft-brayley-pwe3-atm-service-01
    added appendix about defect handling
    cell port mode moved to appendix
    removed AAL5 PDU mode, will put it back in based on draft-fischer
    added applicability statements

    Will merge content with draft-fischer-pwe3-atm-service-02

    merged draft-so-pwe3-ethernet

    ??? - Why two modes? One strips vlan from packet before sending on the tunnel
    and one keeps VLAN tag
    Luca - Most vendors use VLAN tag mode since it is easy to implement on routers.
    The goal is to produce encapsulations that most vendors are able to implement
    Stewart and Mark Townsley - use principle of minimal intervention and keep VLAN
    tag, don't strip the VLAN tag
    Scott - at minimum we should have one required mode
    Ragu - why is this different from FR encapsulation?
    Kireeti - Ethernet switches don't switch VLAN tags but FR switches do switch

    Discussion of draft-martini-l2circuit-trans-mpls-09.txt

    Add requirement for VLAN translation at egress (currently an option)
    Move IANA considerations to separate document

    Scott - Split references for normative and non-normative references in documents

    Other items
    need to provide inter-domain solution
    IANA guideline document

    Kireeti - Should this work be done in PPVPN or PWE3? (exchanging VC labels)
    Danny - Endpoint discovery is PPVPN, signaling setup and maintenance is PWE3
    Kireeti - Why is VPLS in PPVPN and not in PWE3?
    Scott - We have been assuming that all circuit establishment is in PWE3
    Scott - What is different at byte level between intra- and inter-domain PW
    Luca - byte level is not different but maintenance is different one domain
    should not be able to establish circuits across another domain

    Danny - please reword documents to align with protocol layering documents - most
    are not
    Danny - Security considerations are currently very weak - must be addressed or
    docs will not be progressed

    Scott - Hackers are really interested in seeing wide-area layer 2 networks
    Kireeti - It is sad that we have converged on a single encapsulation because we
    could make the hackers guess at which mode is being used!
    Scott - This is called security through obscurity...

    Meeting adjourned at 11:15.


    Extending SONET/SDH CEP for Low Rate Signals
    TDM Common Applicability Statement
    TDMoIP Real - world issues
    ATM and Ethernet Encapsulation
    Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks
    PWE3 Protocol Layering
    An Update on CESoPSN
    PWE3 Protocol Layering
    ITU-T Compromised Solution on ATM - MPLS NETWORK INTERWORKING