Last Modified: 2003-09-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.
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 | |
| Oct 03 | TDM Circuit Documents Last Call | |
| Oct 03 | ATM Documents Last Call | |
| Oct 03 | Ethernet Documents Last Call | |
| Oct 03 | Frame Relay Documents Last Call | |
| Dec 03 | PWE3 MIBs Last Call | |
| Dec 03 | SONET Documents Last Call | |
| Mar 04 | PWE3 WG Charter Review, Additional Work or Ends | |
| Mar 04 | TDM Documents Last Call |
actions.Pseudo Wire Emulation Edge to Edge (pwe3) Minutes – IETF58 Monday, November 10 1930-2200 ============================= CHAIRS: "Danny McPherson" <danny@tcb.net> "Stewart Bryant" stbryant@cisco.com Minutes recorded by Prayson Pate Agenda - Danny reviewed the agenda - Noted addition of a presentation by Andy Malis on FCS preservation Document Status - requirements and architecture in IESG - Ethernet, ATM and L2oMPLS completed WG LC - Fragmentation ready for WG LC - Frame relay ready for WG LC - MIBs - waiting on requirements and architecture - SONET/SDH CEP - waiting on requirements and architecture - FCS preservation - upcoming ########################################################### Rahul Aggarwal - Use of PE-PE IP/GRE/IPSec for MPLS PWs http://www.ietf.org/internet-drafts/draf t-raggarwa-pwe3-pw-over-ip-00.txt This document describes procedures for carrying MPLS PWs over IP, GRE or IPsec tunnels. Still uses MPLS control plane. Motivation is that there may be non-MPLS routers between ingress and egress PEs. MPLS packet gets sent over an IP or GRE tunnel. Can also use IPSEC to secure the tunnel. Rahul - asked to make a WG document Eric Rosen - asked why this document exists since there is a similar document in MPLS WG Rahul - Agreed that other documents exists. This document does not define any protocols - just procedures. The MPLS WG document specifies how to encpsulate MPLS in IP/GRE. It does not specify how to carry PWs over IP/GRE. And that there is an existing document for doing the same for 2547 over IP/GRE. Mark Townsley - seconded Eric's opinion. Said that this was a way to send MPLS over IP without using L2TPv3. Rahul - said that there was a need coming from SPs. This addresses the case when the PW control plane is MPLS and backbone is IP only. Luca Martini - Said that it is contained in control document Rahul - will follow up, but not sure that it is in control document Luca - send me a paragraph Andy Malis - add voice to the chorus. All specified elsewhere Kireeti Kompella - Document in L3VPN in GRE defined elsewhere. This is the moral equivalent for PWE3. If already in place, perhaps we should just expand and clarify. Yaakov Stein - For MPLS label handling is obvious. For IP, not clear. Inner label may be OK. Document raises a good point about how to handle labels over IP. Rahul - concurred. Danny - take it to the mailing list. ########################################################### Sasha Vainshtein (sasha@axerra.com) & Yaakov Stein (yaakov_s@rad.com) Structure-Agnostic TDM over Packet (SAToP) http://www.ietf.org/internet-drafts/draf t-ietf-pwe3-satop-00.txt This document describes a method for encapsulating TDM bit-streams (T1, E1, T3, E3) as pseudo-wires over packet-switching networks (PSN). Yaakov reviewed the history of the document, and described the term "structured-agnostic". He described how the document meets the requirements document, and gave an overview of the basics of SAToP, including the control word, sequence numbers and control flags. RTP is optional, and there are 2 modes for time-stamping. Subject is being discussed in ITU SG13 as Y.tdmompls. Sasha discussed some of the issues. "Octet Aligned T1" was raised by Ron Cohen and Yaron Raz. This issue is related to mapping bits from a NSP, and with mapping between T1 and E1. WG input solicited. Next issue raised by Alex Conta regarding T3 AIS, which cannot be detected in a structured-agnostic fashion. Proposed a direct indication of signal validity, but requested WG input. Last issue is a lack of a reference to the EF PHB. Using EF PHB seems natural, but DiffServ WG chairs objected to naming any specific PHB. WG and AD input requested. Danny - why did they object Sasha - will send exact text Yaakov - described objection Danny - send to list (paraphrased objection as their being willing to issue PDB but not PHB) Sasha - remaining items - resolve open items - allocate code points - add MIB - Add RTP-specific parameters to control protocols - Can complete and resubmit for WG LC before next meeting Ron Cohen - Described reasoning for asking for octet-aligned format. Would allow for more flexibility in granularity, as well as providing a better connection to existing SONET/SDH chips. Sasha - which option do you prefer? Ron - add as an optional mode to SAToP draft Yaakov - can add mode, but what is the exact service? Need to be specify. Ron - not really a new service ########################################################### Yaakov Stein - TDM over IP http://www.ietf.org/internet-drafts/draf t-anavi-tdmoip-06.txt This document describes methods for transporting time division multiplexed (TDM) digital voice and data signals over Pseudowires. Yaakov gave a history of TDM circuit emulation in PWE3. He then gave a justification for structure awareness. - packet loss concealment - data channels - more robust synchronization - maintain MF sync - guarantee integrity of CAS Why 2 drafts? CESoPSN and TDMoIP provide different benefits. Yaakov proposed advancing both as WG informational drafts. Danny - that's the plan we agreed to. ########################################################### Sasha Vainshtein Structured TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) http://www.ietf.org/internet-drafts/draf t-vainshtein-cesopsn-07.txt This document describes a method for encapsulating structured (Nx64 kbit/s) TDM signals as pseudo-wires over packet-switching networks (PSN). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams [PWE3-SAToP]. Sasha gave an update on the changes in the draft. - Unstructured items have been removed. - Remaining items are essentially unchanged. - Better alignment with PWE3 CW and PWE3 fragmentation. - State machines aligned with SAToP Remaining items: - code points - MIB - Control protocol extensions for setup/teardown of PWs Sasha re-iterated Yaakov's request to progress structured documents as WG informationals. Ron - Question about all 3 drafts. Is there a discussion about RTP granularity? Sasha - There is some work in progress among the co-authors of the drafts regarding the recommended timestamp frequency. Should be completed soon. There is one candidate frequency - the SONET byte clock frequency of 19.44 MHz. May need to go to a higher frequency. ########################################################### Stewart Bryant - How to proceed with structured TDM Stewart - what is the status of the TDM requirements Max Riegel - there was little discussion in the last month. Intend to update to reflect the latest changes in the PWE3 requirements draft. Danny - is SAToP aligned? Max - was already aligned Yaakov - meeting this week with Sasha and Max to review. Invited others to join. Stewart - Should we pursue the structured documents as individual or WG documents? Andy - WG documents Yaakov - need to pursue as WG because of procedural issues Sasha - Concurs Stewart - proceed as WG items, take it to list ########################################################### WG chairs - The case for FCS passthrough in Ethernet and Frame Relay PW draft-malis-pwe3-fcs-retention-00.txt Andy Malis described the ideas behind FCS retention, and described an option to preserve FCS. Draft describes that FCS discard is the default, and defines a way to signal. Yaakov - why is this a separate draft Andy - defer question until after Danny's presentation Danny presented some slides generated with Stewart - current drafts specify discard of FCS - pros o carrying FCS increases integrity o increase fault coverage o similar to GFP - cons o current drafts are matuire o experience suggest that checksum options are not used? Danny - are any optional modes ever used in other protocols? Andy - yes, RFC1483 and 1490 o issues with legacy HW - making it a separate document allows the other documents to move forward - makes it clear that FCS preservation is an option. Eric - was discussed to a standstill 3 times - no consensus, would delay base drafts if included. A separate draft allows it to be discussed and tested on its on merits. Danny - agreed. Andy - agreed. Danny - will change mandatory to default and move forward. Liam Casey - will this be a WG document? Danny - ask on WG mailing list Stewart - does anyone object? Eric - re-iterated Stewart's comments about complexity and need. ########################################################### Eric Rosen - PWE3 Congestion Control Framework http://www.ietf.org/internet-drafts/draf t-rosen-pwe3-congestion-00.txt This document attempts to lay out the issues which must be considered when defining congestion control procedures. Eric Rosen discussed some of the issues with congestion control. Need some sort of feedback loop to control throughput based on packet loss. Is it needed? - No. Payload is IP, and IP already handles congestion. - No. PWE3 only runs in non-congested environments. First point may be valid, but second is doubtful. Do existing solutions fit? Not very well. Most are oriented towards end system implementations, and involve heavy interactions with hardware. Rules out TCP. How can congestion be detected? - gaps in sequence numbers problematic due to lack of sequenced delivery - periodic marking e.g. VCCV - per-tunnel approximation Responses to loss: - AIMD vs. TFRC vs. ?? - Why TCP-friendly may be on Internet - Adjusting rates selective stopping of channels? Mark T - When you say PWE3, does this mean all PWE3, or non-IP PWE3? Eric - Trying to gather all issues. If you think that traffic is IP, don't need. If not, need to consider. Mark - may know based on PW type or SLA Eric - Don't need in L2TP because payload is IP Mark - Could just blast packets Eric - But it wouldn't be PWE3, so not our problem Sasha - Regarding VCCV to detect congestion and report via control plane. What is the advantage of such an asymmetric approach? Why not insert tx and rx counts in both directions? Or send tx and rx counts in control plane? Eric - wouldn't rule out this mechanism, but was concerned about problems with matching up packets flowing in two directions. Sasha - Will need to do the same comparison anyway. Eric - If so, need to take into account that reports get lost Sasha - Thinks that everything should be done in control plane Sasha - Regarding TDM - responding to congestion is problematic Eric - if channelized, can selectively shut down channels Sasha - what if channelized TDM is carrying VC channels? Then taking down some channels will destroy the VC group. Eric - that type of traffic must never become a significant part of the internet Stewart - must have a safety valve to preserve the internet Sasha - shutting down the entire service would be simpler and better Stewart - congestion is not beyond the scope of the WG Sasha - seen an IAB draft discussing congestion wrt VoIP Chris Liljenstolpe - tx counts have to go over the data plane, otherwise can get mismatches Randy Stewart - if develop a detailed draft, need simulation Liam - need to think about deployment models Thomas Narten - What is meant by "forget the whole thing"? Disagrees with position that congestion control is not needed. Do have to worry about case where traffic is not TCP-friendly. Stewart - so we need congestion control? Thomas - yes. Need to consider. Chris - Way back when, we recognized that congestion could be an issue, because descided not to address because it would be handled by underlying transport, not at PWE3 layer. Stewart - just discussed a proposal to carry MPLS over IP Mustapha Aissaoui - what changed to make this an issue now? Eric - Worry is that there could be a lot of non-IP traffic. Mustapha - is it because there is a lot of non-TCP traffic? Randy - need to worry about each new application wrt is it TCP-friendly. Right now, don't know that much about the applications that will go over PWE3. If traffic is blasted, will cause problems when carried over the public Internet. Sally Floyd - looks like a first good step. Congestion control is a part of the charter and must be addressed if there is any possibility that the traffic will go over the public internet. Mark -If there is a misbehaving application on top of IP, why does the problem become a PWE3 problem? Sally - The key is whether the transport can use the public internet. If you knew for sure that all traffic was best effort IP, you could punt. Mark - Thinks that there is a significant enough component (80%? 90%?) of IP traffic that we need to consider this case. Eric - Sally's point means that other tunnel types should consider congestion. Mark - Where does it end? Danny - need to wrap up Luca - PWE3 service is supposed to premium. All SPs who are carrying PWE3 are doing it as a premium service. Eric - solicited participation Stewart - solicited alternative approaches ########################################################### George Swallow - Soft Permanent Virtual Circuit Interworking between PWE3 and ATM http://www.ietf.org/internet-drafts/draf t-swallow-pwe3-spvc-iw-00.txt This document defines interworking between Private Network Node Interface (PNNI) SPVC signaling and the Label Distribution Protocol [LDP] as extended by [PWE3-CP] and [L2VPN-SIG]. George described the problem faced by SPs wrt running ATM and MPLS networks. They don't want to run 2 separate networks, or have to move customers as the network evolves. Requirements: - SPVC setup across ATM and PSN - Recovery - no per VC/VP config - Flexibility where SAR occurs - Minimal or no change in ATM software - Simple solution needed soon He discussed mismatch in identifiers: ATM: SPVC IE -> DLCI or VPI/VCI PWE3: IP address, TAI->VPI/VCI George discussed how to map the identifiers. A SP needs to pick two special AGIs to indicate the format of the TAI. No further semantics are implied. Interface between ATM and MPLS is either a AINI or UNI/IISP. The MPLS network is modeled as a multi-homed ATM host (with lots of addresses). All AEs advertise the same single NSAP prefix for the MPLS network. Conclusions: - wide deployment won't happen without a transition plan - proposal places all functions in PSN boxes - other proposals have been complex - needs to be done by IETF to keep it simple Andy - Likes proposal. Suggestion to make simpler - rather than signal PWs, nail them up Jerry Ash - Re-iterated support David Buschbach - drawings were asymmetric - other end may also be an ATM network? George - explicitly ignore problem to focus Chris - This address a real problem (i.e., ATM to PSN interworking, not necessarily ATM-PSN-ATM deployments in most scenarios) Danny - take to list ########################################################### Thomas Nadeau (tnadeau@cisco.com) Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV) http://www.ietf.org/internet-drafts/draf t-ietf-pwe3-vccv-01.txt Document defines how to verify data plane integrity for any PW over any PSN. Added new bi-directional forwarding indication mode, and rewrote the section on signaling. Moving forward: - need section on BGP capability signaling - additional examples - WG feedback ########################################################### Thomas Nadeau (tnadeau@cisco.com) - State of the MIBs Tom gave an update on the state of the MIBs. All are now WG drafts. The drafts have been updated to reflect implementation experience as well as to align with the current drafts. Moving forward: - need to publish PW-FR MIB - clean up compilation - update referencec - minor edits Issues: - who has implemented what versions - volunteers for VPLS MIBs Danny - need to incorporate TDM drafts (SAToP) Thomas - should be in CEP MIB Ron - why? Thomas - may need to be an independent document Danny - need to get together and discuss, independent document seems more appropriate. ########################################################### Thomas Nadeau (tnadeau@cisco.com) OAM Message Mapping http://www.ietf.org/internet-drafts/draf t-nadeau-pwe3-oam-msg-map-03.txt Draft addresses definition of mapping OAM erris to attachment VCs. Provides a consistent place to find these mappings. Draft updated for consistency with other drafts, and to add new contributors. Moving forward - Clean up - Accept as a WG item. Danny - any objections? <none voiced> ########################################################### Yaakov Stein (yaakov_s@rad.com) Pseudowire Customer Edge to Customer Edge Emulation http://www.ietf.org/internet-drafts/draf t-stein-pwe3-pwce2e-00.txt Yaakov discussed how PWE3 means "PE to PE". What about "CE to CE" (PW-CE2-E)? Only difference is where IWF resides. CE model may be a better fit in some scenarios. There was then a discussion of the charter. Does it rule out PW-CE2-E? If so, can we fix it? Also, who says that the SP is focused on ATM or MPLS? What about Ethernet SPs? Can we add this to the architecture document? Stewart - are we in the business of supporting Ethernet SPs? Eric - what is the issue? The chances are 0 that we are going to revise all of the references in the architecture documents. Yaakov - vendors are doing this today. Why treat differently? Eric - No reason he can't do it, but no need to make changes. Stewart - must be congestion aware Yaakov - MPLS edge devices don't know how to look at a label Eric - could use tunneling. What is the specific change that needs to be changed? Danny - isn't this just a change in semantics? Protocols don't preclude Craig White - expressed support. Mustapha - What is the nature of the network in the attachment circuit? Is there a network? Is there an IP control plane to signal the labels? Yaakov - looking at the case of a single hop Danny - need to focus on any change in requirements Mark - sounds like this is purely sematics Yaakov - 95%. Just need a few small changes. Mark - could this be solved with a simple statement? Yaakov - need to change in a couple places Mark - Probably too late for PWE3, but L2TPv3 draft is agnostic Sasha - If label on attachment circuit is a label assigned by the far end, how does the PE know where to forward? Yaakov - how does it know in the case of an ATM AC? Sasha - the AC is identified with the other end Yaakov -let's take offline Stewart - no expectation of a re-write of the architecture document. Let's focus on the shortcomings that may prevent running from customer to customer. Craig - What was your view of the AC between the SP and the customer? How was the label mapped? Yaakov - Take to the list. ########################################################### Tom Walsh - ITU-T Draft Recommendation X.84 Support of Frame Relay Services over MPLS. Described liaison from SG 17 to PWE3. Posted to list, and contains 3 attachments. - Liaison from ITU-T - Draft X.84 - Proposed amendment 1 Document is currently in ITU last call (AAP process). Yaakov - A lot of work is being done to normalize the drafts. Could it be the same draft as the IETF draft i.e. exactly the same rather than similar? Tom - good question, will pass on the WG management. Such an approach has only been done once or twice. ITU trying to keep functionality the same, but words differ. Danny - take to mailing list ########################################################### Danny - re-charter and move to internet area is upcoming. Some issues include: - PPP and HDLC PW types - PNNI interworking - Changes to requirements based on Yaakov's PW-CE2-E Will send draft of new charter to mailing list. ########################################################### Meeting Adjourned ########################################################### |