Last Modified: 2004-07-23
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.
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)
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
L2TPEXT, DIFFSERV, AVT, CCAMP, PPVPN, MPLS, TEWG, ROHC
|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|
Pseudo Wire Emulation Edge to Edge (pwe3)
MONDAY, August 2, 2004 (1530-1730)
CHAIR: "Danny McPherson" <email@example.com>
"Stewart Bryant" <firstname.lastname@example.org>
MINUTES: Matthew Bocci email@example.com
SLIDES: Available at http://pwe3.tcb.net/meetings/ietf60/index.html
WG Document Status & Charter Update:
Danny McPherson firstname.lastname@example.org & Stewart Bryant <email@example.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
HDLC/PPP 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)
- Including users as well sas SPs
- Interconnections between different PWS and the same PWs
- IP PW
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
- 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 firstname.lastname@example.org
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
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.
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 email@example.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 firstname.lastname@example.org
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
- 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)
- 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 email@example.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.
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 firstname.lastname@example.org
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 email@example.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 firstname.lastname@example.org
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 email@example.com
UDP/IP issues (Yaakov Stein)
Where should we put the PW label?
- destination UDP port should be a registered value
- source UDP port number = PW label
- 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?
implicit upstream allocation (registered port at beginning)
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
IP Pseudowire Encapsulation: Florin Balus <firstname.lastname@example.org>
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 email@example.com
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