NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Danny McPherson <danny@ambernetworks.com>
Luca Martini <luca@level3.net>
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Allison Mankin <mankin@isi.edu>
W. Mark Townsley <townsley@cisco.com>
General Discussion:pwe3@ietf.org
To Subscribe: pwe3-request@ietf.org
In Body: subscribe your_email_address
Archive: http://www.ietf.org/mail-archive/working-groups/pwe3/
Service providers (SP) are seeking to offer multiple services across a common packet switched network (PSN), such that the result is emulations of e.g. Frame Relay or ATM circuits, or SONET/SDH. Multiple services on common infrastructure can be offered using pairwise conversions, so for instance, if the native link is ATM, FR could be offered over it by having modules that convert FR to ATM going in and ATM into FR coming out.
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
May 01 |
|
PWE3 WG started, organize editing teams. |
May 01 |
|
Hold interim meeting, including discussion of priority of service-specific documents and consider pruning some deliverables |
Jun 01 |
|
Requirements Document Last Call |
Jul 01 |
|
Framework Documents Last Call |
Aug 01 |
|
Produce first draft of PWE3 MIB and review MIBs for specific services to determine if they can be used for the pseudo wire services, or whether additional deliverables will be needed |
Oct 01 |
|
Frame Relay Documents Last Call |
Oct 01 |
|
First drafts of service-specific documents |
Oct 01 |
|
Ethernet Documents Last Call |
Mar 02 |
|
ATM Documents Last Call |
Mar 02 |
|
SONET Documents Last Call |
Mar 02 |
|
Other TDM Circuit Documents Last Call |
Jul 02 |
|
PWE3 WG Charter Review, Additional Work or Ends |
London IETF Meeting PWE3
Gerald de Grace - provided minutes for the meeting.
Peter Mills - Also provided minutes for the meeting.
Note: In future meetings people should clearly say there names.
Requirements Draft Presentation
Released a new requirements draft from .00 to .01
Xipeng: Several updates to the requirements draft were presented
???: Section 2.5 under packet ordering, are we trying to keep ordering of the maintenance and within the packet data
Xipeng: Opinion was that this was true
Dave McDysan: Is the intent to produce multiple solutions per technologies or a single solution per technology ? Opinion is that the control plane will be a common solution ? the different media types would of course have slightly different approaches
Luca: the technology design teams will be short lived with the mission to put them out to the email group as soon as possible ? the purpose of the teams is to quickly get text out for a larger review
Dave McDysan: Should we use positive statements of which features will be supported or a negative statement with the limitations
Xipeng: we will use applicability statement for this purpose
Framework Draft Presentation
Presented framework models
- in scope signaling should be called maintenance and out of scope should be referred to signaling
Rob Rennison: the outbound terminology is with reference of the CE and not the PE
Danny McPherson: we will clarify and ensure that what ever we do is consistent
Dave McDysan: something should be mentioned about signaling for SVC and PVC solutions
Dave McDysan: is there going to be a effort to make Ethernet a par with ATM, FR in this document
We might want to make some changes to LDP or RSVP ? L2TP has some of this already built in ? to keep the CE's happy and transparent to the network we might have to add something to the applicability statement
Luca: RSVP will not likely be modified for this protocol
Luca: clarified what we will work on initially
Luca: will make sure to use the word maintenance for in-scope signaling
Mark Townsley : if you are using a single protocol to set up the tunnels and you have everything in that to provide the maintenance then why would you use a different protocol to provide maintenance.
Mark Townsley: If you want to use L2TP it may have already defined signaling
Mark Townsley: If you want to use LDP then you might just want to add and not necessarily use something from L2TP
Mark Townsley: Separating signaling and maintenance may not be a good idea
Luca: explained some particular examples of signaling the CE which will be necessary like LucaI in Frame Relay ? the maintenance protocol requirements should cover this ? this will be spelled out better in the requirements document
David Zelig: presented PW MIB Relationships, PW-MPLS-MIB
David Zelig: requirement for 1:1 APS or 1:N is for further study
David Zelig: need volunteers for other PSN and service MIBs
David Zelig: point to point signaling will be covered in the PWE3, need to coordinate with PP-VPN for appropriate MIB contributions
Thomas Nadeau: presented service specific MIB (Circuit Emulation Service Over MPLS (CEM) Management Information Base Using SMIv2)
Thomas Nadeau: open issues on protection switching as mentioned before
Thomas Nadeau: need additional objects for performance monitoring
Thomas Nadeau: GMPLS, MPLS, PPVPN support is needed to push ahead
Thomas Nadeau/Danny McPherson: a document on how all the MIBs work together may be necessary to add to the framework document
Dave McDysan: these MIBs could be used for configuring PWs. The framework may be a good place to describe this functionality.
Thomas Nadeau: Okay, then I will add this to the framework in the near future.
Ananth: are the timelines for service specific documents going to stay on schedule as described in the first meeting
Luca: not likely
Ananth: other standards bodies are working on similar work ? how will we coordinate
Danny McPherson: we encourage open participate with the IETF ? publish to a draft ? publish to the mailing list
Allison: we should spell out any incompatibilities between technologies ? we should bring the experience directly to the IETF
Luca: we should work with other IETF bodies so that we have one common design
Sohel Khan Sprint: Frame Relay this year ? ATM next year ? is this still the case
Luca: all service design groups are starting in parallel ? we should see them in a similar time frame ? we should see them in the December time frame
Dave (Nortel): need for network behaviors ? 1:1 APS and other functions ? will we do anything to address these
Danny McPherson: this will be addressed in the applicability statement
Dave (Nortel): Coordination with TE group should happen immediately as they are looking at the similar items
Luca: thanks the design teams for bootstrapping the effort. The design team again is to get things out quickly so others can participate.
--- order of discussion is skewed here.
Requirements Draft
Section 2.5 Does packet ordering apply to both maintenance and user's mode?
(Luca) Both
Do you intend to support multiple solutions per technology?
(Luca) Wherever possible a unified solution will be adopted for all technologies and will endeavor to ensure maximum commonality at an early stage but nonetheless there will be some differences between frame relay, ATM etc.
To what extent will the emulated wire solution faithfully comply with the original? Should there be a list of limitations?
(Luca) Covered within the applicability document
(Luca) SE changed to CE for consistency
(Luca) Applications and point to multipoint pending for inclusion within framework draft
(Alison Mankin) Signalling is out of scope and should be renamed maintenance
(Luca) Agreed
(Dave McDysan, Worldcom) Does psuedo wire launch signalling?
(Luca) Out of scope
(Rob Renosen, Laurel networks). Need to define explicit direction for inbound and outbound?
(Luca) Yes
( Dave McDysan ) Soft PVC's include signalling between PE and CE e.g. LocaI, so should this be included in the draft?
(Luca) True but described in the applicability statement
( Dave McDysan ) What is "point to multi-point"?
(Luca) Described later
( Dave McDysan ) Is Ethernet on a par with frame relay emulation?
(Luca) Yes
(M Townsend) Experience gained of using LSTP, where there is signalling PE/CE using PPP
(Luca) Special Case
(Jim Boyle) Will common encapsulations be supported?
(Luca) Design team will try to unify protocols wherever possible
(Luca) Multi-point VPN's out of scope
Why create a new maintenance protocol?
(Luca) Need to define maintenance protocol PE/CE in the requirements doc
MIB Discussion
APS, 1:N for further study
Reverse mapping is it required?
Is VC an iftype - probably not
( Dave McDysan ) Will there be an API for external system to provision emulated wires?
(Luca) Yes
( Dave McDysan ) Will there be a separate applicability document?
(Luca) Separate document not required
( Dave McDysan ) Similar work has been done by ATM Forum
(Luca) ATM Forum welcome to contribute and discuss with other working groups e.g. ATM MPLS inter-working. Don't want to reinvent the wheel.
(Oneally) Some of the network behaviours required to support emulated wire do not currently exist.
(Luca) Will refer matter to TE MPLS WG, if it leads to a requirement being generated.
From Interim Meeting:
<A HREF="slides/pwe3_i-0/index.html" TARGET="BLANK">Interim Meeting Agenda</A>
<A HREF="slides/pwe3_i-1/index.html" TARGET="BLANK">PWE3 Interim Meeting</A>
<A HREF="slides/pwe3_i-2/index.html" TARGET="BLANK">PWE3 Framework</A>
<A HREF="slides/pwe3_i-3/index.html" TARGET="BLANK">Requirements for Pseudo-Wire Emulation Edge-to-Edge</A>.