Last Modifield: 06/05/2002
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||Requirements Document Last Call|
|JUN 02||Framework Documents Last Call|
|DEC 02||SONET Documents Last Call|
|DEC 02||TDM Circuit Documents Last Call|
|DEC 02||ATM 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|
Minutes Recorded by: Matthew.Bocci@alcatel.co.uk Meeting opens at 13:00. Administrivia - Danny McPherson ------------------------------- Working Group Document Status: o Requirements went through WG Last Call. Several comments from WG, ADs and others added. Redo of WG Last Call Dec '02. o Framework, Protocol Layering and Terms documents have been folded into architecture. Makes sense to be in one place. WG Last Call Dec '02. o Fragmentation document hasn't had much feedback. Chair doesn't think it is contentious. WG Last Call Dec '02. o Ethernet: WG Last Call for March. A few editorial and semantics changes. o Transport: Luca Martini will talk about this o SDH/SONET is on hold at the moment. Issues to be discussed with authors. Miscellaneous Comments from Chair: o ADs are concerned that we must address congestion. Must have way to detect PW packet loss. Sequencing and length semantics will be put in architecture document and some generic text added to discuss congestion control with all service types will be added. o Need Security considerations. o Terms must follow those defined in Architecture document and only introduce new service-specific terms. o There MUST be a default mode for each service. o TDM requirements will be in a separate document. o Quote from Allison Mankin: "MUST be a single default mode" PWE3 Architecture Draft - Stewart Bryant ---------------------------------------- o This is the -01 version of the doc. Includes framework and Protocol Layering and terms document. o All comments received are incorporated. o Changed diagram to include RTP for MPLS. o Structured bitstream: needs framing. Agreed with TDM groups. o RFC3378 text in security section: Need to be aware that security risks may be higher than on a native network. o Operation of IPSec is already explicitly called up o Will add an extra short section on congestion. This is not payload congestion, but how you prevent PWs causing congestion in the public Internet. Take packet loss, apply metric, or shut down. o Control word: definition of common control word in architecture document. o What is an Ethernet pseudo-wire? PWE3 is consistent with PPVPN, more complex models e.g. bridge, reside in PREP. o Terminology: At the last IETF we agreed a separate terminology document. There is now a consensus that we now delete the old term draft. As a result of ITU-T work, need to tighten up on terms. o Requests comments on the document before last call Comments from floor: Sasha Vainstein: Does Ethernet mean multiple pseudowires are out of scope? Stewart Bryant: No, CE->PE is a LAN segment. Eric Rosen: If you want architecture document to have control word, then it must be standards track Comment: In other groups, it has been made Informational/BCP Stewart Bryant: Will defer to Chair and ADs to decide on a status PPVPN L2 Signalling -- Eric Rosen ---------------------------------- o Presented in PPVPN yesterday o L2 VPN framework and PPVPN architecture aligned in terminology. o Signalling connections 2 forwarders. Two forwarders are connected by a PW using Martini signaling. Each forwarder independently initiates LSP. Problem: presupposes provisioning model. Each PW individually provisioned. o No support for other PPVPN provisioning models. No integration with L2VPN auto-discovery. o Solution: Generalise method of identifying remote forwarder. Allow either forwarder to be the initiator, other to be the responder. o Martini signalling (PWE3 Transport/Control) currently doesn't have provisions for this. o A number of examples and associated problems shown: Example 1: VPLS. Forwarders ID'd by VPN-ID. Current VPLS proposals reuse martini VCid field as VPN ID. Example 2: Distributed VPLS. Example 3: VPWS full mesh model. Example 4: switched connections. E.g. ATM SVCs to PWs. o Going forward: ensure PWE3 signaling is general enough for PPVPN to use (PWE3 draft?). Specify use of PWE3 signaling for various provisioning models (PPVPN draft?). Mark Townsley: Current L2TPv3 spec includes identifier that is not tied to 32 bit. This would match that well, so He supports it. Hamid Ould-Brahim: Good, it will be better to use globally unique identifiers instead of BPN-ID since we already have one format for VPN-ID that is standards-based (RFC2685). Doing that will avoid the proliferation of multiple formats for VPN-IDs that need to be standardized. Rahul Aggarwal: The comment I made was that we have to consider whether these signaling extensions should be defined in PWE3 or PPVPN. The BGP PW/VPLS signaling extensions are not being defined in PWE3. Hence I said its not clear whether these should be or should not be defined in PWE3. Eric Rosen: PPVPN is prohibited from defining protocols. This group is defining protocols, and PPVPN model is based on PWs, so should rely on the PWE3 sig mechanisms RE: sounds like PWE3 should set up PWs. Luce Martini: We are chartered to have maintenance protocol. Pt-pt, simple. Including some extensions for PPVPN isn't a problem, but I don't think we should consider all of the PPVPN designs here. Would like to receive comments from WG on including this. Not a bad idea, but still it is pt-pt oriented. Mohan: Some of these extensions fit very nicely. Chair: In favour. Trivial to define semantics of extensible attributes to assist PPVPN in defining deployment scenarios, etc... Marco Carugi: PPVPN wil clarify functional blocks for sig. DT will work to clarify. Which info we want to carry for different models. For LDP, being done with same people in 2 groups. Doesn't mean this is the proposal. Group doing protocol should define how. This seems a clear way to proceed. We want same sig for pt-pt and for VPN models. PW Management Discussion -- David Zelig --------------------------------------- o Provides a brief update. Shows general concept of the generic MIB. o Connected to service layer MIB and PSN layer MIBs. o PW_BIB is Very stable. No change from last IETF. Waiting for control plane last call. o PW MPLS MIB is very stable. o Ethernet MIB is just a WG item. o ATM MIB just expired. Needs to be respun. o PW CEP MIB: did cleanup of unused objects. o Summary: MIB Implementation experience exists but needs more inputs. o Future additions: Notifications, use cases, and cleanup based on implementation experience. o Frame relay coming soon o Good timing for MIB doctor review. TDM Design Team Update -- Tom Johnson ------------------------------------- o Deadlock for about 2 years now. Design team was put together to solve this. o Agreed: Max Riegel's Requirements draft will be progressed for going forward. New revision by end of year. o Proposed compromise between 3 TDM drafts. There will be two drafts, one for structured and one for unstructured mode. Asking for those to be accepted as WG items. o All drafts will be aligned in terms of language, etc. Want to put together a common framework. [Clarifying notes from Tom sent to chair in follow-up email] 1) A TDM design team was formed to address the TDM emulation issues. The team is comprised of Max Reigel Prayson Pate Sasha Vainshtein Shahram Davari Tim Frost Tom Johnson Yaakov Stein The team has held several phone conferences and one face-to-face meeting. 2) A requirements doc will be developed that defines all of the requirements for TDM and SONET/SDH Emulation. The document will be based on "d raft-riegel-pwe3-tdm-requirements-00.txt". A new revision will be available by the end of the year. The DT requests that the updated document be accepted as a WG item when it becomes available. 3) A compromise proposal has been reached between the competing TDM draft authors. The updated drafts will be released to the WG by the end of the year, and the DT asks that the WG consider the updated documents for acceptance as WG documents when they become available. 4) Going forward, the DT has agreed that all of the TDM drafts will be studied for commonality. The first step will be to align sections and language between the various TDM drafts. And, if it makes sense, we will consider the possibility of creating a TDM architecture document to hold the common language and terminology. [End Notes Sent in Follow-up Email] Transport of ATM AAL1/2 frames over PSN -- Shahram Davari --------------------------------------------------------- o Briefly discussed the compromise in TDM, deferred details to later speakers. o Proposes for PWE3 to adopt TDMoIP Anavi draft. o Applications: Leased line, private line, toll bypass. o Need to reuse as much as possible existing technology. AAL1 is a proven technology, available in both hardware and software. Has a number of desirable features, which are listed. o There is also a need to interwork with ATM. Carriers use ATM CES in their network. Simple and inexpensive to use ATM SAR at ATM and IP/MPLS boundary. o Slide showing how TDMoIP and ATM CES Interwork. o "Any Service and Port (ASAP) is an important architecture." o Current Any Service Any Port (ASAP) support with AAL1. o Easy to upgrade to IP/MPLS CES from current Any Service Any Port o TDMoIP is based on proven AAL1 technology. Off the shelf hardware/SW. o Interwork seamlessly with ATM. o Asks WG to adopt TDMoIP. Chair: Take proposal to mailing list. Unstructured TDM (Sasha Vainshtein) ----------------------------------- o Presents motivation: - Many transport applications carry entire TDM stream transparently. - An evolution of unstructured approaches presented earlier in draft-vainstein-cesopen-03 and draft-anavi-tdmoip-04. - Simple enough to overcome differences. - Supported by editors in separate drafts. o Scope: all unstructured services, except unstructured SONET/SDH. o Encap has been aligned with SONET/SDH. RTP is part of the header. Control word is mandatory. o Two modes of timestamp generation. o Procedures updated to handle local handling of lost packets. o Payload is carried as captured. Two payload sizes. o Issues: default payload size value is not yet specified. DT is considering a compromise based on solutions for structured/unstructured. Steve Casner: Is this consistent with AAL framing from previous talk? Sasha V: this draft accommodates unstructured AAL1 attachment circuits. Steve Casner: Does this proposal meet the agreement that previous talk said? Sasha V: we are working on details of compromise. This proposal is part of the compromise. Dave McDyson: Glad for compromise. I am unclear specifically what you are proposing. Chair: Actual text of compromise is not in these drafts. Explanation of TDM compromise -- Yaakov Stein -------------------------------------------- o Previous draft is an unstructured draft only. The TDM design team initially felt that this might be progressed more easily. Problem is that we had no mandatory mode and the ADs are insisting that we have one clear "MUST" mode. o There will be 2 TDM drafts: Unstructured TDM (where unstructured means arbitrary bitstreams at TDM rates or structured TDM but when this structure has no impact on transport mechanisms) Structured TDM For the unstructured TDM draft the mandatory mode is CESoPSN with full frames. There are two optional modes: 47*N & 193 bytes per packet. For the structured mode TDM draft the mandatory mode is TDMoIP with AAL1 and there are two optional modes: AAL2 & CESoPSN with full frames. Sasha V: correction. There are 2 not 3 main modes in structured TDM. Yaakov has correctly relayed compromise. Issues with Control Word & Packet Loss -- Yaakov Stein ------------------------------------------------------ o Presenter claims the intention matches well with the AD's desires. Control word has: - Sequence number - Payload dependent flags - Packet length - Fragmentation - Payload type o We actually have 3 types of control word: - Martini CW - CEP Header - Fischer CW o Why 3 formats: Different services have different requirements, but primarily different groups wrote different drafts and different existing implementations. o Proposal: CW should be based on Martini draft. Ron Cohen: don't understand motivation. Really disagrees. Mark Townsley: When running over PSN, there should be one control word. There is point of first nibble. The martini definition is very friendly to existing P routers. Yaakov Stein: Agrees and should deal with this Ghassem Koleyni: Martini is compatible with ITU-T Sasha Vainstein: Not sure we can force one control word structure. Chair: ATM mode is the only one that employ Fischer CW format and it's optional there. Comment: Are you proposing that we have 2 types of sequence number: one that wraps to 0 and one that doesn't? Chair: Indeed Martini wraps to 1 and RTP wraps to 0. Martini reasoning for this is so that 0 represents "no sequencing enabled" but field is always present in CW. We'll try to make this less confusing in the architecture document. Effects of Congestion -- Yaakov Stein ------------------------------------ o PWE3 needs to take congestion into account. Presenter shows effects of packet loss on voice quality. Packets contain info from lots of different voice channels. o Graph comparing different techniques. Packet loss concealment can be built into VoIP. o Proposal: When structured TDM is transported the encapsulation must be able to easily support replay. Implementations should provide interpolation. Chair: Perhaps this needs to be in the requirements for TDM. Sasha Vainstein: Unstructured TDM can safely reply previous packets provided that the packet payload size is a suitable multiple of the frame size of the original circuit. This corresponds to one of the methods described in the draft. Other methods (linear interpolation, statistical) really require structured TDM. [Email correction from YJS: Even in the unstructured mode one can do replay if full frames are used] Steve Casner: In the structured case you assuming that it is all voice? Yaakov Stein: Yes, for data there have to be higher layer protocols to address packet loss. Steve Casner: Do you pass an error? Yaakov Stein: As long as loss is good enough for toll voice, this is not needed. Stewart Bryant: If this is deemed of value after peer review, why not progress as informational or best practice? Chair: Take proposal to mailing list please. Bi-directional LSPs for classical MPLS -- Rohit Dube ---------------------------------------------------- o Previously presented at MEF and MPLS WG. o Presents definition for Bi-directional and symmetric LSP. o Benefits: Good fit for both PWE3 and MEF EVPL. o Better manageability. o Shows RSVP-TE extension required. o CSPF extension shown. o Proposal extends LSP setup mechanism. Fits in MPLS WG and presented to PWE3 for information. Chair: Thanks for sharing... Header Compression Drafts -- Jerry Ash -------------------------------------- o Motivation: carriers evolving to converged MPLS backbone with VoIP services. Enterprise VPN services with VoIP. Legacy voice migration to VoIP. o Requirements are presented: needs efficient voice transport. o Support voice encoding. o Compress/decompress header using cRTP or simple algorithm, operate in 2547 VPN context, and be scalable. o Proposals: steps for method 1: - use RSVP to establish LSPs between CE1-CE2. - Use cRTP (or simple HC) to compress header at CE1, decompress at CE2 Steps for method 2: - use RSVP to establish LSP between PE1-PE2 - use cRTP to compress header at CE1, decompress at CE2 - PE1 & PE2 create 'SCID routing tables' and perform 'SCID switching' for compressed packets (SCID --> MPLS labels). o Why PWE3: seems best fit, but not within current charter. o Review of Implementation issues, and changes to protocols. Stewart Bryant: Whilst I am sympathetic to the need for a home for this work, it does not fit here, because it is radically different from any pseudo-wire type we are defining. Steve Casner: Comments recorded but clarified in the following email: [Steve's clarifications via email: The proposed work is not an extension to 2509, rather it is parallel to 2509. 2509 specifies signaling and packet type indication for PPP; as I understand it, the proposed work specifies signaling (via RSVP) and setup of packet type indications in MPLS. As I said in a post-meeting chat with Jerry, I think MPLS makes the most sense since RSVP-based signaling is discussed there, and clearly the MPLS-specific aspects fit there. The bigger question is whether it is feasible to implement cRTP on the line cards that are handling packet forwarding for MPLS tunnels.] Chair: Still need to discuss if/where this fits with ADs. Any-MPLS Interworking in ITU-T -- Ghassem Koleyni ------------------------------------------------- o Report on what happened in ITU-T in last 2 weeks. o Agreed last time to incorporate Martini modes into ITU-T 2 cell modes: 1-1 and N-1. o On cell modes, document sent for approval. o Reference diagrams shown for 1:1 and N:1 shown along with encapsulation formats. o Voice over MPLS is also being discussed. o All referenced documents can be found online (IETF participants have to register) o A liaison statement was sent to IETF explaining this. Progress Update for ATM, Ethernet, Control Draft -- Luca Martini ---------------------------------------- ------------------------ o ATM Draft is a merging of the ATM drafts (draft-martini, draft-koleyni, draft-bocci) for cell modes and AAL5 modes. o We met in this IETF and agreed to some changes to the first encapsulation document. o We want to make one applicability section. Lots of editorial work. o Remove MTU, sequencing, introduction terms/diagram, leave to architecture document. o Agreement to make N-to-one cell the only mandatory mode. o Ethernet draft: Single mode for Ethernet encapsulation. Todo: - remove control word sequencing, length. - Remove appendix. - WG last call. o Control Document: Since 00, refs updated, VLAN Request interface parameter. TODOs: - Considering protocol extensions draft-rosen-l2-signaling-02. - New TLV for PW status - New TLV for IP address will be in separate document in PPVPN - congestion control, seq, length will be put in arch draft Rahul Aggarwal: Ethernet: you mean encap, not PW type? Luca: Yes only one encap. 2 PW types but one encap. Mark Townsley: Ethernet and control draft, a good amount of improvement. ATM document still has a lot to do. Chair: applicability statements will determine the modes. Rahul Aggarwal: There should be no such thing as mandatory and not mandatory. Chair, agree: but unfortunately, this is the real world and we've made lots of progress. It's far better than where we were. Craig White: should remove non-implemented modes from the drafts. Meeting Adjourned.