Current Meeting Report
Jabber Logs

2.8.12 Pseudo Wire Emulation Edge to Edge (pwe3)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. 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-tc-mib-00.txt
  • - draft-ietf-pwe3-pw-mpls-mib-00.txt
  • - draft-ietf-pwe3-sonet-00.txt
  • - draft-ietf-pwe3-sonet-vt-00.txt
  • - draft-ietf-pwe3-ethernet-encap-00.txt
  • - draft-ietf-pwe3-control-protocol-00.txt
  • No Request For Comments

    Current Meeting Report

    Minutes Recorded by:
    Meeting opens at 13:00.
    Administrivia - Danny McPherson
    Working Group Document Status: 
     o Requirements went through WG Last Call.  Several comments from WG, ADs 
    and others added.  Redo of WG Last Call Dec '02.
     o Framework, Protocol Layering and Terms documents have been  folded into 
    architecture.  Makes sense to be in one place. 
       WG Last Call Dec '02.  
     o Fragmentation document hasn't had much feedback. Chair doesn't think it is 
    contentious.  WG Last Call Dec '02.
     o Ethernet: WG Last Call for March. A few editorial and semantics 
     o Transport: Luca Martini will talk about this
     o SDH/SONET is on hold at the moment. Issues to be discussed with 
    Miscellaneous Comments from Chair:
     o ADs are concerned that we must address congestion.  Must have way to 
    detect PW packet loss.  Sequencing and length semantics will be put in 
    architecture document and some generic text added to discuss 
    congestion control with all service types will be added. 
     o Need Security considerations.
     o Terms must follow those defined in Architecture document and only 
    introduce new service-specific terms.  
     o There MUST be a default mode for each service.
     o TDM requirements will be in a separate document.
     o Quote from Allison Mankin: "MUST be a single default mode"
    PWE3 Architecture Draft - Stewart Bryant
     o This is the -01 version of the doc. Includes framework and Protocol 
    Layering and terms document. 
     o All comments received are incorporated.
     o Changed diagram to include RTP for MPLS.
     o Structured bitstream: needs framing. Agreed with TDM groups.
     o RFC3378 text in security section: Need to be aware that security risks 
    may be higher than on a native network.
     o Operation of IPSec is already explicitly called up
     o Will add an extra short section on congestion.  This is not payload 
    congestion, but how you prevent PWs causing congestion in the public 
    Internet. Take packet loss, apply metric, or shut down.
     o Control word: definition of common control word in architecture 
     o What is an Ethernet pseudo-wire?  PWE3 is consistent with PPVPN, more 
    complex models e.g. bridge, reside in PREP.
     o Terminology: At the last IETF we agreed a separate terminology 
    document.  There is now a consensus that we now delete the old term 
    draft. As a result of ITU-T work, need to tighten up on terms.
     o Requests comments on the document before last call
    Comments from floor:
    Sasha Vainstein: Does Ethernet mean multiple pseudowires are out of 
    Stewart Bryant: No, CE->PE is a LAN segment.
    Eric Rosen: If you want architecture document to have control word, then it 
    must be standards track
    Comment: In other groups, it has been made Informational/BCP
    Stewart Bryant: Will defer to Chair and ADs to decide on a status
    PPVPN L2 Signalling --  Eric Rosen
     o Presented in PPVPN yesterday
     o L2 VPN framework and PPVPN architecture aligned in terminology. 
     o Signalling connections 2 forwarders. Two forwarders are connected by a PW 
    using Martini signaling. Each forwarder independently initiates LSP.  
    Problem: presupposes provisioning model. Each PW individually 
     o No support for other PPVPN provisioning models. No integration with 
    L2VPN auto-discovery.
     o Solution: Generalise method of identifying remote forwarder. Allow 
    either forwarder to be the initiator, other to be the responder.
     o Martini signalling (PWE3 Transport/Control) currently doesn't have 
    provisions for this.
     o A number of examples and associated problems shown:
        Example 1: VPLS. Forwarders ID'd by VPN-ID. Current VPLS proposals 
    reuse martini VCid field as VPN ID.
        Example 2: Distributed VPLS.
        Example 3: VPWS full mesh model.
        Example 4: switched connections. E.g. ATM SVCs to PWs.
     o Going forward: ensure PWE3 signaling is general enough for PPVPN to use 
    (PWE3 draft?).  Specify use of PWE3 signaling for various 
    provisioning models (PPVPN draft?).
    Mark Townsley: Current L2TPv3 spec includes identifier that is not tied to 32 
    bit. This would match that well, so He supports it.  Hamid 
    Ould-Brahim: Good, it will be better to use globally unique 
    identifiers instead of BPN-ID since we already have one format for VPN-ID 
    that is standards-based (RFC2685).  Doing that will avoid the 
    proliferation of multiple formats for VPN-IDs that need to be 
    Rahul Aggarwal: The comment I made was that we have to consider whether 
    these signaling extensions should be defined in PWE3 or PPVPN.  The BGP 
    PW/VPLS signaling extensions are not being defined in PWE3.  Hence I said 
    its not clear whether these should be or should not be defined in PWE3. 
    Eric Rosen: PPVPN is prohibited from defining protocols. This group is 
    defining protocols, and PPVPN model is based on PWs, so should rely on the 
    PWE3 sig mechanisms RE: sounds like PWE3 should set up PWs.
    Luce Martini: We are chartered to have maintenance protocol. Pt-pt, 
    simple. Including some extensions for PPVPN isn't a problem, but I don't 
    think we should consider all of the PPVPN designs here.  Would like to 
    receive comments from WG on including this. Not a bad idea, but still it is 
    pt-pt oriented.
    Mohan: Some of these extensions fit very nicely.
    Chair: In favour. Trivial to define semantics of extensible 
    attributes to assist PPVPN in defining deployment scenarios, etc...
    Marco Carugi: PPVPN wil clarify functional blocks for sig. DT will work to 
    clarify.  Which info we want to carry for different models.  For LDP, 
    being done with same people in 2 groups.  Doesn't mean this is the 
    proposal.  Group doing protocol should define how. This seems a clear way to 
    proceed.  We want same sig for pt-pt and for VPN models.
    PW Management Discussion -- David Zelig
     o Provides a brief update. Shows general concept of the generic MIB.
     o Connected to service layer MIB and PSN layer MIBs.
     o PW_BIB is Very stable. No change from last IETF.  Waiting for control 
    plane last call.
     o PW MPLS MIB is very stable. 
     o Ethernet MIB is just a WG item. 
     o ATM MIB just expired. Needs to be respun. 
     o PW CEP MIB: did cleanup of unused objects.
     o Summary: MIB Implementation experience exists but needs more inputs.
     o Future additions: Notifications, use cases, and cleanup based on 
    implementation experience.
     o Frame relay coming soon
     o Good timing for MIB doctor review.
    TDM Design Team Update -- Tom Johnson
     o Deadlock for about 2 years now. Design team was put together to solve 
     o Agreed: Max Riegel's Requirements draft will be progressed for going 
    forward.  New revision by end of year.
     o Proposed compromise between 3 TDM drafts. There will be two drafts, one 
    for structured and one for unstructured mode.  Asking for those to be 
    accepted as WG items.
     o All drafts will be aligned in terms of language, etc. Want to put 
    together a common framework.
    [Clarifying notes from Tom sent to chair in follow-up email]
      1) A TDM design team was formed to address the TDM emulation issues.  The 
    team is comprised of
            Max Reigel
            Prayson Pate
            Sasha Vainshtein
            Shahram Davari
            Tim Frost
            Tom Johnson
            Yaakov Stein
        The team has held several phone conferences and one 
    face-to-face meeting.
      2) A requirements doc will be developed that defines all of the 
    requirements for TDM and SONET/SDH Emulation.  The document will be based on 
    raft-riegel-pwe3-tdm-requirements-00.txt".  A new revision will be 
    available by the end of the year.  The DT requests that the updated 
    document be accepted as a WG item when it becomes available.
      3) A compromise proposal has been reached between the competing TDM 
    draft authors.  The updated drafts will be released to the WG by the end of 
    the year, and the DT asks that the WG consider the updated documents for 
    acceptance as WG documents when they become available.
      4) Going forward, the DT has agreed that all of the TDM drafts will be 
    studied for commonality.  The first step will be to align sections and 
    language between the various TDM drafts.  And, if it makes sense, we will 
    consider the possibility of creating a TDM architecture document to hold the 
    common language and terminology.
    [End Notes Sent in Follow-up Email]
    Transport of ATM AAL1/2 frames over PSN -- Shahram Davari
     o Briefly discussed the compromise in TDM, deferred details to later 
     o Proposes for PWE3 to adopt TDMoIP Anavi draft.
     o Applications: Leased line, private line, toll bypass.
     o Need to reuse as much as possible existing technology. AAL1 is a 
    proven technology, available in both hardware and software. 
       Has a number of desirable features, which are listed.
     o There is also a need to interwork with ATM. Carriers use ATM CES in 
    their network. Simple and inexpensive to use ATM SAR at ATM and IP/MPLS 
     o Slide showing how TDMoIP and ATM CES Interwork.
     o "Any Service and Port (ASAP) is an important architecture."
     o Current Any Service Any Port (ASAP) support with AAL1.
     o Easy to upgrade to IP/MPLS CES from current Any Service Any Port 
     o TDMoIP is based on proven AAL1 technology. Off the shelf 
     o Interwork seamlessly with ATM.
     o Asks WG to adopt TDMoIP.
    Chair: Take proposal to mailing list.
    Unstructured TDM (Sasha Vainshtein)
     o Presents motivation:
       - Many transport applications carry entire TDM stream 
       - An evolution of unstructured approaches presented earlier in 
    draft-vainstein-cesopen-03 and draft-anavi-tdmoip-04.
       - Simple enough to overcome differences.
       - Supported by editors in separate drafts.
     o Scope: all unstructured services, except unstructured SONET/SDH.
     o Encap has been aligned with SONET/SDH.  RTP is part of the header.  
    Control word is mandatory.
     o Two modes of timestamp generation.
     o Procedures updated to handle local handling of lost packets.
     o Payload is carried as captured. Two payload sizes.
     o Issues: default payload size value is not yet specified.  DT is 
    considering a compromise based on solutions for 
    Steve Casner: Is this consistent with AAL framing from previous talk?
    Sasha V: this draft accommodates unstructured AAL1 attachment 
    Steve Casner: Does this proposal meet the agreement that previous talk 
    Sasha V: we are working on details of compromise. This proposal is part of 
    the compromise.
    Dave McDyson: Glad for compromise. I am unclear specifically what you are 
    Chair: Actual text of compromise is not in these drafts.
    Explanation of TDM compromise -- Yaakov Stein
     o Previous draft is an unstructured draft only.  The TDM design team 
    initially felt that this might be progressed more easily.  Problem is that we 
    had no mandatory mode and the ADs are insisting that we have one clear 
    "MUST" mode.
     o There will be 2 TDM drafts: 
       Unstructured TDM (where unstructured means arbitrary bitstreams at TDM 
    rates or structured TDM but when this structure has no impact on 
    transport mechanisms)
       Structured TDM
      For the unstructured TDM draft the mandatory mode is CESoPSN with full 
    frames.  There are two optional modes: 47*N & 193 bytes per packet.
      For the structured mode TDM draft the mandatory mode is TDMoIP with AAL1 
    and there are two optional modes:  AAL2 & CESoPSN with full frames.
    Sasha V: correction. There are 2 not 3 main modes in structured TDM.  
    Yaakov has correctly relayed compromise.
    Issues with Control Word & Packet Loss -- Yaakov Stein
     o Presenter claims the intention matches well with the AD's desires.
       Control word has:
        - Sequence number
        - Payload dependent flags
        - Packet length
        - Fragmentation
        - Payload type
     o We actually have 3 types of control word:
        - Martini CW
        - CEP Header
        - Fischer CW
     o Why 3 formats: Different services have different requirements, but 
    primarily different groups wrote different drafts and different 
    existing implementations.
     o Proposal: CW should be based on Martini draft.
    Ron Cohen: don't understand motivation.  Really disagrees.
    Mark Townsley: When running over PSN, there should be one control word.
      There is point of first nibble. The martini definition is very 
    friendly to existing P routers.
    Yaakov Stein: Agrees and should deal with this
    Ghassem Koleyni: Martini is compatible with ITU-T
    Sasha Vainstein: Not sure we can force one control word structure.
    Chair: ATM mode is the only one that employ Fischer CW format and it's 
    optional there.
    Comment: Are you proposing that we have 2 types of sequence number: one 
    that wraps to 0 and one that doesn't?
    Chair: Indeed Martini wraps to 1 and RTP wraps to 0.  Martini 
    reasoning for this is so that 0 represents "no sequencing enabled" but 
    field is always present in CW.  We'll try to make this less confusing in the 
    architecture document.
    Effects of Congestion -- Yaakov Stein
     o PWE3 needs to take congestion into account. Presenter shows effects of 
    packet loss on voice quality.  Packets contain info from lots of 
    different voice channels.  
     o Graph comparing different techniques.  Packet loss concealment can be 
    built into VoIP.
     o Proposal: When structured TDM is transported the encapsulation must be 
    able to easily support replay. Implementations should provide 
    Chair: Perhaps this needs to be in the requirements for TDM.
    Sasha Vainstein: Unstructured TDM can safely reply previous packets 
    provided that the packet payload size is a suitable multiple of the frame 
    size of the original circuit. This corresponds to one of the methods 
    described in the draft.  Other methods (linear interpolation, 
    statistical) really require structured TDM. [Email correction from YJS:  
    Even in the unstructured mode one can do replay if full frames are used]
    Steve Casner: In the structured case you assuming that it is all voice?
    Yaakov Stein: Yes, for data there have to be higher layer protocols to 
    address packet loss.
    Steve Casner: Do you pass an error?
    Yaakov Stein: As long as loss is good enough for toll voice, this is not 
    Stewart Bryant: If this is deemed of value after peer review, why not 
    progress as informational or best practice?
    Chair: Take proposal to mailing list please.
    Bi-directional LSPs for classical MPLS -- Rohit Dube
     o Previously presented at MEF and MPLS WG.
     o Presents definition for Bi-directional and symmetric LSP.
     o Benefits: Good fit for both PWE3 and MEF EVPL.
     o Better manageability.
     o Shows RSVP-TE extension required.
     o CSPF extension shown.
     o Proposal extends LSP setup mechanism.  Fits in MPLS WG and 
    presented to PWE3 for information.
    Chair: Thanks for sharing...
    Header Compression Drafts -- Jerry Ash
     o Motivation: carriers evolving to converged MPLS backbone with VoIP 
    services.  Enterprise VPN services with VoIP.  Legacy voice migration to 
     o Requirements are presented: needs efficient voice transport.
     o Support voice encoding. 
     o Compress/decompress header using cRTP or simple algorithm, operate in 
    2547 VPN context, and be scalable.
     o Proposals: steps for method 1: 
        - use RSVP to establish LSPs between CE1-CE2. 
        - Use cRTP (or simple HC) to compress header at CE1, decompress at CE2
       Steps for method 2:
        - use RSVP to establish LSP between PE1-PE2
        - use cRTP to compress header at CE1, decompress at CE2
        - PE1 & PE2 create 'SCID routing tables' and perform 'SCID 
    switching' for compressed packets (SCID --> MPLS labels).
     o Why PWE3: seems best fit, but not within current charter.
     o Review of Implementation issues, and changes to protocols.
    Stewart Bryant: Whilst I am sympathetic to the need for a home for this 
    work, it does not fit here, because it is radically different from any 
    pseudo-wire type we are defining.
    Steve Casner: Comments recorded but clarified in the following email:
       [Steve's clarifications via email:  The proposed work is not an 
    extension to 2509, rather it is parallel to 2509.  2509 specifies 
    signaling and packet type indication for PPP; as I understand it, the 
    proposed work specifies signaling (via RSVP) and setup of packet type 
    indications in MPLS.
       As I said in a post-meeting chat with Jerry, I think MPLS makes the most 
    sense since RSVP-based signaling is discussed there, and clearly the 
    MPLS-specific aspects fit there.
       The bigger question is whether it is feasible to implement cRTP on the 
    line cards that are handling packet forwarding for MPLS tunnels.]
    Chair:  Still need to discuss if/where this fits with ADs.
    Any-MPLS Interworking in ITU-T -- Ghassem Koleyni
     o Report on what happened in ITU-T in last 2 weeks. 
     o Agreed last time to incorporate Martini modes into ITU-T 2 cell modes: 
    1-1 and N-1.
     o On cell modes, document sent for approval.
     o Reference diagrams shown for 1:1 and N:1 shown along with 
    encapsulation formats.
     o Voice over MPLS is also being discussed.
     o All referenced documents can be found online (IETF participants have to 
     o A liaison statement was sent to IETF explaining this.
    Progress Update for ATM, Ethernet, Control Draft -- Luca Martini
     o ATM Draft is a merging of the ATM drafts (draft-martini, 
    draft-koleyni, draft-bocci) for cell modes and AAL5 modes.
     o We met in this IETF and agreed to some changes to the first 
    encapsulation document. 
     o We want to make one applicability section. Lots of editorial work.
     o Remove MTU, sequencing, introduction terms/diagram, leave to 
    architecture document.
     o Agreement to make N-to-one cell the only mandatory mode.
     o Ethernet draft: Single mode for Ethernet encapsulation. 
        Todo: - remove control word sequencing, length. 
              - Remove appendix. 
              - WG last call.
     o Control Document: Since 00, refs updated, VLAN Request interface 
    parameter.  TODOs:
        - Considering protocol extensions 
        - New TLV for PW status
        - New TLV for IP address will be in separate document in PPVPN
        - congestion control, seq, length will be put in arch draft 
    Rahul Aggarwal: Ethernet: you mean encap, not PW type? 
    Luca: Yes only one encap. 2 PW types but one encap.
    Mark Townsley: Ethernet and control draft, a good amount of 
      ATM document still has a lot to do.
    Chair: applicability statements will determine the modes.
    Rahul Aggarwal: There should be no such thing as mandatory and not 
    Chair, agree: but unfortunately, this is the real world and we've made lots 
    of progress.  It's far better than where we were.
    Craig White: should remove non-implemented modes from the drafts.
    Meeting Adjourned.


    PWE3 Architecture
    End-to-End VoMPLS Header Compression
    TDM Agreement
    PWE3 ATM, and Ethernet encapsulation PWE3 Control Protocol Updates
    Bi-directional LSPs For Classical MPLS
    Signaling: Identifying PW Endpoints
    Pseudo-Wire Emulation Edge-to-Edge MIBs update
    Why PWE3 Should Adopt TDMoIP
    End-to-End Header Compression
    Any - Mpls Network Interworking In ITU-T SG13
    Unstructured TDM over PSN