2.3.17 Pseudo Wire Emulation Edge to Edge (pwe3)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-07-23

Stewart Bryant <stbryant@cisco.com>
Danny McPherson <danny@tcb.net>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.com>
Technical Advisor(s):
Mark Townsley <mark@townsley.net>
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/web/pwe3/index.html
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
Done  Accept drafts of service-specific documents as WG items
Done  Requirements Document Last Call
Done  TDM Circuit Documents Last Call
Done  ATM Documents Last Call
Done  Ethernet Documents Last Call
Jan 04  Fragmentation LC
Jan 04  TDM Requirements LC
Feb 04  SONET Documents Last Call
Mar 04  TDM Documents Last Call
Mar 04  PWE3 WG Charter Review, Additional Work or Ends
Apr 04  Frame Relay Documents Last Call
Apr 04  PWE3 MIBs Last Call
Apr 04  SONET Documents Last Call
Apr 04  FCS retention Last Call
May 04  VCCV Last Call
  • - draft-ietf-pwe3-requirements-08.txt
  • - draft-ietf-pwe3-pw-mib-05.txt
  • - draft-ietf-pwe3-pw-mpls-mib-06.txt
  • - draft-ietf-pwe3-pw-tc-mib-05.txt
  • - draft-ietf-pwe3-sonet-08.txt
  • - draft-ietf-pwe3-ethernet-encap-07.txt
  • - draft-ietf-pwe3-control-protocol-08.txt
  • - draft-ietf-pwe3-cep-mib-05.txt
  • - draft-ietf-pwe3-enet-mib-05.txt
  • - draft-ietf-pwe3-arch-07.txt
  • - draft-ietf-pwe3-fragmentation-05.txt
  • - draft-ietf-pwe3-frame-relay-02.txt
  • - draft-ietf-pwe3-atm-encap-06.txt
  • - draft-ietf-pwe3-tdm-requirements-05.txt
  • - draft-ietf-pwe3-iana-allocation-05.txt
  • - draft-ietf-pwe3-hdlc-ppp-encap-mpls-03.txt
  • - draft-ietf-pwe3-vccv-03.txt
  • - draft-ietf-pwe3-satop-01.txt
  • - draft-ietf-pwe3-fcs-retention-01.txt
  • - draft-ietf-pwe3-cesopsn-01.txt
  • - draft-ietf-pwe3-tdmoip-02.txt
  • - draft-ietf-pwe3-satop-mib-02.txt
  • - draft-ietf-pwe3-tdm-mib-01.txt
  • No Request For Comments

    Current Meeting Report

    Pseudo Wire Emulation Edge to Edge (pwe3)

    MONDAY, August 2, 2004 (1530-1730)

    CHAIR: "Danny McPherson" <danny@tcb.net>
    "Stewart Bryant" <stbryant@cisco.com>

    MINUTES: Matthew Bocci matthew.bocci@alcatel.co.uk

    SLIDES: Available at http://pwe3.tcb.net/meetings/ietf60/index.html


    WG Document Status & Charter Update:
    Danny McPherson danny@tcb.net & Stewart Bryant <stbryant@cisco.com>

    Shows slides on WG document status

    These will be posted to the mailing list. Requirements and architecture are in RFC editor queue.
    Waiting on some documents:
    TDM reqs, ATM encap, SATOP, sent to IESG
    FCS retention needs update then sent to IESG.
    WG last call: Frame Relay and cesopsn
    Work in progress: MIBs are going in parallel with other specs

    Tom Nadeau: the 1st 3 docs + ethernet MIB and ATM should be ready for last call after meeting
    Danny McPherson: please send comments to Tom. Most been around for a while
    Andy Malis: Asked several times for cell transport draft to become WG draft.
    Danny: noted, OK

    Charter Update (ppt)
    Danny: We have moved to the Internet area. Tom Narten is primary AD and area advisor. Margaret Wasserman is other AD.
    Stewart: Proposed charter sent to Tom. Waiting for comments. Rewritten text. No work items have been removed, but some new ones added to regularise what we were doing, and in response to suggestions from the list.
    - Allows more than one emulation for a service (e.g. ATM)
    - HDLC/PPP
    - OAM
    - Transparency
    - ECMP

    - Including users as well sas SPs
    - Interconnections between different PWS and the same PWs
    - IP PW
    - Congestion

    PW Control Word & MPLS BCP: Stewart Bryant & Danny McPherson

    MPLS PW control word.
    Control word removed from PWE3 architecture at request of IETF. George swallow has a BCP draft addressing ECMP
    Control word draft shows how to address ECMP in PWE3
    Explains preferred control word.
    IANA considerations for 1st 4 bits: 3 ranges
    - Reserved
    - PW standards track
    - Experimental / vendor specific
    Registry is a catch-all.

    Tom Nadeau: do we have 2 PW types?
    Stweart : will regularise text between the two
    Sahsa Vainstein: Current PWE3 draft specifies IPv4 and IPv6 types. What is proposed if you don't use these for VCCV?
    Stewart: Setup a dictionary for PWE3. VCCV is VCCV's issue
    Sasha V: May be resolved by allocated special values for VCCV payloads. A
    Rahul Aggarwal: need to go back to VCCV document and make sure these things match
    Mustapha Aissaoui: problem is that we use identifier for both control plane and data plane identifier. We have to understand how we differentiate and signal the two. In some cases may need control word for both data and control planes. General idea of a registry is good.
    George swallow: If you want to use OAM with control word, you signal it and it uses all zeros. Otherwise you have to signal one of the other needs.
    Dave Allen: PID avoids gratuitous complexity. Be careful.
    Tom Nadeau: This is the same PW type as control plane setup. When we need a CW with PW type, will use same registry
    Dave Allen: Seems like a new way to signal IP. seems complex
    Danny: we have PWE3 registry for specific purpose. Ther eis still only one.
    Stewart: have to ask if this can become WG draft
    Danny: send to list and look at Georges draft too.

    PWE3 OAM Message Map: Thomas D. Nadeau tnadeau@cisco.com

    Changes: aligned with WG input (any-to-any), Aligned with draft-aissoui-l2vpn-vpws-iw-oam-01, aligned with MPLS/ATM/FR Alliance OAM documents
    Trying to work with other groups and not redefine anything
    - Timing synchronisation between protocols
    - End to end vs. partitioned loop model
    Does anyone care about end-to-end model?

    Dave Allen: yes
    Tom: why?
    Dave Allen: with end to end, don't care what the notification method is in any particular AC. In partitioned case, I'm note sure this is true. Want to discuss this with other authors
    Rahul Aggarwal: Agrees with point Dave made. Transparent OAM end to end, and second is where you break down end to end OAM from PE to CE, PE to PE, etc. Need to break down both.
    Yakov Stein: both models have justification: trail extended vs. trail terminated.
    Mustapha Aissaoui: Draft currently has both models used in specific contexts. Less of an issue with this draft, more of an issue with draft-aissaoui. Plan to discuss on the mailing list.

    - Congestion
    Do we need to add congestion control like counting lost packets
    Danny: need a problem statement, but in priciple yes
    Tom: leave a placeholder
    George Swallow: just sets up control channels for this.

    Tom: need to get document to the ID repository. Sorry, were a little late. Also need to include Ethernet OAM over MPLS mappings
    Didn't change title, but this is an open question. Respond on mailing list. We are fairly close to what we want.

    ITU-T Update: Thomas Walsh tdwalsh@lucent.com
    Andy Malis presents.
    Liaison is available online at IESG liasons site.
    X.84 text online at: see slides for URL
    Approved for publication in March 2004
    Completely based and aligned with PWE3 FR draft, plus some optional stuff for end to end PVC status signalling
    Needs some IANA actions: FEC128, FEC129, and status code points. Several liaisons have asked for this to be formalised
    Current IANA procedures, as long as it is in 1st come 1st served space, can do allocation while it is still an ID.

    Tom Narten: Not just the code points, but also needs the drafts to be approved. IANA cannot hand out code points for a registry that doesn't exist.
    Sasha Vainstein: is not the allocation of the PW type also needed? This is in FEC 128/129
    Andy: That's true
    Luca Martini: No problem: status TLV code points are not reserved
    Andy: So really need to get these documents done. FR draft has completed editing at v03, but not in time for this IETF. Is on PWE3 WG server.
    Yakov Stein: SG 13 approved Y.1413, TDM PW document. Contains 3 drafts here.
    Danny: have not yet seen liaison from SG13, so would be good to follow up

    RSVP-TE for Multi-hop PWs: Rahul Aggarwal rahul@juniper.net

    Idea is to introduce a problem space, a solution, and get a discussion going.
    Single hop PW: a PW with only 2 PW demux allocation nodes
    Multi-hop PW: a PW with more than 2 demux allocation nodes
    - PWs across multiple domains
    Multiple IGP domains and multiple ASs

    - PW QoS
    SLA with emulated service: signalling QoS parameters such as BW, interface types etc

    PW redundancy
    - Primary PW and backup PW. Shares QoS resources with primary PW on common nodes. like secondary LSPs in RSVP-TE

    - explicit routing of PWs (QoS provisioning and administration)

    Why RSVP-TE:
    - look at entire picture, RSVP-TE provides required mechanisms. Especially of interest to providers running RSVP-TE
    No intent to pitch against LDP solutions. Simply saying that one solution doesn't fit all.

    Lists capabilities of RSVP-TE
    Overview of the mechanisms is given
    A few points:
    - Convergence requires QoS, multihop, and PW redundancy. PWE3 needs to look at all of these.
    PWE3 must look at all of these. We feel RSVP-TE fits the bill.

    Yakov Stein: anything that helps stitching is good. A few questions about RSVP.
    - Charter says cannot exert influence on underlying PSN. This sounds like we are forcing the PSN to give us something. Not sure how this works with different underlying PSNs.

    Rahul: Using RSVP for PW signalling. If underlying PSN signalling is RSVP TE, then its good. They are orthogonal issues.
    Luca Martini: that's not what the draft says. Nobody is preventing you from using RSVP TE with one tunnel per PW.
    Eric Rosen: Nobody would use one tunnel per PW. Could use BGP for setting up the PW ;-) We already have two ways to setup a PW. We need to understand what we can't do with existing protocols. No issue with QoS in the PSN (tunnel does this). Doesn't see what RSVP gives you here, or understand sharing of BW
    Rahul: need to TE the PW over several hops. Tell me how to do this with LDP?
    Eric Rosen: want to have some architecture to see what is missing from today's protocols and see the requirements.
    Rahul: once you want PW QoS you need this
    Kireeti Kompella: should we just do auto-discovery with RSVP, or LDP?
    Dimitri Papadimitriou: what prevents us from progressing enhanced requirements?

    Stewart: continue on the list

    PW Switching (Inter-provider/AS PWs): Luca Martini luca@cisco.com

    Trying to solve inter-domain PW problem.
    Slides show an overview of the problem.
    Sometimes don't want reachability info to be passed between providers, or you may have multiple PSN technologies.
    Proposes additional control plane between ASBRs, and between ASBRs and PEs
    Not meant to be a new protocol, or to make LDP scale better. LDP scales very well already; this does not have same issue as BGP.
    Illustrates differences.

    Peter Busschbach: So this is really for inter-provider communication. This is not clear in the draft. I like this for inter-provider. For intra provider, would have to configure switching points
    Luca: don't confuse auto-discovery with this. Configuration of this can be dealt with L2VPN draft.
    Peter B: This goes back to previous discussion. If inter-provider, this makes sense as you don't want to exchange all information. But, would be more comfortable if we had clear requirements. However, thinks RSVP TE draft makes more sense for intra-provider.
    Luca: Auto-discovery doesn't come with RSVP-TE. Can use BGP with this draft.
    Kireeti Kompella: We need requirements for stitching and for QoS for PWs before we go down the path of solutions. These are new aspects. Also, if you take LDP and add all these things, we get CR-LDP.
    Luca: unclear whether you need to actually signal the QoS. Most implementations don't use single sided signalling.
    Danny: take it to the mailing list. Need a requirements draft.

    PWE3 QOS Signaling: Himanshu Shah hshah@ciena.com

    Presents a list of requirements:
    QoS is an inherent attribute of the service
    Typically service delivery with a specific QoS is realised by configuring appropriate parameters.
    The sender of the PW FEC provides guidance for the receiving PE
    Should be backwards compatible with the existing LDP protocol.
    Explains the proposed solution.
    Can use the same mechanism for congestion notifications
    - Policing upstream would not make sense
    - This is not a QoS TLV, a traffic parameter TLV
    - Should not use for congestion indication
    - PW affects the traffic stream, to signalled parameters do not indicate this

    Dry-Martini: Ping Pan ppan@hammerheadsystems.com

    This gives a PW perspective to IP centric technology for Sub IP traffic
    An aggregation mechanism.

    Shows how dry this could be:
    Shows how you can aggregate through any

    Eric Rosen: clearly out of scope. This is PWs over no PSN.
    Ping Pan: No, PWs over any layer 2 network
    ?: ITU SG13 is working on this very problem: Ethernet over SDH etc
    Ali Sajassi: Are you doing the whole thing to save one label at the edge of the network? Don't need IP/MPLS in network.
    Luca Martini: Don't understand what you are trying to do. Do you want a statement as to what the PSN is? GMPLS? ATM?
    Ping Pan: Can allow any PSN
    Yakov Stein: Can't use TDM on it's own. You need something to get a packet across it.
    ?: For MPLS over SONET, can just use PPP
    Dave Allen: This is a valid scenario. PHP will replicate this behaviour. Control plane draft acknowledges this.

    CESoPSN and WG LC: Sasha Vainshtein sasha@axerra.com
    Reviews the main issues raised in last call, Reference PE architecture is clarified, simple vs. enhanced NSP
    Draft is now in last call after fixing issues raised
    Yakov Stein: Last 2 issues are questions of trail terminated vs. trail extended
    Sasha: want to do trail terminated
    Yakov: please add wording for which model you want

    TDM Extensions to PWE3: Sasha Vainstein

    Lists motivation for control protocol extensions.
    Setup of TDM PWs needs additional parameters, but these were not included in any of the encapsulation drafts.

    TDM PW over UDP and TDMoIP Updates: Yaakov Stein yaakov_s@rad.com

    UDP/IP issues (Yaakov Stein)

    Where should we put the PW label?

    Alternative 1:
    - destination UDP port should be a registered value
    - source UDP port number = PW label

    Alternative 2:
    - destination UDP port = PW label
    - need some protocol to distinguish PW

    Using the destination port number as PW label is problematic for NATs and firewalls.

    How do we distribute the label?

    Alternative 1:
    implicit upstream allocation (registered port at beginning)

    Alternative 2:
    unsolicited downstream, e.g. with tLDP
    Need a immediate decisions on where to put PW labels, and which label distribution method to use.

    Sasha Vainstein: Trail extended as the basic mode and optionally trail terminated based on using a DXC as an extended NSP.

    Yaakov: the combination of source and destination IP addresses serves as a tunnel.
    the UDP port number demuxes PWs inside that tunnel.
    Stewart Bryant: what are security implications of implicit method?
    Yaakov: no worse than telnet or tftp
    Eric Rosen: Do we need a third PSN? 
    Yaakov: yes, but widely deployed and arguably the first.
    Stewart Bryant: please consider this request from ITU-T as they have asked for an answer
    TDM updates (Yaakov Stein)
    trail terminated vs. trail extended OAM models
    performance OAM

    IP Pseudowire Encapsulation: Florin Balus <balus@nortelnetworks.com>

    Defines motivation and requirements for IP PW. PWs used for transport between unlike ACs, but traffic is known to be IP.
    Ensure consistent PW OAM. Maintain same datapath for OAM and data frames using IP PW
    Explains control word:
    IP header already has length and fragmentation fields, so don't need this and set to reserved.
    Pass the layer 2 discard priority bit using the D flag, signal FR congestion using B flag

    Any Malis: ARP mediation draft already covers this
    Florin: No it doesn't
    Luca Martini: RFC1332 is encapsulation for this
    Florin: control word moves this into the PW domain
    Luca: IP already has TCP, and QoS parameters.
    Florin: SP cannot touch IP header on PWs
    Ali Sajassi: jist is to take care of ECMP. This is one instantiation of control word draft. Can incorporate this in control word draft
    Florin: need to discuss on the list where this should go

    PWE3 Control Protocol Extensions: Mr. Cagatay Buyukkoc du.ke@zte.com.cn

    The presenter claims there is an issue of scaling when there are large numbers of tunnels.
    Introduces a reflector to reduce the number of T-LDP sessions from N^2 to N
    Extensions to LDP: simple relay mode where reflector participates in sinalling messages, but not in routing
    Second mode (next hop self mode) reflector participates in routing as well
    Explains the stitching points of the PW and an auto negotiation of the capability to support the reflector.

    Tom Nadeau: Is this basically another PW switching mechanism? Earlier consensus went a couple of ways, We need to write requirements. This could be one of several ways to do PW stitching.
    Cagatay Buyukkoc: can also be used for inter AS
    Stewart Bryant: please continue this on the list



    PWE3 WG Document Status
    PWE3 Charter
    PWE3 Control Word
    PWE3 OAM Message Mapping
    ITU-T SG17 Liaison to PWE3 on X.84
    Setup and Maintenance of PWs using RSVP-TE
    Pseudo-wire Switching
    PW QOS Signaling
    Dry-Martini: Run PWE3 over Any Sub-IP
    WG Last Call: Issues and Resolutions
    UDP PWs
    IP Pseudowire
    Scalable VPWS Network
    Updates in Setup of TDM Pseudowires