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.
Assumptions
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.
Deliverables
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
ATM
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" <danny@tcb.net> "Stewart Bryant" <stbryant@cisco.com> MINUTES: Matthew Bocci matthew.bocci@alcatel.co.uk SLIDES: Available at http://pwe3.tcb.net/meetings/ietf60/index.html ========================================== WG Document Status & Charter Update: Danny McPherson danny@tcb.net & Stewart Bryant <stbryant@cisco.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) - HDLC/PPP - OAM - Transparency - ECMP New: - Including users as well sas SPs - Interconnections between different PWS and the same PWs - IP PW - Congestion PW Control Word & MPLS BCP: Stewart Bryant & Danny McPherson ------------------------------------------------------------ http://www.ietf.org/internet-drafts/draft-bryant-mcpherson-pwe3-cw-00.txt 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 - Reserved - 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 tnadeau@cisco.com --------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-pwe3-oam-msg-map-00 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 Issues: - Timing synchronisation between protocols - End to end vs. partitioned loop model Does anyone care about end-to-end model? Dave Allen: yes Tom: why? 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. - Congestion 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 tdwalsh@lucent.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 rahul@juniper.net ----------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-raggarwa-rsvpte-pw-00.txt 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 Why? - 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 PW redundancy - Primary PW and backup PW. Shares QoS resources with primary PW on common nodes. like secondary LSPs in RSVP-TE Motivations: - explicit routing of PWs (QoS provisioning and administration) Why RSVP-TE: - 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 luca@cisco.com ------------------------------------------------------------------ http://www.ietf.org/internet-drafts/draft-martini-pwe3-pw-switching-00.txt 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. Illustrates differences. 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 hshah@ciena.com -------------------------------------------------- http://www.ietf.org/internet-drafts/draft-shah-pwe3-qos-signaling-00.txt 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 Comments: - 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 ppan@hammerheadsystems.com ------------------------------------------------ http://www.ietf.org/internet-drafts/draft-pan-pwe3-over-sub-ip-00.txt 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 sasha@axerra.com ---------------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cesopsn-01.txt 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 --------------------------------------- http://www.ietf.org/internet-drafts/draft-vainshtein-pwe3-tdm-control-protocol-extensi-01.txt 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 yaakov_s@rad.com --------------------------------------------- http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdmoip-02.txt UDP/IP issues (Yaakov Stein) Where should we put the PW label? Alternative 1: - destination UDP port should be a registered value - source UDP port number = PW label Alternative 2: - 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? Alternative 1: implicit upstream allocation (registered port at beginning) Alternative 2: 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 performance OAM IP Pseudowire Encapsulation: Florin Balus <balus@nortelnetworks.com> -------------------------------------------------------------------- http://pwe3.tcb.net/draft-balus-pwe3-ip-pseudowire-00.txt 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 du.ke@zte.com.cn ------------------------------------------------------------------------- http://www.ietf.org/internet-drafts/draft-yudong-pwe3-control-protocol-ext-00.txt 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 MEETING CLOSES |