Current Meeting Report

2.7.13 Pseudo Wire Emulation Edge to Edge (pwe3)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 30-Oct-01
Danny McPherson <>
Luca Martini <>
Transport Area Director(s):
Scott Bradner <>
Allison Mankin <>
Transport Area Advisor:
Allison Mankin <>
Technical Advisor(s):
W. Mark Townsley <>
Mailing Lists:
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:
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
No Request For Comments

Current Meeting Report

Pseudo Wire Emulation Edge to Edge (pwe3)

Wednesday, December 12, 1300-1500

Chairs: Danny McPherson <>
Luca Martini <>


1300-1315 Administrivia (15 minutes)

Agenda Bashing
Blue Sheets
WG Document Status

1315-1325 PWE3 Protocol Layering Discussion
Stewart Bryant <>

1325-1330 PWE3 Framework Draft
Xipeng Xiao <>

1330-1335 PWE3 Requirements Draft
Prayson Pate <>

PWE3 TDM Drafts

1335-1345 Prayson Pate <>
Ron Cohen <>
David Zelig <>

1345-1355 Sasha Vainshtein <>

1355-1405 Discussion of TDM Drafts
Motty Anavi <>

PWE3 Ethernet

1405-1415 Tricci So <>

PWE3 Frame Relay

1415-1425 Clause Kawa <>

1425-1435 Stewart Bryant <>


1435-1445 Discussion of ATM Drafts:
Matthew Bocci <>


1445-1455 Tom K. Johnson <>

1455-1500 Wrap Up

IETF 52 WG Meeting Minutes

Recorded bv Richard Rabbat <>

Danny McPherson, Opening Slides:

WG Objective:

o Try to merge competing proposals where it makes sense.
o Discuss chartered services briefly
o Review current drafts and try to reach consensus
o Comments welcome -- please send to mailing list

Document Status:

Requirements document accepted as WG document, need comments from WG.

Framework document went to last call (to become WG document). Lots of comments, need to move to WG doc.

If writing service drafts, read charter, frameworks document and requirements documents before going forward to WG.

Martini drafts were submitted to RFC Editor to be published as Experimental. IESG considering what to do with document, looking for comments --

Xipeng Xiao: PWE3 Requirements Document

"Requirements for Pseudo-Wire Emulation Edge-to-Edge"

o current version is -02
o back in May, 00 version that got a lot of comments that were incorporated in 01, by London.
o very few comments since
o considered stable now

Changes with 01:

o organization of some sections:
- forwarding plane reqts
- control plane reqts
o most changes largely editorial
o feedback positive

In London IETF, people requested clarifications to be made to:

o packet ordering reqts: may be applied to control packets only or to both control and data packets
o pw's can be either MPLS LSPs or L2TP sessions
o added security consideration for use of non-path-oriented PWs
o cleaned up references
o request to add some mention in reqts of the kind of quality of service
o clarification: whether atm cells can be transported, or just frames

Q. what are the generic requirements?
Q. agreement to change faithfulness section

Q: in draft, when discussing L2TP 3, clarify whether it is L2TP 2 or 3
A: reference was change between L2TP 3 and 2

Q: wondering about deletion of IP
A: paragraph that if one wants to carry timestamp from one end to the other then use RTP.

Q: use IP underneath?
A:from chair: yes

CHAIR: please send any other comments to mailing list

Stewart Bryant: "PWE3 Protocol Layering"

Layering issues:

Current approach piecemeal: each payload design team has own solution

e.g.: ethernet and frame-relay, but not packet
e.g.: TDM services defining specific real-time support, requiring new packet services to define rt

Current layering approach diagram with current vertical stack approach.

Agreement on bottom layer up to IP v4, v6 and MPLS

Payload Framework:

o requesting generic types sent similarly on the wire shim-layer for specialist teams to design including bit-specific, cell-specific and packet-specific info payload commond support
o suggest common timing/sequencing layer, maybe working with the RTP folks

Proposed Protocol Layering

o focus of pwe3: above common multiplexing layer
o also suggested an alternative layering model agree to have common structure above the RTP layer switch the order of some layers. refer to diagram on slides


o layering model be incorporated in the PWE3
o framework draft move to generic, rather than individual payload types
o send payload transparently rather than intermediate format, making translation for switch support a value-added service
o we define operation of PWE3 over IP and MPLS separately

Comment: reference model has value

Q: the RTP timing requirements are quite different for services like sonet vs. atm. with RTP-like timing mechanism, may add too much overhead and rtp may not be adequate for service jitter

A: one payload team has used RTP. let's talk to RTP guys

Comment: calling it RTP is fine, but it is not really RTP

Q: efficiency on the wire? move towards efficiency or layering?

Q: in frame-relay, length of header is local to the interface. more efficient to build the header at the egress

A: not convinced by argument. own implementations haven't seen this issue switching vs. frame relay

Steve Casner: implement t3 over RTP implementations and the clocking works fine

Yakov Stein: some issues: separate bit-serial vs. byte
vs. packet in tdm, bit-stream and both byte-stream for T1 and E1 payload is sent transparently.
AAL 1 over wire will also be different from tdm over wire

A: some packaging arrangement has to happen. trying to confine <>'s to smallest areas of protocol

Q: trade-off between efficiency and layering

A: team will have to work very carefully on how payload is designed

Comment to yaakov: unframed E1, etc. are all bit streams


Update on framework draft


o -01 was presented in London, then revised
o most changes editorial
o need to remove excess text, add input from Bryant and chairs draft will be updated and submitted for acceptance as WG item

Q: Has it been accepted as a WG item?

CHAIR: one reply said no, so waiting for more people to reply and more work needs to be done framework is NOT a wg document YET, now sending a last call to become a wg doc



o draft-anavi-tdmoip
o draft-pate-pwe3-tdm
o draft-vainshtein-cesopsn
o comparison
o questions

Slide: classic telephony with access network of analog lines to CO switch class 5 to SONET/SDH, synchronous, 'non-packet based

New picture: TDMoIP, with packet network in the core (IP or MPLS) pseudo-wires over packet networks wants to transport:

o voice tones & fax and modem
Transmissions, signaling, timing lost packets for voice may not be very important but in other cases, very important problems with encapsulating T1/E1 frames.


o fine-grain latency vs. efficiency
o efficiently handle fractional T1/E1
o No lost packets
o Avoid service interruption
o increase granularity
o add pointer to next (super)frame boundary
o only send desired timeslots
o add packet sequence number

AAL1 is inefficient if the timeslots are hard-wired to allow dynamic allocation, use AAL2 not just ATM
AAL1 and AAL2 are adaptation protocols


ip header
udp header
optional rtp header
TDMoIP header
TDMoIP payload

CHAIR Q: if you consider high-speed links, what kind of delay problems will arise?

A: this proposal for T1/E1 and maybe T3/E3, but not high-speed network

CHAIR Q: if you send over OC-192, what do you do?

A: solving efficiency problem, not timing problem

Q: how are u planning on muxing/demuxing multiple streams?

A: go back to draft to see bundle number, multiple bundles

Comment1: framework proposal has some work on bundling that may be used

Comment2: maybe not use the martini proposal

Prayson Pate:

o another approach
o looking at other applications, where interaction with
o SONET networks will be important

How to allow fractional STS encapsulation?

o circuit emulation from t1 to t3
o compatible with SONET/SDH CEP as defined in

o use well-defined SONET/SDH
o extend OAM's

E1/T1 solution:
o VT encapsulation
o fractional T1 as well

VT encapsulation:
o use SONET/SDH CEP header
o pointer points to V5 byte
o up to multi-frame payload size

Fractional sts-1
o carry bytes of VTs
o maintain end-to-end BIP

o simple extension to SONET/SDH CEP
o suggest adoption as wg item

Q: payload is 104 bytes, isn't VT different?
A: not setting

Q: why bring all the complexity of T1 and E1?
A: the mappings work fine

Q: you don't have sonet add/drop boxes
A: while it is attractive to use new protocols, this exists and works well and has silicon chips for that. we also have consistent approach from T1 and up

Comment: putting too much complexity
A: building boxes today

Stewart: are the boxes in-scope or added service?
A: # of discussions b/c of the way somebody wants to build a switch, fine line. my proposal proposes a convenient format.


CESoPSN encapsulation for emulation of low-rate TDM circuits over PSN. FROM fractional to unstructured T1/E1 to up E3 and DS3 minor modifications to unstructured low-rate SONET application to class 5 networks.

o minimal requirements to the PE synchronization

o configurable fixed size payload:
o limited by path MTU and packetized

Delay reqts
o fixed for PW life cycle
o multiple of the size of the natural

Delineation data chunk
o always octet-aligned

RTP header:
o carries clock of incoming ES from ingress to egress over PSN
o marking
o sequencing
o misconnection and mistype defects detection
o compatible with RTP header compression


Control Word:
o dynamic bw allocation (save bandwidth in case of end service outage)
o signaling problems detected at ingress.
other issues

OAM issues:

o hierarchy of defects considered
o PW loopbacks

Issues for further study were also listed

Based on working implementation
Proposed for wg document

Consensus comparison of 3 approaches:
*contentious issues intentionally left out*

o Chart on provided services
o IPR claims

Steve Thomas: Q: conclusions from interim meeting in tel-aviv were to merge 2 proposals and move one to SONET

A: nothing of the Tel-Aviv meeting agreement happened not found a way to combine approaches first and third approaches have sufficient overlap that may be worked out CEP people have a very different approach CEP people have been trying to work with SONET

Comment: if a box implements the 3 approaches, bad!


Ethernet Pseudo-Wire Emulation Edge-to-Edge
draft document: draft-so-pwe3-ethernet-00.txt

References model & scope
o diagram with PSN tunnel from pe 1 to pe 2
o focus on the PW termination for the pt2pt configuration only multi-pt is referred to draft-lasserre-vkompella-ppvpn-tls
o support both raw and tagged virtual port modes considering MPLS, GRE, and L2TP as the tunneling technologies no new signaling mechanism

pt-to-pt reference configuration with PW termination processing
o setting up
o maintaining
o encap/decap

Did not consider on adaptation, leave it to Ethernet

o Emulate pt-to-pt Ethernet trunking and switching behaviour
o Setup Ethernet PW between PE devices over the PSN tunnel
o Encapsulate Ethernet PDUs
o Describe maintenance interactions,

Ethernet PW outsdanding issues:

1. lack of signaling support for Ethernet PW over GRE to coordinate VC/PW label distribution and maintenance support

option 1: develop new signaling
option 2: implement MPLS-in-GRE like approach to leverage GMPLS signalling

2. to convey the PW/VC ID for Ethernet PW over L2TP

3. need to determine if fragmentation is needed for the Ethernet pw

4. ethernet pw over mpls design is aligned with Martini draft

5. how to align the pw design approaches among different draft, e.g. PW over L2TP?

o Clarify with ADs if on right track
o requesting input from PW wg
o need to collaborate with L2TP WG on the PW ID reqts
o clarify how above issues can be solved

o requesting that the draft become the wg document

Chair: work is very good. enclined to move to wg doc.

Comment: in terms of identifying Ethernet at pw, it already exists; some fields may be leveraged, email back and forth to iron this out

Chair comment: please incorporate updates to wg document

A: sure, more discussion offline

CLAUDE KAWA: Frame-Relay over PW Emulation Edge-to-Edge

o write draft on frame relay on pw's

Header format (based on Martini draft)
Packet processing specification
o general procedures covering all types
o specific procedures for MPLS LSP, IP w/ or w/o GRE

Maintenance protocol
o lightweight protocol
2 functions:
o exchange PVC status between two PW edges
o perform keep-alive functions in the

Abense of user traffic

Remains to be done:
o bug fixing
o enhance section of frame relay over pw packet processing
o section on L2TP not done yet
o PVC maintenance protocol needs more work address QoS signalling for SVC and SPVC establishment

Q: is it appropriate to define a signaling mechanism or use pre-defined mechanism such as L2TP signaling?

A: can use different signaling include frame-specific LMI

Comment: maybe no need to send LMI in-band, and use specific L2TP

Q: don't understand why processing of frame-relay is very different depending on underlying layer

Q: what happens with frame relay control bits? are they just encapsulated?

A: we have to process bits. they will not be copied blindly

Q: no text in draft

A: not written yet

Q: may need additional bits

A: no answer

Q: need a way to signal PVC over pw, so we adopted technology used in FR

A: agree

Comment: Include in-band or out of band signaling (that will have the list of PVC signaling). Decide to use in-band as it is simpler on the operational side.

Q: single tunnel or multiple tunnels?

A: flexible


Encapsulation Header

o 2 methods discussed for sending frame-relay PDUs over a pw
o why do we need 2 header translations?
o critical bits are in the right relative positions
o translation process is trivial
o: separate convergence and payload

Frame relay without abbreviation

o uses generic packet payload type
o simple and efficient
o draft-kamapabhava-fr-pwe3-00, easy micro-code operation

Proposed change to follow martini header twisted bits

o send frame-relay packets transparently and unchanged if we must use intermediate type, use efficient format

Q: assume blind copy of bits, whereas significant processing

A: customer doesn't care about bits. in addition, some send FR w/o calculated values

Q: discussion that we had during discussion of Martini header encapsulation in a lot of cases, header length is local to the local interface, maybe no need to carry it

moved to a discussion between 2 fellows

Comment: considerations implementation-dependent

Q: are we emulating pw or pw with some part of the box?

A: pw

Q: 2 modes of operation:
o per vc
o transparent
Why not do that in FR?

A: boxes from different vendors won't work

Kireeti: need some sequence number if we're doing signalling

Mark: which fits the layering model

Comment: as a provider, don't know what is sent, so I need sequence number

BOCCI: ATM service draft-fisher
draft-fisher compromise between draft-martini and draft-koleyni

support ATM over IP/GRE, l2tp and mpls
combines features /simplicity of drafts w/ bw efficiency/transparency

PW's can be:
o atm vcc's
o atm vpc's
o atm ports

Each mpls packet can carry
o 1 atm cell
o concatenated atm cells (for bw efficiency)
o aal5 pdu or sdu

o optional sequence number
o optional length field

Chair interrupted: interested people have read the draft. what are the differences?

A: o fisher does not send VCI and VPI fields unless needed
o bit positions in control word are different
o fischer maintains protocol layering
o layer 2 information nearest layer 2 payload

Comment (to Luca): Are you interrupting as chair or author of a draft?
Chair: chair. need to move on this

draft-fisher builds on and is compatible with workg going with ATM Forum and ITU-T

Working group document
Chair: please send summary to mailing list

Suhail: Fisher draft is more efficient in comparison
testing in labs
Comment: Fisher draft based on implementation.
compatible with ATM Forum draft work is progressing very fast with ITU-T come up with one unique solution?

Chair interrupted


Current status: sonet design team consensus differences between cep and cep provides base Sonet EM functionality multiple implementations underway

o Going forward: payload compression enhanced performance monitoring
o sonet emulation is part of pwe3
o basic concepts stable for over 1 year
o please adopt in wg...


TDM Circuit Emulation over Packet Switching Networks (CESoPSN)
ATM Service draft-fischer
PWE3 Framework Update
Comparison of Three Approaches to TDM over Packet
PWE3 Frame Relay
PWE3 Protocol Layering