2.3.18 Pseudo Wire Emulation Edge to Edge (pwe3)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-07


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

  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
  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-pw-mib-05.txt
  • draft-ietf-pwe3-pw-mpls-mib-06.txt
  • draft-ietf-pwe3-pw-tc-mib-05.txt
  • draft-ietf-pwe3-sonet-09.txt
  • draft-ietf-pwe3-ethernet-encap-08.txt
  • draft-ietf-pwe3-control-protocol-12.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-06.txt
  • draft-ietf-pwe3-frame-relay-03.txt
  • draft-ietf-pwe3-atm-encap-07.txt
  • draft-ietf-pwe3-tdm-requirements-05.txt
  • draft-ietf-pwe3-iana-allocation-07.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-02.txt
  • draft-ietf-pwe3-cesopsn-01.txt
  • draft-ietf-pwe3-tdmoip-02.txt
  • draft-ietf-pwe3-satop-mib-2.txt
  • draft-ietf-pwe3-tdm-mib-01.txt
  • draft-ietf-pwe3-cell-transport-01.txt
  • draft-ietf-pwe3-oam-msg-map-01.txt
  • draft-ietf-pwe3-cw-00.txt

    Request For Comments:

    RFC3916 I Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)

    Current Meeting Report

    1530-1730 Afternoon Session II; Lincoln East


    Chairs: Danny McPherson & Stewart Bryant
    Minutes: Matthew Bocci
    Slides are available on pwe3.tcb.net

    Charter & Draft Status - Stewart Bryant & Danny McPherson

    Working on updating charter with ADs. Danny to send email
    to list with prposed updated and goals and milestones.

    Draft status: Stewart

    Lots of dependencies between drafts. Cannot become RFCs until dependencies become RFCs. Very important to get this right. Draft text may change if dependency text changes.

    Stewart carried out a dependency analysis: this is shown and looks very complex.

    This will drive order in which we send documents to RFC editor.

    Concerns: Not all normative references are really normative. Authors need to double check this. Also need to make sure all things that should be normative are called out as such. Need to check for informative refs and docs with no normative references.

    Base requirements now an RFC.

    Architecture: list of dependencies, but one may not be correct. Edits sent to the list. Now in editors queue. Waiting for fragmentation and L2TP. This will be RFC.

    Fragmentation: needs an updated. Encap refs can be moved to control word references.

    Andy Malis: Refs to arch can also be changed to refs to CW.

    Stewart: not sure this is allowed as arch is informational.

    Arch needs frag, needs control, and control doesn't have dependencies.

    Luca Martini: Architecture doc should be an informative reference becasue you define CW in architecture.

    Stewart: Fragmentation called up 2 bits in CW.

    Yaakov Stein: CW has to be standards track because of 1st 4 bits

    Luca Martini: Every documents defines the CW bits that it uses. CW document is the generic template.

    Mark Townsley: would be preferable if description was all in one place.

    Yaakov Stein: important to keep things the way they are now for expediency

    Eric Rosen: will confuse the IESG

    Control Word Draft: Most refs to arch refer to sec 5 and could be deleted. These could be changed to arch. Will respin and send up.

    IANA: This is in last call and will be sent out as soon as this is completed. Needed to set up the registries. Also lots of requests to stabalise code points.

    Control : This is one of the most strategic docs. Past last call, but keeps getting minor change requests. This is an urgent gating draft. Need to take a hard line on this.

    Luca Martini: Also some editorial nits that need to be fixed.

    Stewart: as long as protocol works, need to draw a line in the sand.

    ATM and Ethernet: Had 1st go of AD review. A few edits to fix.

    Thomas: very close to last call.

    TDM Reqs in Thomas' queue

    SONET needs TDM requirements to get AD review before progressing.

    SATOP sent to Thomas, but want to resolve UDP issues first.

    CESoPSN is informational, but want to resolve UDP situation too.

    HDLC encap: Needs a respin to fix refs. Completed last call.

    Frame Relay: Needs some TLC. A get well package has been agreed, and should see a new rev shortly. Style out of step with rest of document set. terms need fixing.

    Yaakov Stein: Titles of encap drafts could be standardised or made more consistent.

    Luca Martini: Titles are not consistent. Most say MPLS/IP, some say just MPLS.... Want comments on changing all of the titles and making them consistent.

    VCCV: Pressure to move this on. It went to last call. Dave Allen's comments have not yet been resolved: should be in rev 04, but this has not been published yet. Needs a serious edit pass, and should be last called. Depends on BFD and LSP-ping.

    MIBs: these have a hge cross dependency list. Need to make sure procedures are published before.

    FCS retention: Has standard encap dependencies. Not in last call yet.

    Andy Malis: it is ready for last call.

    Cell transparent mode ready too.

    TDMoIP: Need to resolve UDP issue. Appendix depends on VCCV. Waiting for comments on 2 OAM issues.

    OAM messag mapping: Big dependencies, so wait for others to get out of the way.

    1. Get -iana-allocation- to IESG
    2. Finish -pwe3-cw- and send to IESG
    3. Edit -control-protocol- to sort out refs
    and send to IESG
    4. Edit fragmentation and then send to IESG
    At this point we have the platform needed to
    progress the encap drafts
    5) -ethernet-encap-
    6) -atm-encap-
    Get TDM requirements to IESG, then the TDM encaps
    7) -tdm-requirements-
    8) -satop-
    9) -cesopsn
    Then finish the following encaps as they become available

    When we have made progress on the above we will promote the other work to the priority list

    Architecture draft is in editors queue. Waiting on frag and L2TP. CW dtaft will be standard. Arch will be informational.

    Yaakov Stein: Why is CW standards track, if it is not refered to as normative in other docs?

    Danny: Take to list and see what WG consensus is on new title.

    Mustapha: is CW is informational, why not just merge back to the architecture draft.

    Danny agrees that this is an issue that needs to be addressed. Will take offline.

    PW CW - Stewart & Danny

    There was lots of work after last IETF. Introduced associated channel concept. Only use of 001 encapsualtion is for associated channel for OAM traffic. This needs a formal definition for associated channel. Suggestions to the list on this. Other format ID values are available for additional purposes.

    Yaakov Stein: word channel clashes with the use in the architecture draft Stewart: propose some text to the mailing list.

    Channel type will have its own registry. Plan is to grandfather VCCV value (21). Some errors in the text around IANA assignment.

    UDP Statement to ITU - Stewart

    This is one of the most discussed issues. TDM encaps are being pursued in SG13 as well. UDP encaps are only used by low speed TDM. IETF documents are vague on use of UDP. Need to resolve this before we can go forward. The ITU started to talk about introducing an expected mechanism for handling the ports. 5 techniques proposed in liaison. Extensive comment on this to the list. Unable to reach consensus. Statement proposed to the list. Essentially says PWE3 deals with L2TP, and MPLS tunnelled over IP. Unable to reach consensus on whether we need a 3rd method, so unable to give advice to ITU on where to go next. However, are willing to listen to proposals on how to carry PW over UDP, but anyway will need to consider issues such as congestion, security, and specific application.

    UDP Encapsulation - Yaakov Stein

    Service provider model is presented. Emulation is PE to PE. IWF is located in the PE. AC is native service. Encap sits at the PE. Becomes MPLS at the PE. However, another model is that the iwf is at the CE. The AC does not run the native circuit. 3 possibilities:

    - MPLS AC
    - UDP/IP AC
    - other AC possibilities (L2TP, MPLS over IP, native service over IP using GRE, etc)

    Lively thread on the list. Over 50 emails from 16 participants.
    Advantages: UDP/IP familiar to customer base, PW label as UDP port no. reduces overhead, already extensively deployed for TDM PWs, reuse of AVT protocols, simplify NAT traversal.

    Disadvantages: had to provide QoS without c/o pt-pt trail. Cannot be layer network above UDP. UDP doesn't scale, not enough port numbers and increases NAT/firewall state. Need protocol for UDP port signalling. UDP checksum needs to be calculated. Why a new PW type at a late stage? Security and congestion control

    Other comments: need to reply to ITU liaison, PWE charter aimed at operators, not enterprise customers, wrong, but how to stop enterprise using it, no consensus, should divert to AVT, but CE-CE PWs not in AVT charter, UDP OK for VoIP since adapts an application, some comments seem to rule out MPLS

    Presents an rebuttal:
    - QoS similar to LDP based MPLS or L2TP
    - Enterprises don't need large number of UDP ports
    - Scales better than VoIP today
    - can use manual port provisioning
    - UDP checksum can simply be set to 0
    - PW type has been in the charter from day 1
    - Security: LDP and L2TP protocols are similarly unsafe
    - Congestion similar to L2TP

    Explicitly limit UDP/IP to enterprises (CE-CE case)
    - only allow manual provisioning
    - enterprise responsible to security, congestion avoidance
    - MPLS should be used if large numberof PWs needed.

    Stewart: would like comments to help draft ITU response

    Sasha: Agrees that there is no sense in developing a control protocol for UDP PWs. Don't understand what enterprise PWs means. If it connects to a class 5 switch, what is it? Also not sure that admission control should be up to the customer.

    Yaakov Stein: On congestion avoidance, the link that is UDP will suffer. SP can discard excess traffic. The access PW is the point from the CE to the core network.

    Sasha: Confused. Are UDP PWs only a part of Multi hop PWs?

    Yaakov: yes

    Sasha: don't know what to do with MH PWs

    Eric Rosen: is is too late to remove this TDM from charter entirely?

    Stewart: many people want to work on this

    Eric: if you want to get this though, stop drawing attention to the problems e.g. NAT, signalling, how you do multiplexing, seems to need to be manually configured to interoperate. Solution is to take UDP out and leave up to SG13, or only have manual configuration. IESG may still notice this. Better to leave this in the hands of the ITU.

    Luca Martini: Be careful and write a good security section. You are mixing control protocol with data planes. We are very exposed here.

    Danny: We are trying to define protocols, not how and where they are deployed. A lot of concern on how to scope enterprise vs. service provider here. We need to assume the protocols defined here will be deployed in the Internet.

    Stewart: can either:
    - not respond
    - say unable to reach consesus
    - say we recognise that there are limited cases where
    UDP would be appropriate, supported by manual configuration
    Scott Bradner: You have about a week to honor tradition and not respond, but it would be better to send them a response

    Thomas Narten: Be pragmatic and reasonable. If we don't respond, what will happen?

    Stewart: we have an opinion as to how UDP is correctly operated. We have a duty of care.

    Yaakov Stein: reason this was sent was that this was going to be progressed in SG13. If we cannot reach consensus, SG13 wil l do what it wants.

    Scott Bradner: ITU is trying to work with us. We should cooperate going forward, even if it is to say that we don't have an opinion. We must not ignore them.

    Thomas Narten: Agrees. We can give our thoughts. We may not like what they want to do, but should explain why.

    Mark Townsley: could say PWE3 doesn't care. Is there some work to do at an IAB level on what you do with UDP?

    Craig White: We do need to send a fairly strong statement similar to what eric expressed, but need to be cognisant of the fact that they have implementations. Need to say that on the Internet, this is not an appropriate use, but may be appropriate in a private network. be aware of issues if it gets connected to Internet at any time.

    Scott Bradner: What is magic about UDP in this context?

    Stewart: this was not an issue until it was noticed that we needed a port assignment protocol

    Scott Bradner: This working group was formed with the assumption of UDP and MPLS

    Craig: congestion avoidance problem with UDP

    Scott: no real difference

    Yaakov Stein: ITU would be happy to hear that we only want manual configuration.

    Luca Martini: We also have an implementation of this. Bottom line is that a better design is L2TPv3 and this should be used instead. IETF thinks this is a better idea.
    Eric Rosen: 2 issues: signalling. Suggestion that you could use LDP, with port numbers instead of labels. Do you use source or destination port? What about NATs? not sure we can come to consensus, except you need to manually configure it.

    Stewart: We do not recommend UDP, but L2TP. If you use UDP, you so manual config.

    Yaakov Stein: why?

    Stewart: We recommend that you only do manual configuration of the ports.

    Mark Townsley: ...and if you want to do automatic configuration, use L2TPv3 Issue with UDP is that it can cause problems for NATs. Some of the arguments made on the list are significant.

    Yaakov Stein: why does RTP group get away with this?

    Shasha: Neither MPLS nor L2TP are suitable for NAT traversal. Could say: No signalling protocol, should not be used in NAT environment. Agree that there is substantially more VoIP and so we could say that UDP already used for VoIP sessions with operational success.

    Mark Townsley: L2TPv3 designed to run over UDP. Every NAT knows how to do L2TPv3 as in RFC2661

    Thomas Narten: Liaison doesn't ask if it is a good or a bad thing. It asks how to do port number stuff. We should answer the question.

    Stewart: Our advice is that this is only done in a manually configured mode, and anything more advanced should be made as a proposal to the PWE3 group.

    Yaakov Stein: pick one and send it back already! Pick manually configured, but use L2TPv3 for signaled

    Consensus around this. Propose to the mailing list by Friday afternoon.

    PW Multi-Hop Requirements - Luca Martini

    Presents the outcome of the requirements team.

    Last IETF was a discussion about PW stitching. Since then, we had a long drawn out email thread. Concluded we needed a requirement document.

    Document not achieved by this IETF deadline.

    Met face to face. We are regrouping, and trying to produce a draft by the end of november concentrating on requirements for this technology. This will guide if we need to do any more protocol work.

    Open Microphone

    Luca Martini: What is the state of the rechartering?
    Danny: Will provide an update on the charter, goals and milestones on the mailing list.

    Meeting Adjourned


    PWE3 Draft Status
    PWE3 CW
    PWE3 UDP Liaison Statement
    PWE3 UDP Encapsulation Discussion
    Multi-Hop PWs