Last Modified: 2004-01-22
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|
PWE3 Meeting IETF 59 Seoul, Korea ------------ Chairs: Danny McPherson & Stewart Bryant Minutes: Giles Heron Requirements - Stewart Bryant ----------------------------- Requirements draft is "pretty much there". Gone through IESG. All other drafts are stalled behind requirements and basic architecture drafts. Need to get TDM requirementss to last call. Bunch of stuff ready for that. Plan is to remove architecture roadblock and then pass a block of final drafts to IESG. Need to create a list of what drafts are in what state after this meeting - Danny & Stewart to provide this. Once list is sent please provide feedback. Architecture - Stewart ---------------------- Ssent to IESG. Small change in security - sent to list. IESG says need to do work in next phase on use of IPSec. They want to know *how* we use it. Also need to do security applicability statement. MIB needed a fair bit of cleanup. Prayson/Tom/etc. have rewritten it. Circulated to list? Control word/protocol type led to discussion in IESG. Issue was not the design or the encapsulation - but needs to describe it the right way to rest of IETF. 3 options for way forward: 1) delete all refs to IP version and pull CW defs out of hat (simple for us, but creates a tarpit for other groups if change first nibble after MPLS). Being first WG to put non-IP over MPLS need to ensure right things happen. 2) create registry for "nibble after MPLS header". MPLS WG problem. ADs support this. 3) PWE3 CW registry. Define here. Encourage MPLS to pick it up and formalise. Current plan is to simplify 5.4.3/5.4.4 of arch draft to ensure they get through IESG as gate for other work. Include reference there that this is work in progress. Luca Martini, Monique Morrow and Andy Malis all expressed preference for option 3. MPLS/FR Alliance - Andy Malis ----------------------------- Only message is we need to get the work out so that we're not holding MPLS/FR alliance and ITU-T up. PW control draft has provisional FEC assignments (128, 129). Need these officially assigned by IANA so non-IETF bodies can reference. Also need codepoint for status TLV. X.84 (FR over MPLS in ITU-T) wants to sync with FR encaps draft. Need to get docs to RFC so other bodies can reference those. SATOP - Sasha V --------------- SATOP 01 rev posted. Same editors/authors as 00. Resolved all issues from Mineapolis: 1) octet aligned T1 2) resolved T3 AIS 3) left QoS unchanged - list feedback was to do this. New work on setup and service type code points. Also new draft on MIB. Ready for last call, but stalled on TDM reqs. CESoPSN - Sasha V ----------------- Both this and TDMoIP on Informational track. Basically NxDS0 - also trunk-specific CAS stuff. Can fragment multi-frame structures if they take too long to packetize. Reallocated CW bits to align with ITU-T SG 13. Also minor edits. Control protocol extns for signalling MIB will be separate draft Waiting for feedback to do last call. Comments - Ron Cohen (Lycium networks) Good that comments before integrated. One issue is that default packetisation sizes for NxDS0 differ based on value of N (1 or 5ms). Better to unify to one packetization size. Needs to be high enough for efficiency for large values of N. Would like to have 4 ms rather than 5 as is a 2^N value so easier for clock-recovery. Sasha - will try to accomodate in next rev. Setup of TDM PWs ---------------- 2 drafts - one for PWE3 (MPLS) and one for L2TPext (L2TPv3). 2 basic modes (and sub-modes) 1) Structure-agnostic (T1, E1, T3, E3 - plus octet aligned T1) 2) Structure-aware Many parameters must be agreed in setup: 1) attachment circuit type 2) AC bitrate 3) payload size 4) use of RTP (optional but can be used by all encaps) Aim is to map onto small set of parms for PW FEC. Equally applicable to martini FEC and generalised FEC. Reused already defined elements Allow simple setup of PWs. Allow exchange of AC status in data plane rather than Controk Plane. End point ID is out of scope (difference in martini and generalised). Use: Service Type CW flag (always set) Interface parameters - bitrate and CEP payload bytes - from Malis draft. Can this be omitted if the corresponding default is used. Wants Luca etc. to agree to name change to TDM/CEP One new parameter - TDM options (can be omitted for SATOP with no RTP). Alternative approaches on service types vs AC bit-rates. In SATOP these two are mutually interchangable. Doc uses multiple code points for service type => no need for AC bit-rates. Only needed if octet-aligned T1 encapsulation is used. Alternative is single SAToP service type CP with mandatory bit-rate parameter. Wants WG input on this. For structure-aware code-points distinguish beteen basic NxDS0 and trunk-specific DS0. Need bit-rate to indicate number of DS0s. TDM PW FEC - shows if RTP is used, which type of structure aware (F bit), freq of timestamp clock, sync source of RTP if that is used. How to progress? Is it too late to merge with control protocol and IANA allocation? need new IANA allocations (8 new code points, new interface parm ID, 6 new status codes). Wants to adopt as WG item and progress with rest of TDM work at least for MPLS. Another question - do we keep MPLS and L2TPv3 separate or merge? Q for WG chairs and ADs. Comments from Andy Malis - prefer to keep separate so one doesn't hold the other up. (MPLS and L2TPv3). Debateable as to control protocol merge. Ron Cohen - do you intend the CP to configure the two end nodes, or just verify config is correct? Sasha - needed to set up connection. Additional status codes if gets rejected. Ron - for SONET emulation didn't allow configuration (security etc. issues) so just verify that config is correct at both ends. Need to ensure approaches are similar. Sasha - glad to discuss. Stewart - do we need to change any procedure in control draft, or is it just IANA stuff? Sasha - main impact is IANA allocation draft. Other than that changes to control protocol draft will be minimal. Most parameters are already mentioned. Changes to IANA allocation are more major. Stewart - am I correct in thinking this could go ahead, and then add some minimal bits to control draft? IANA has to be something you can add anyhow. Luca - we'll add parameters as needed to IANA draft until published. After that will have to go via IANA. Not gone to last call yet. Want to do it last as we'll add things. Otherwise will be delay between going to editors queue and IANA being able to allocate. Luca - are you trying to do negotiation of parameters for timing etc.? Sasha - all it is is agreeing on optional functionality. If only one end does it then revert to defaults. Luca - we already do this so no protocol change. Luca - is there major difference to what is already defined in status TLV. Sasha - in all TDM drafts we use the CW to send status in the data plane. So no need to use status TLV. Draft says not recommended to send status using control plane. Luca - status TLV was to have a better mechanism than label withdrawal. So I'd recommend you use this rather than CW. Sasha - real time processing is required, so using data plane. SONET drafts use this for AIS. So want to keep this in the data plane. With TDM and SONET send data even if nothing to send, and need real time status. Luca - what is the real time factor here? Why not use the control plane? Sasha - because control plane has unpredictable delay. May be longer than the jitter buffer can tolerate. So will conclude there is network problem and may start trying to do recovery. Packet arrival rate is predictable so use this for clock recovery etc. Will complicate things if involve the control plane as it has unpredictable delay. For example must generate certain patterns if something goes wrong (can't just stop sending data). Luca - same problem with ATM. With ATM can send in the PW. So question is should we also send a status message. Sasha - my approach is not to as don't want two sources of info (as you'd have to decide which source to follow). Luca - if the status is anything beyond down then you might end up with problem where the control plane is ????. Sasha - down is covered in data plane as is case where no data from the far end. Any additional signaling should be done through status TLV. OAM message mapping - Monique ----------------------------- Draft addresses how failures in PWs and ACs get mapped to OAM for both. Consistent location to find the mappings. E.g. how to map locally detected failures to PW status and Q.933 in FR. And equally for stuff received from remote end to LMI and Q.933. Tools to detect failure - VCCV, MPLS ping/traceroute, self-test etc. Change to draft is to remove any-to-any bits as these are out of scope. So like to like only. MPLS/FR alliance working on SIW OAM. Aligned with new versions of VCCV and LSP ping. Cleaned that up a fair bit. Also re-aligned with MPLS OAM reqs. Wants to be a WG draft. L2VPN WG requires VPWS OAM. Mustapha's draft there is for like-to-like and will align with this. L2VPN will discuss other types of VPWS. Status discussed here. Stewart - poll for WG status. Few in favour, none against. Rahul Aggrawal - Doesn't relate to this specific draft. Is there a need for L2VPN VPWS draft? Just takes these procedures and renames them. Monique - Will be open for discussion on Weds. Mustapha - History of drafts - this one was focussed on VCCV and mapping that to L2 native OAM. at same time his draft had very consistent sections for like to like. done at same time. So ended up agreeing to align like to like. Other types of VPWS will be done in L2VPN (in charter for L2VPN). Monique - want to clarify that to be in scope for PWE3 needs to be like to like. VPWS OAM does heterogenous ACs also (l2vpn language). Aligns with MPLS and FR alliance stuff on SIW OAM. Orly Nicklass - TDM over PSN-MIB -------------------------------- Combining presentation to cover TDM and SATOP MIBs then ref objects individually. Scope for MIB is PW connections between two TDM native services. Aim is to monitor and configure connections using multiple MIB modules at different layers. Design issues - PWE architecture limits scope of MIB modules to mapping service to underlying network. Need to fit with TDM reqs. Minimise # of objects - large set of MIBs in different layers so minimise objects here to those that are missing. Focusing on status reporting and statistics - and data for SLAs. Also need to do configuration. And alarms. Long time since MIB modules covered here. Model is 4 layered. PSN layer, PSN VC layer, generic PW layer, service layer (e.g. MPLS, MPLS VC, generic PWE3, Ethernet service MIB, and then 5th layer = Ethernet). For TDM reuse the same bottom 3 layers from before. This MIB connects the service layer MIB to the VC layer MIBs. Scope is TDM circuits for PDH: Unstructured is raw bits in payload Structured has framing etc. TDM MIB covers agnostic and aware. SATOP MIB just covers the agnostic stuff. Also will need TDMOIP and CESOPSN MIBs. Top layer is native tech. Relies on DS1, DS3, DS0 MIBs TDM MIB has five tables: TDM PW table Generic Config (stuff needed to get service up) 3 performance tables: (1) generic info on PW. interface index of TDM. 2 different pointers to other tables for the characteristics (generic/specific). Various measurement objects for monitoring status and statistics. Need to measure packet loss etc. Also have current status and timestamp for last error state. (2) generic config. same for any TDM. Payload size, packet reordering, RTP, jitter buffer depth, payload supression, and error info. One entry in this table can be used for multiple connections. Each connection can use pointer to point to this one. (3) perf. current 15 mins, historic to 24 hours (up to 96 intervals), running counters. Perf tables have info on misordering, out of seq, underrun/overrun, malformed packets. Also error secs, severe error secs, unavailable secs. extra stuff in historic table for interval length. Current table has info to say if there was a failure to collect statistics. SATOP MIB only needs the specific config table. has config parameters (mostly for performance). Again can service multiple connections. Basic config to understand how we transition from state to state. Packets lost to move state to state, what do we do if we lose packets, how many bytes are we expecting to say that the connection is up, how many bytes to fail to count before we say the connection is not in synch (these last two work together), alarm/alarm clear thresholds, excessive packet loss threshold, missing packet -> SES (how do we know we're in SES). Indication of what sort of timeout are we using (absolute or differentiated). To do: 1) Need to add a type of "TDM" to the PW TC MIB. 2) Add notifications to TDM and SATOP MIB Wants modules to be WG drafts. Questions? Stewart - will take the WG question to the list. If nobody objects will make it a WG doc. Stewart - all slides now online at pwe3.tcb.net. Luca - PWE3 sequencing ---------------------- Implementation issues. Tricks to make seq recovery better in certain situations. Not changing the protocol. Rather suggestion of best practices for sequencing. Couple of events at MPLS router could require resync of seq. 1) APS switchover 2) Linecard crash Problem is with low-speed traffic 65K packets to resynch could be a big problem. Today the only way to reset is to do a label withdraw. Ideally could do this in the data plane. Normally start seq at 1 and goes up one by one. What can do is do 1, then mid (32768), then top (65535). This done 3 times. Then go back to normal. protocol doesn't say you have to go up one by one - so this will work. This works on transmit side. Can have some counters for drop-resynch, and drop-resync threshold. If exceed a certain number of packets out of seq in a time period can decide is broken and then need to fix (so do the CP thing to fix it). This would work on the receive side. Add counters to MIB: drop counter - number of out of order packets dropped. gap counter - number of packets "not received" (i.e. gaps in the sequencing). Could do this as a draft then to RFC. Doesn't change protocol - just improves processing. Rahul - could have flapping under congestion? So is this the best thing to do. Luca - good to have counters. Question is what we do with them... If using counters to change status then need to do damping. Rahul - so what do we do if we find an issue? Luca - exactly. Need to address this as a WG ASAP. The ADs have said we need a mechanism. Doesn't need to be perfect but just something people can use if needed. Use counters - we can't do anything a la TCP. Nothing in protocol to signal congestion. Rahul - broader scope. Need to ask what is application on PW and can it address end to end congestion. So not clear what the problem is and whether we should solve it here. Stewart - TDM world has spent most time on sequencing. How is this aligned? Sasha - in TDM start from random number. Since packet arrival rate is predictable can identify when you've missed packets. In that case (lost preconfigured number of packets) then you decide that any seq number is OK. Unique to TDM as you know when the next packet should show up. Luca - this is synchronous so is different. Stewart - could send control message? Luca - could have bit in CW to signal in data plane (or set seq to zero). Problem is this needs to change the protocol. Danny - let's publish a draft to list and then we can talk about deployment guidelines. Luca - yes, will do informational draft. Craig White - Important after a gap to know what happened. Could have counter of in-sequence after a gap. Way to detect persistent conditions. Luca - will write a draft, send to list, and discuss from there. Stewart ------- Batch of stuff to dot is and cross ts on to send to IESG. Charter requires us to stop work soon or re-charter. Need discussion on where the WG should go. Outstanding items: 1) get drafts to RFC. 2) address security. Security folks have asked for appicability statement. 3) congestion. Eric started some work but has stalled. ADs have been concerned about this all along so need to address. Issue of IETF vs ITU-T scope. Overlap so far on PW. Good thing is that there is overlap of people so standards have ended up being identical (even if described differently). IETF is design authority for IP and MPLS so any changes to IP or MPLS must be here. But PW inter-working is not a traditional IETF area, and that seems to be the next area people want to work on. This is an IETF policy issue - what should we/should we not work on next? ADs and IESG need to direct us on this. How did we get where we are today? Initial focus of PWE3 was greenfield converged netorks. Didn't want to spend CAPEX on ATM/FR/TDM kit but wanted to compete with incumbents. Now have reqs from incumbents that want to migrate to a converged MPLS core (generally MPLS rather than IP). Seeing stuff on list about this. ITU-T focus on MPLS. Additional question is enterprises. Particularly in TDM space - TDMoIP is largely directed at this. Are the requirements different? Encapsulations. Issues with transparency. E.g. FCS. Also issues on header translations for MPLS PWs (not transparent today). So if people want this fixed it needs to be a new work item and people need to write drafts. Criticism that this isn't a completley transparent service. HDLC and PPP not done so far as weren't in charter. Definitely a demand. Need to clean this up. SPVC interworking. Seen discussion on list. Severe words said. Is this our job or not, and do we have competence. Or is this a case of supplementing other groups. Need to give the support that we are competent for and are the design auth for. Andy Malis - do have a WG draft on FCS carriage. Stewart - correct. I keep forgetting! Monique - big issue on IETF vs ITU-T. Need direction from ADs. Same people are working in both areas. Need to avoid duplication of work. If there is something flawed with an architecture then people should be encouraged to do drafts. Fundamentally we need to grasp what our scope of work is going to be or we'll be discussion this ad-infinitum. Craig White - have an interest in extending PWs for SIW. Specific case of IP interworking. As an SP once people carry circuits over your network they'd like to do an IP circuit. Two things - can establish a PW from yourself to the customer to carry IP. With PW architecture have opportunity to cause an IP packet to come out so PW becomes a generic connection mechanism for IP access network. No draft yet. Do you have to terminate the PW before you can output an IP packet, or can you recover IP packet and hand off to next available router. Special case of interworking and has IETF slant as is about recovering IP packets from PW AC. Kireeti - came for something else but paragraph in one of his drafts about this. Came to talk about ITU-T, MPLS-FR alliance etc. interaction. Big problem in CCAMP. We are doing GMPLS and other people like it but start changing it so it ends up rather different. With ITU-T have a design team with IETF and ITU-T people together to present requirements, but then do protocol work here. Should have done this earlier. That way protocols remain consistent. If PWE3 continues and want to work in this area then we should do this - or the two orgs will do incompatible extensions. Steve Trowbridge - same issue of adding ITU-T and MPLS-FR alliance in. As Monique said if you see a problem then write a draft or contribution. Issue will be doing the draft/contribution in the right group. Don't take something here if don't like ITU-T and vice versa. Dimitri - question on PWE3 stitching. When and where should signalling discussion happen? Need broader discussion on methods for stitching PWs. Need work in RSVP-TE. Stewart - if you submit a draft then say which groups need to look at them. Dimitri do we submit in PWE3 and also in MPLS, or do we wait until we get a decision as to whether it is in the charter. Danny - nothing wrong with defining reqs and then feeding them into the WGs. don't have to do implementation here. Sasha - two suggestions to add WG items. PW stitching/splicing. QoS. Personally would support both. Stewart - any other areas we need to address that we've forgotten? Mustapha - add a point on what Craig said. PW as IP interfaces. Yaakov brought work item on PW terminating on a CE. Mustapha's opinion was that he was asking to use PW as an AC. So generalising PW to be on the network side as well as access to L2 and L3 services. This could be a topic for the WG. Rahul - some devices already do this. Not clear that any protocol extensions are required. Jaime Miles - worth talking about P2MP PWs (though need to wait on MPLS WG perhaps). Luca - couple of things. For interworking the IETF has a bunch of RFCs (1483/1490 etc.) Enough interest here. As WG chairs should take this to ADs. Question is whether they will accept this. Last calls - only two or three people commented on last last call. Please read docs when a last call goes out. Need to check nothing has been missed. Much better if 10 people read a doc than two. With control doc had to re-do the status TLV as it violated RFC3036? Nobody caught this. So please read docs at last call. Danny - will send something out this week or next. Last calls on a whole bunch of docs. Will sync proposed charter with ADs and send charter extension to mailing list. Stewart - situation is still that once arch and reqs are through IESG we'll move the group to the Internet area so Thomas Narten will be our AD. Jon Petersen will be consultant from transport area (particularly for congestion). Craig White - can we clarify security and congestion control. With CC have had ideas thrown out but have lost track (e.g. DCCP). Can we have a draft produced to list the items that have been looked at so we can decide where to apply effort. With security would like clarification. Juxtaposition of Luca and Sasha's presentations wrt sequence numbers. Sasha uses random number - secure. Luca uses known number. Is this matter of cleaning up to start with random values etc. or are we more concerned with some other aspect of security. Stewart - particular concern is IPSec for IP transport. For sequence numbers need to get Luca to produce a draft which has a security section which addresses this weakness. Luca - the seq number is too small to be secure in any way. Security has to be done in some other way (e.g. IPSec). This discussion happened in L2TP. They came up with a large cookie for this reason. Craig - not calling your usage into question, but rather the security section is a wet blanket that gets thrown over work for no good reason. Rest of IETF may not understand why you'd use random seqs. We may need to call out these differences. Need to understand what we need to do to address security. List issues out and have checklist so we can get work progressed quickly. Rahul - IPSec. MPLSoIP doc talks about how can use this for MPLSoIP or GRE. Also there was a draft on PW over IPSEC in this WG. Am more than happy to help with this. Danny - we're done.