Last Modified: 2003-01-14
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|
|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||TDM Circuit Documents Last Call|
|DEC 02||SONET Documents Last Call|
|DEC 02||ATM Documents Last Call|
|DEC 02||Ethernet Documents Last Call|
|DEC 02||Frame Relay Documents Last Call|
|MAR 03||PWE3 MIBs Last Call|
|MAR 03||PWE3 WG Charter Review, Additional Work or Ends|
soon.PWE3 @IETF56 -- San Francisco, CA March 19, 2003 Minutes Recorded by Vach Kompella No agenda bashing allowed - lack of time Progress (Danny) - security considerations needs more work - need feedback from security wg - terminology, and refs need to be cleaned up 3 week last call on new rev of pwe3 requirements Architecture (Stewart) - all feedback incorporated except - all syntax/terminology is more ietf-oriented - ref models retained from the reqmts draft - generic control word - need more flag bits - specify ttl = 2 - use pid to make a first level determination that the packet is NOT ip - propose pid=0 for pwe3 - reject control words that use 4 for the first nibble - itu-based control word violate this (stewart) - dave allan: isn't this iana issue - yaakov s: at least 2 in violation of the basic limitation != 0, 4, 6 - chris l: why assume that it is always ip? - mark t: this is for pw that requires control, or requires all pws to implement cw - mark t: can't accidentally use 4 or 6 - stewart b: can't squander the bits, so can't limit to not using 0, 4, 6 - mustafa: don't use that position (1st nibble) for anything - andy m: mpls implied that ipv4/ipv6 carried by mpls need lot more discussion - andy m: make it self-describing, not this half-baked approach - luca m: don't call pid because it is not a protocol id, but maybe a class - find out packet is ip by computing checksum, other methods (general groans from audience) - george swallow: for better or worse, mpls decided not to have protocol - need some way to find what is in there, to identify flows - various hacks out there - eric r: original encap did have pid but it was deemed unnecessary - mark t: need to have defined value that is pw - vach k: this is really version, so can use 1, 2, 3, 5 - dave mcdysan: 5 may still be in use - congestion - pwe3 may be used by end-user and so it will be - text from rtp wg - if known to carry tcp, then its own backoff mech kicks in so no need for extra work - if not, pw must provide a loss-sensitive backoff mech - done by nsp, and out of scope - long term avg for tcp throughput - issues - do we need cong ctrl - is perfect emulation more important than congestion mgmt - what to do if we detect congestion? - how to identify a traffic class to do measurements on? - run over dccp? - congestion mech like red and yellow cards - backoff or drop - need more description on the pwe3 congestion approach? - rahul a: if qos sla is broken, what to do? We haven't reached that point because we don't know what to do yet - rahul a: some measuring mechanism is required [Stewart Agrees] - steve casner: perfect emulation means that when congestion occurs, the pw is probably breaking anyway, - what about other protocols over ip? who is responsible for better behavior, pw mgmt or just regular internet behavior - sb: whatever the internet does - mustafa: how to make some AS's take action, across admin boundary. can't take unilateral action to curb traffic - how to provide enough info so that the feeder of the congestion is notified of what is causing congestion - need fault notification - mark t: hope i'm not hearing that p routers have to worry about congestion OAM reqmts (Tom Nadeau) - promised not to bore us - sp reqmts - common set of oam reqmts for mpls networks - read the draft VCCV (Tom Nadeau) - mech for pwe3 using inband diagnostic - two approaches - use a bit in the flags (although none are left) - use a pid - mustafa: can't use existing tools to test PWs. use existing tools - there are already existing approaches. - tom: using those mechs you can't tell whether a p router is broken - mustafa: if you have native oam, then you can determine pw connectivity - lsp-ping for tunnel, and native oam for pw - not needed - but what fixes the problem with vc lsp and tunnel connectivity - dave allan: use a bit to identify the packet is an inband test packet - the reply is back over the vc - tom: yes, the pw is bi-di - what identifies what comes in the test packet? read the draft - shahram: can't use lsp-ping? because of ecmp? - tom: not necessarily, want to follow the disposition path of the egress, so we want the packet to be encapped correctly - george: you can't just ping the vc lsp, you need to identify the packet as a test packet - george swallow: (off-mike) something about informal survey of ecmp hashing methods - if detected to be ip, then fish in packet header , etc. - yaakov s: pws are defined as uni-directional - george s: always send the reply in the control plane - single-sided downstream unsolicited - incorrect in draft - still need to find a way to identify the test nature of a packet - take to wg for discussion Mesg mapping (Tom Nadeau) - based on a customer oam reqmt - translation of failures in lsp-ping or vccv to atm oam or other l2 oam messages - what to do about ethernet? - mustafa: mapping of state: need to check several things - cv is pro-active - but need defect indication (e.g., mpls tunnel failure needs to be used to generate ais type messages) - look into the proper oam and mapping of defects, rather than looking at it as a mapping of messages (which sounds like interworking of the native and mpls oam) - reactive mechanisms need to be addressed - tom n: this is not the be-all end-all, look at all the tools to solve the problems, this is only part of the solution - dave a: use of withdrawal of label as failure manifestation - so need to address in data plane ATM mib (Tom Nadeau) - adds to the basic structure of the mibs for pwe3 TDM (Tim Frost filling in for tom johnson) - why another? - 2 years of deadlock, and no compromises have worked - tom put in charge of dt to address this - draft-johnson - same control word structure more or less as sonet draft - unstructured em mode: pure bitstream, normal segmentation - (see draft for details) - broad agreement on this mode from dt (debate on default size of payload) - structured em (NxDS0 w/ CAS) - similar to atm cem doc - structured em (NxDS0 w/o CAS) - based on tdm multiframe format - discussion on how to choose the arbitrary payload length - need feedback from list as to whether this draft breaks the deadlock - yaakov: unstruct mode - everyone agrees struct mode: disagreement because the optional mandatory mode is not well-defined - tim: why pick a size that fits the tdm network when we are going into a pkt network that can have - alex: how many advantages of the other drafts are preserved? - tim: succeeds in preserving structure, uses the same cas structure (atm interworking is more difficult) - alex: why not preserve draft-anavi advantage (atm interworking) - tim: because it is not possible to solve both problems - alex: but draft-anavi is for unstruct mode - danny: if you have a draft that preserves all advantages then we'd be happy, but we need a compromise - danny: bring it to the mailing list - steve (axerra): big picture - lot of activity suggesting solutions or identifying problems - what changes are in the offing? - tim: in the area of how to segment it into different payload sizes, with the tradeoff into efficiency or latency - steve: what about areas like lost packets? - tim: needs to be addressed, but probably minor (in terms of controversy) - shahram: ask list which is more important. constant delay from pe to pe regardless of the bit rate, or ease of atm interworking TDM reqmts (Max Riegel) - init draft covered t1, e1, t3, e3 - needed to cover sdh/sonet - rest from the slides - revised edition out beginning of may, continue discussion on list TDMOIP-LE (Yaakov Stein) - loop emulation for congestion control - form id does not conflict with pid - aal2 is variable bit rate so allows more nsp processing (e.g., vad, compression, etc.) - tcp is 1st class citizen, and tdm is dropped with congestion (which is contrary to service provider needs) - if pw traffic is small, and not all of it is tdm. so for statistical peak situation by dropping packets and conceal with nsp techniques - to deal with congestion avoidance - we must have vbr mode - cw must have length field - form id is needed (since we can't change modes in control plane) TDM Structured Em (Sasha - who subbed for him?) - mostly stuff right from the slides - main concept: nsp function allows for less perfect structure - see convergence on tdm in the offing - Why there has been difficulty in obtaining consensus for TDM work, and how to resolve it? - Good news - - consensus on emulation of unstructured TDM (E1,T1,E3,T3) is close - Bad news - situation with structured tDM, because different people mean different things - clear WG position on scope, reqts and arch lacking for structured TDM. - Tried to clarify what structured TDM means and why we care about it. - Bandwidth saving on psn by skipping unused channels - efficiency - resilience of attachment circuit and specific applications to packet loss - application-specific BW mgmt - Piece of wire vs. Distributed DXC approaches. - Conclusion - optimistic for consensus on different approaches. MPLS FORUM liaison (Andy Malis) - current draft "TDM Emulation over MPLS using AAL1" is ready - please read and comment PWE3 control and maintenance changes (Luca) - changes include - refs - single sided mode - atm modes - numeric allocations to separate iana draft atm-encap - n-to-1 cell mode default - need some defs in 1-to-1 mode - may conflict with the arch doc ethernet-encap - tagged option needs reworking: move to nsp function - resolve and move to wg last call danny: need to resolve other docs before ethernet encap moves forward even though it is ready - rahul a: don't understand need to change. the tagged mode supports tagged mode and the spec should be left unchanged. - rahul a: there are existing implementations and some deployment around the tagged mode. - luca m: tagged mode is needed to overcome limitations of ip routers - ali s: both modes are useful - luca m: send comments to mailing list AAL1 transport (Shahram) - does not introduce new protocol - suggest move to informational wg - andy m: third suggestion - don't use pdu mode - also, l&r bits handling is not just informational, adds protocol changes so draft can't be info - yaakov s: support the draft, need atm encap draft changes L2TPV3 (Mark Townsley) - draft is in hands of iesg - companion drafts are in last call - will post to the list on the status David Allan - y1711 and lsp-ping are complementary - for pwe3: easy to do oam interworking with y1711 - with oam in dp, will prevent overloading control plane and label removal - danny: send points to mailing list Danny: work on documents between meetings, and not just near the IETFs