Current Meeting Report

2.7.12 Pseudo Wire Emulation Edge to Edge (pwe3)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 07-Mar-02
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:
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   Framework Documents Last Call
Jun 02   Requirements Document Last Call
Dec 02   SONET Documents Last Call
Dec 02   ATM Documents Last Call
Dec 02   TDM Circuit 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
No Request For Comments

Current Meeting Report

PWE3 Meeting Minutes -- IETF 53

Minutes Recorded by:

"Tom K. Johnson" <>
"Motty Anavi" <>

o Danny goes over current status of work group

o The expected deliverables are a common Edge to Edge emulation maintenance protocol as well as an applicability statement per draft.

Stewart Bryant -- Issues w/Protocol Layering Draft

Major topics included...

o Differing IP and MPLS approaches

o Is a PW a wire or is it more complex?

o Native Service Processing.

o Principal of Minimum Intervention

Changes to draft include...

o The Position of the Timing and Sequencing layers were swapped, since there is seems logical that timing information may be dependent on sequencing information.

o The Tunnel layer has been renamed to be PW identification layer, as that better describes its purpose from a processing perspective.

o Then he reviewed specific details on how the layers described in the protocol layering draft would map to IP implementations.

o Stewart mentioned that the IP ethos is to towards generality and reuse of existing solutions while other PSNs have different concepts.

For example, a PW being carried over IP might make the following choices in mapping layers:


PW Identification = L2TP, GRE, IPSec, MPLS, etc.

Tunnel Sequencing may be provided by a number of different mechanisms.

However, if you're using RTP, then of course you should use RTP sequencing mechanism.

o Payload convergence as necessary for the specific service. And, in general the Payload should be sent raw, unless there's a good reason.

Then Stewart led a similar discussion mapping services to MPLS

o He noted that the PW over MPLS camp tends to value efficiency more than the PW over IP camp. And, that this appeared to be a key difference between some of the encapsulation proposals.

o Stewart then demonstrated how Martini meets layering model, but is simply more efficient from a header/payload standpoint. (see slides for details)

Next discussion, where does the PW stop.

o Stewart asserted the architectural principal (which was originally discussed back in Colorado), that the PWs should simply emulate 'wires', and not attempt to recreate service-specific processing functions (such as those of an ATM switch or a SONET Multiplexer). Those should be handled outside of the Pseudo Wire using techniques defined by the relevant standards-bodies.

o This non-PW processing is referred to as Native Service Processing (NSP). This is defined by the standards that have ownership of that specific service (such as the ATM Forum, ANSI, or the ITU-T). The PW should simply be a technique to carry the services through a PSN.

o Of course, the NSP function may be co-resident with the PW Adaptation Function.

Next, Stewart discussed the "Principal of minimum intervention".

o He indicated that this is not dogma, but simply a way of looking at the problem. The guiding principal is that if you fool around with the service payload as part of the mapping, you're likely to break something. If you carry the payload transparently, you are less likely to have problems. And, it's simpler. The primary issue that was frequently sited against such an approach was efficiency. Carrying ATM cell headers inside the PW when they will likely be re-mapped at the other side of the network was sited as a specific example of this inefficiency.

With that, several questions were posed to the working group to discuss on the list...

1) How much manipulation of payload should we do? (Stewart's thinking - unless there's a really good reason, the payloads should be carried as is.)

2) Is payload manipulation somehow dependent on PSN Type? For example the PSN=MPLS camp seems more interested in efficiency.

o He noted that non-intervention has the advantage of decoupling payload development from PW development, but has disadvantage that it may be less efficient on the wire.

o Next Stewart made a few suggestions about how/when RTP should be applied to PW work. Specifically, he said that RTP is not necessary if an external clock is used to provide timing for the service. Otherwise, RTP should be used for services that require timing support, unless there was a very good reason.

o Stewart then discussed fragmentation. Basically, try to avoid it in the PW. Try to get the CE to do it or in the NSP. However, if we need to support fragmentation as part of the PW work, let's figure out one way to do it for all PWs.

Next, there was a discussion of different channel types.

o For example, there appears to be a need for a very reliable control channel in many of the PWs. Depending on the service type, there may also be best-effort channels and sequenced high-quality bearer channels, and several other types in between.

o As a group, we need to define requirements.

Luca suggested that the list be used to comment on Stewart's presentation. Then, some Q/A...

1) Andy Malis noted that he had posted his issues and wants to continue discussion on list.

2) Khalid Ahmed noted that there is a sub-layering beneath those shown in Stewarts doc. Stewart said that much of that could be addressed by the NSP. Since we should only be emulating a wire, we should be able to keep things very simple. Use existing specifications for NSP behaviors rather than re-inventing them at the IETF.

o Follow up - Suggestion that we should be more consistent in our encapsulation schemes. Stewart acknowledged that we should strive for consistency, but there may be reasons to diverge. However, any differences should be clearly justifiable.


Matthew Bocci -- Fischer vs Bayley for ATM PW

o Matthew acknowledged that Fischer and Brayley had not been able to reconcile their drafts into a single document, so both parties had met with they had met with ADs. It was decided that Brayley and Fischer would break down each encapsulation mode for both drafts and evaluate applicability on a one-by-one basis. The goal being to reconstruct a single unified draft for ATM PWs.

o Matthew stated that the purpose of Fischer is to emulate VCC/VPC services on a cell by cell basis, and an AAL5 frame mode (PDU and SDU) which he noted is also simple to implement. However, he said that port mode had been removed.

o He noted that lots of issues with port mode had been raised on mailing list. And, that fault managemment was identified as a major problem where there is no way to isolate problems on a PW. He noted that given the original B-ISDN service model, port mode simply doesn't fit. He stated that ATM services are not simply cell transport, it's VC and VP Connections, with traffic contracts etc. Without connections, there is no way to recognize and enforce QoS requirements that are essential to ATM. And, there's no equivalent service to an ATM port mode in the current networks. So, it's not appropriate for PWE3.

o VCC/VPC modes include single cell modes which are very simple, but bandwidth inefficient. Additional modes to support concatenation of cells as well as AAL5 frame encapsulation for improved efficiency.

o VPC mode saves label space with full management of ATM services.

o Q/A... -- No questions


Jeremy Brayley - Brayley for ATM PW

o He confirmed Matthew'ss statement that the ADs want to see the two drafts converge. And, that they are trying to accomplish this by breaking down the two drafts into the individual services.

o Jeremy said that a key components of the debate was based on whether or not VPI/VCI should be relayed through the PW, and details of AAL5 mode. And, of course, port mode.

o Jeremy stated that service providers are looking to migrate ATM services onto their IP backbones. Then he reviewed VCC cell relay, AAL5 VCC, AAL5 SDU, AAL5 PDU of his draft.

o Jeremy said that he didn't think that single cell relay would be widely used due to ineffeciency. He also noted that there would be significant differences between a PWE3 ATM connection and a native ATM connection. For example ATM cell headers have single bit correction, whereas PWE3 ATM connections will drop packets with bit-errors. Also, since the PW must be transparent to the PSN, there's no way to signal EFCI in the ATM cell headers based on congestion in MPLS network.

Another issue he noted is that service emulations do not provides "perfect emulations" as may the less efficient cell relay. So it's not exact emulation.

o However, Jeremy stated that existing ATM I.610/OAM functions will need to work on the ATM PWs just as they do today on ATM circuits.

o Next Jeremy discussed the merits of ATM Port Mode. He acknowledged that port mode is most contentious. But, Jeremy says that carriers want it. It's a simple way to interconnect ATM ports through a PSN. There are problems with it, such as fault management, but it seems like there should be workable solutions for these.

o Next, there was a discussion of the two modes of AAL5 carriage. AAL5 SDU mode drops the padding, AAL5 trailer, and encapsulate the result. The main advantage of this approach is increased efficiency for AAL5 traffic. This is especially true for small packets, where the padding needed to fill out to the next cell can be almost as much as the payload. This is a well recognized problem for existing ATM networks. Why carry it forward?

o Jeremy says that main objection to AAL5 carriage is lack of OAM support. His view, if you need ATM OAM support, don't use AAL5 mode, use cell mode.

o AAL5 mode. Some carriers want to provide AAL5 service that includes UU, FCS. There's no need to recompute FCS. However, Jeremy is lukewarm on this mode.

o Khalid Ahmed Commented on the need to have applicability statements. AAL5 mode is not an ATM service, so it's applicability is limited. Same comment on port-mode. Suggested that PWE might want to consider a generic port-mode that does not depend so much on service type.

o Jeremy said that providers are interested in ATM port mode. Jeremy has heard need from service providers to generic port mode.

o Comment - there's no way to have a 'generic' port mode, since you need to know what's inside the stream in order to process. For example, carriers want an ATM port mode as a replacement for leased lines. The ATM port mode provides an opportunity for compression by not transmitting idle cells.


Prayson Pate -- Status of the PWE3 Framework ID

o He reviewed the history of the draft and noted that the framework draft is now WG doc.

o Lots of generalized clean up (see slides).

o Noted that it will need to be reworked a bit more to be coherent with Bryant draft on protocol layering.

o Q/A? - no Questions


Ron Cohen -- Pate TDM ID

o Main purpose of Pate's draft is to extend SONET/SDH emulation to explicitly handle lower rate tributaries. And, fractional STS-1 to conserve bandwidth on unequipped VTs.

o Reviewed basic application of TDM aggregation over PSN.

o Noted changes since -02. (see slides)

o He also noted that new revision is pending. This revision will include VC-4 support, similar to STS-1. And includes some options for compression.

o He explained that this draft is relatively simple extension to existing SONET/SDH emulation protocol by Malis.

o Khalid Ahmed noted that the main application of this draft is to be used as a distributed ADM. He then asked why should service providers use a PW rather then an ADM.

o Ron responded by mentioning the commonality of this application and the fact that the solution saves ports in the central location.

o Chris Liljenstolpe - Comment to last questioner - some service providers don't want to buy any more SONET ADMs. That's why they want to emulate SONET.

o Stewart asks if this belongs in PWE3 since it emulates a SONET ADM rather than a wire?

o Ron indicates that it is relatively easy to carry VT formatted data, and this meets Stewart's minimum intervention criterion.

o Sasha remarked that the term end-to-end used in the application slide does not correspond to end to end terminology used in PWE3, i.e. carrying information from CE-to-CE.

o Sim notes that this approach carries VT1.5, whereas other schemes only carry the tributaries without the SONET VT overhead. He requested that the value of carrying the VT1.5 overhead be explained in the applicability statement.


Yaakov Stein -- TDMoIP ID

o He explained that current revision is a major re-write of original draft to bring it in line with current PWE3 terminology. It provides more information about the protocol layering. It's been revised to support PW types other than IP. And he's added OAM for IPPM measurements.

o He presented how TDMoIP format maps into Stewarts nomenclature. Major difference between this draft and competing drafts is what payload is carried. This draft uses AAL1, AAL2, or HDLC to carry the different TDM payloads.

o Yaakov asks rhetorically... Why use AAL1? Isn't this a violation of minimum intervention. Yaakov attempts to demonstrate that AAL1 is the simplest method to carry TDM over packets. Other approaches will fall apart on packet loss, be less efficient. And, he makes the point that AAL1 is a debugged protocol that has been used for years and is known to work. AAL2 (another completely designed and debugged protocol) can be used.

o Yaakov discusses why TDM drafts have yet to converge, the reason is that the motivation of the draft writers is different. He suggests a possible approach to include Raw Frame and SONET/SDH in addition to AAL1, AAL2, and HDLC within his framework.

o Yaakov explains that one approach considers distribution of SONET/SDH, another concentrates on raw TDM trunk distribution while the third considers the lower end structured and fractional TDM trunks.

o To clarify, Yaakov proposed the following guidelines.

o SONET/SDH could be used for high rate signals or for distributing end-points that are already SONET.

o For other rates:

- MUST use raw frames for unstructured.

- MUST use AAL1 for structured static timeslot and case.

- MUST use AAL2 when dyanamic timeslot or bandwidth allocations is required.

- MAY use either AAL1 or raw for structured w/o CAS.

o Danny asked that Yaakov float his proposal to the mailing list.


Sasha Vainshtein -- CESoPSN ID

o His proposal is Edge to Edge for TDM circuits. It supports NxDS0 service, unstructured DS1/E1, DS3/E3.

o Sasha noted that his proposal uses RTP for timing synchronization and sequencing. And, that he had worked with Steve Casner to iron out some issues with the earlier revision of the draft.

o Then, he reviewed several detailed slides of open issues and changes. (See slides for details).

o Finally, Sasha raised the convergence issues with CESoPSN, TDMoIP, and Pate's extensions to CEP. He noted that after a number of attempts, he had been unable to converge his approach with Yaakov's TDMoIP. He stated that he has not yet tried to resolve issues with Pate's CEP extensions. He noted that the big issue is resolution of payload formats, which are quite different between the various drafts.

o Finally, Sasha raised some questions...

o Is a specific requirements statement needed for TDM?

o What is RTP role in PWE3 w.r.t. TDM services?

o Q/A -

o Yaakov questions whether Sasha's proposal meets the minimum intervention principal, due to how it handles CAS.

o Sasha disagrees.

o Donald O'Conner asked about how these different approaches compare from a TDM performance perspective. For example, "How do they behave when exposed to packet jitter", "how efficient are they", "how do they behave when packets are dropped", etc. The questioner noted that this line of question should be critical in determining which of the TDM proposals move forward.

o Sasha indicates that this analysis has not been completed.

o Mr. O'Conner also notes that whatever the performance is (from a TDM perspective) it will need to be verified on live networks with live TDM traffic.

o Sasha notes this has not been performed or compared.


Mark Townsley -- Frame Relay over L2TP.

o Tutorial style presentation - reference slides for details.

o Mark notes that his slides don't include anything above the L2TPv3 header. And that L2TPv3 can be carried of a variety of packet-switched networks.

o Mark shows that Frame Relay could be supported by L2TPv3 by adding a single AVP with two bits.

o Mark shows ladder diagram on how a frame relay circuit would be provisioned using L2TP.

o Mark walks through various scenarios for service establishment.

o Notes that shutting down on PVC doesn't require shutting down the L2TP session.

o Then walks through session tear down example.

o Then compares his doc to competing PWE3 draft for Frame Relay.

o He notes that the payload mappings are different, but that's a general discussion.

o However, his key point is that PVC control and maintenance sections are not necessary, since it can be addressed by L2TP with one AVP.

o Khalid Ahmed asks what's the relationship between this draft and the frame relay over MPLS draft.

WMT notes that L2TP runs over IP and that other tunneling protocols may be used over MPLS.

o Andy Malis notes that there should be a distinction between L2TPv2 and L2TPv3

WMT agrees.

o Question - What is the information that is sent in the message to identify specific circuit at far end -

Mark - VPNID. Configurable by software.

o Question - why not use GRE?

Mark answers that GRE is only encapsulation. The competing FR draft is mostly dealing with management. Using L2TP, all the control plane issues are addressed with existing protocols with minor extensions.

o Khalid Ahmed asks if there is work going on in Frame Relay forum to carry Frame Relay over MPLS. How does this relate to that work.

Mark says that L2TP runs over IP and MPLS or anything else. So, it addresses all the necessary components of the charter.

o Khalid Ahmed asks if FR over MPLS should use an alternate protocol?

Mark recommends that L2TP would work fine over MPLS as well but other tunneling techniques may be considered.

o Andy - notes that MPLS focused people would like to stay with MPLS based protocol. And, asks that L2TPv2 be noted separately from L2TPv3, since L2TPv2 is much more widely deployed.

Mark concurs that L2TPv2 is more widely deployed than v3.

David Zelig -- PWE3 MIBs.

(See presentation for diagrams)

o David describes layers of MIB. There is a service-specific layer, a PWE3 Common Layer, and a PSN-specific layer.

o Next he walks through mechanics of establishing a PW using the MIB. David indicates that the mapping of an adaptation function to a tunnel can be thought of as a kind of logical cross connect function. And that this is the way it is represented in the MIB.

o Next he reviews the MPLS-specific PSN MIB and the Ethernet-Specific service MIB.

o Next he shows relationship to interface stack table and other standard MIBs.

o Next he reviews ATM-specific service MIB, and SONET-specific service MIB (CEP).

o David notes that the PWE3 MIBs are very stable now. He asks the WG for implementation input. He states that he will be adding support for notifications shortly.

o Requests that this work be adopted as WG item.


Allison Mankin -- AD

o Notes that ADs ad WG chairs have coordinated on the layering draft by Bryant.

o She says that we must remain focused on the fact that PWs are not real wires.

o Applicability statements will note shortcomings.

o ADs and chairs will be meeting over coming weeks to discuss differences between IP and MPLS PSNs.

o Steve Casner noted that RTP header optional. He asks "is RTP/UDP/IP the right choice?" If not, Steve would recommend L2TP. Allison confirms that RTP/UDP/IP is appropriate for PWE3.

o Craig White - [lengthy comment that I was unable to capture...] We should stay focused on carrying services over IP rather than MPLS. So, RTP/UDP/IP is the way to go.

Craig clarified on mailing list:

"Boy, I guess it's my own fault for the rambling comment, but this doesn't match what I meant :)

It was a 3 part comment,

First, I was making the observation that you don't have to define your PW protocol using MPLS for the PW to use MPLS.

Meaning IP packets are put into LSP tunnels currently, so therefore, FR/L2TP/UDP may still end up in an MPLS tunnel. Which was my answer to the question about do you have to throw out UDP/L2TP/FR or UDP/RTP/SONET if you also want/need to take advantage of MPLS features such as traffic engineering, backup paths, etc.

Secondly, I offered the observation that perhaps our inability to move past some of our points of contention (e.g.. portmode) is due to the way that the AD's choose to define PWE3's work.

This was done in terms of service type (ATM, Ethernet, TDM) rather than by encapsulation method (MPLS, L2TP, RTP) or even by PW faithfulness (applicability statements), or another dimension not yet defined.

Very early on, one of the requirements of what has become PWE3 (esp. from the point of view of an IP service provider) was to use this technique to carry IP traffic. By this I mean to recover the IP frame "hidden" within the "native transport" protocol and then to efficiently move that IP frame through the network.

My third observation was that other standards bodies (ITU, ATMF, etc) perhaps saw a way to use an MPLS LSP a a transport medium for their particular protocol and to do this may require a lot of work that isn't necessary to simply move IP packets."

o Mark Townsley - Noted that there are two parts to L2TP, encapsulation and control plane. One can be used without the other. So, this should be kept in mind.

o Khalid Ahmed noted that there is much work going on w.r.t. ATM over MPLS in other standards bodies. How will that work be reconciled.

o Danny - we will be focusing on applicability statements and protocol layering. So, monitor the mailing list for the latest.

o Comment - we should hold an interim meeting to firm up applicability statements, etc.

o Danny - That may happen but probably not per time constraints w/Interim meeting, Yokohama coming up, etc. Try to resolve without meeting.

o Donald O'Conner notes that applicability statement must note short-comings.


An Update on CESoPSN
ATM Service Draft draft-fischer
PWE3 Protocol Layering
Extending SONET/SDH CEP for Low Rate Signals
PWE3 Framework Update
Pseudo-Wire Emulation Edge-to-Edge MIBs
TDMoIP Updates