Current Meeting Report
Slides
2.8.11 Pseudo Wire Emulation Edge to Edge (pwe3)
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.
Last Modifield: 06/05/2002
Chair(s):
Danny McPherson <danny@tcb.net>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
A. Mankin <mankin@isi.edu>
Transport Area Advisor:
A. Mankin <mankin@isi.edu>
Technical Advisor(s):
W. Mark Townsley <mark@townsley.net>
Mailing Lists:
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/
Description of Working Group:
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
Goals and Milestones:
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 |
Internet-Drafts:
- draft-ietf-pwe3-requirements-03.txt
- draft-ietf-pwe3-framework-01.txt
- draft-ietf-pwe3-protocol-layer-00.txt
- draft-ietf-pwe3-pw-mib-00.txt
- draft-ietf-pwe3-pw-mpls-mib-00.txt
- draft-ietf-pwe3-pw-tc-mib-00.txt
No Request For Comments
Current Meeting Report
Minutes recorded by Jeremy Brayley
July 14 PWE3 Working Group meeting (9:00AM - 11:30AM) Yokohama IETF54
-----------------------------------------------------------------
-----------------------------------------------------------------
Protocol layering document - Stewart Bryant
Do we need GRE and IPSEC as tunnel types?
3 people using GRE, nobody using IPSEC
Need GRE text from those interested
Fragmentation section to be updated with draft-malis-pwe3-fragmentation-00.txt
Payload Type section 3.3 could use some help, MPEG expert needed
Terminology - many docs have their own terminology section
Scott Bradner - proposes standalone terminology document
Work dependencies
Need to sync up with PPVPN WG
-----------------------------------------------------------------
PWE3 Fragmentation and Reassembly - Andy Malis
draft-malis-pwe3-fragmentation-00.txt
Fragmentation is required to send a frame larger than that supported by the PSN
Want a single set of Fragmentation/Reassembly procedures rather than specifying
the procedures in each PWE3 service draft
Procedures adopted directly from RFC 1990 MLPPP
Also used by FRF.12 and ATMF FAST
Bit usage inverted from RFC1490
Therefore not-fragmented packet looks the same as a packet from a PE that
doesn't implement fragmentation
Signaling additions - New VCFEC element parameter ID to signal the ability to
reassemble fragments
Two new L2TP AVP pairs
Scott Bradner - questions why reassembly is optional. He believes it should be
mandatory or not used at all
Andy - PSN MTUs are typically limited to 9K bytes
Scott - The question of whether to signal the ability to fragment and whether to
implement fragmentation are orthogonal
If mandatory to implement, you can still use slowpath even if it doesn't work
well
[Comments from mailing list]
I don't think this quite reflected the exchange, although Scott was quoted
accurately.
My primary point in the discussion was that I personally had no problem with
Scott's suggestion that reassembly be made mandatory, even though the specified
signaling is pretty simple.
Other speakers disagreed and felt that the ability reassembly shouldn't be
required, and that the signaling should be retained. As I recall, the conclusion
was to take the discussion to the list.
-- Andy Malis
[End Comments from mailing list]
-----------------------------------------------------------------------
Mark Townsley draft-townsley pwe3-l2tpv3-00.txt
Overview of l2tpv3
Difference between LAC and LNS
includes encapsulation (sessionid-cookies-flags- 24bitsequencenumber)
PWE3 document organization discussion
Mark proposes that PWE3 should generate the following documents in a hierarchy
**************************************************************
pwe3 requirements --------> pwe3 Framework and
Protocol layering
Pseudo wire documents --------> pwe3 mibs
(fr, eth, hdlc) (fr,etc,hdlc)
PW over MPLS PW over L2TP/IP
(fr, eth, hdlc) (fr, eth, hdlc)
**************************************************************
[Clarification from mailing list]
Just to be precise, the PWE MIB documents fit into the following picture (as
described in the Framework):
pwe3 requirements --------> pwe3 Framework and Protocol layering
Pseudo wire documents --------> pwe3 mibs
(fr, eth, hdlc) (fr,etc,hdlc)
/
PW-VC MIB (for general PW VCs)
/ \
PW over MPLS PW over L2TP/IP
(fr, eth, hdlc) (fr, eth, hdlc)
PW over MPLS MIB PW over l2TPv3 MIB (TBD)
--Tom Nadeau
[/end from mailing list]
????- how about a single document for MPLS and a single doc for L2TP?
then PW specific documents can refer to a field defined in these docs like
"these bits go into the flags field defined in the PW over L2TP doc"
Luca - ordering should be reversed
Scott- should PW over MPLS and L2TP have any fr, eth, hdlc specific info at all?
-----------------------------------------------------------------------
draft-reigel-pwe3-tdm-requirements-00.txt
open issues
more terminology necessary for TDM emulation
need specification of CAS and CCS
Channel associated signaling and common channel signaling
need synchronization reference model
should requirements for SONET/SDH emulation be added?
Danny- This should definitely become a WG document
Should it be folded into the current requirements document?
Scott- fundamental question is whether we should try to emulate technology
exactly or point out what is different
Emulation is not necessarily useless even if it doesn't meet every application's
requirements
Yaakov - want to fold these requirements into TDM documents since some of these
requirements are very specific to a particular TDM application
----------------------------------------------------------------------------
TDMoIP Real world issues - Yaakov Stein
RAD - over 9000 TDMoIP ports deployed
Market wants average of 4 E1/T1 ports per edge device
Less than 1% of ports were E3/T3
The point is that T1 level emulation is a more appropriate problem to solve
School districts began using voice over IP, but they didn't like voice quality
and delay
RAD replaced VoIP with TDMoIP
>90% of access network is CAS (PBX interconnect)
Kireeti - Makes the comment that Yaakov's presentation is too much
marketing for his taste
Scott - Asks Yaakov to concentrate on facts
AAL1 - requires high reliability
AAL2 - useful for toll bypass, people don't expect high-reliability -ex. point
of sale applications
Cellular telephony
Requires 50ppb clock accuracy - will RTP really work here?
Scott - Maybe 50ppb should not be a design group goal, maybe PSN should not be
used for some applications. It is not the PWE3 group's goal to define procedures
to support every application.
Yaakov 50ppb can be done, but requires a lower layer mechanism different from
RTP
Ray Jangar? (PMC Sierra) - TDM over IP is a real requirement - seeing
requirement heavily in Asia
----------------------------------------------------------------------------
CESoPSN update - Sasha Vainshtein
draft-vainshtein-cesopsn-03.txt
Control word aligned as much as possible with draft-malis-pwe3-sonet-03
Structure pointer is always 0
Will emulated CE to CE service experience prolonged outage if an occasional
CESoPSN packet is lost?
No for both structured and unstructured modes, but for different reasons...
Convergence issues
Common applicability statement and control word with draft-pate
(CEP) CESoPSN vs TDMoIP (draft-anavi)
[Comments from mailing list]
I have said that both are common with draft-malis (CEP) and draft-pate (CEP-VT),
and that the commonalities, as well as certain partitioning of the application
space will be presented by Ron.
> CESoPSN vs TDMoIP (draft-anavi)
I have said that merging TDMoIP "unadapted" format (introduced in the latest
release of draft-anavi) should be simple, but the issue with the AAL1/AAL2-based
("adapted") formats remains open.
-- Sasha Vainshtein
[End comments from mailing list]
-----------------------------------------------------------------------
Extending SONET/SDH CEP for low rate signals - Ron Cohen
draft-pate-pwe3-sonet-vt-00.txt
This draft extends draft-malis to SONET VT1.5/2/3/6 and SDH VC-11/12/2 but with
no extension to its applicability statement
It adds bandwidth saving modes
??? - Why add vt3, vt6 since they are not used in the real world?
Ron - agrees, but vt3 and vt6 come for free
[Comments from mailing list]
TDM Common Applicability Statement - Ron Cohen
http://www.ietf.org/internet-drafts/draft-cohen-pwe3-tdmsonetapp-00.txt
common to:
draft-malis-pwe3-sonet-03.txt
draft-pate-pwe3-sonet-vt-00.txt
draft-vainshtein-cesopsn-03.txt
-- Ron Cohen
[End comments from mailing list]
Applicability
fidelity of emulated TDM services
fault isolation and performance monitoring
PSN considerations - path MTU, bandwidth saving modes
P2P PDH emulation
MP2MP SONET/SDH emulation
draft-malis-pwe3-sonet-01.txt does STS-1 and above
draft-pate extends to VT level
MP2P PDH to SONET emulation
common applicability statement
-----------------------------------------------------------------------
Andy Malis - Frame Relay draft
no slides - We have seen the presentation too many times already
Have reached agreement on encapsulation
Must decide how to organize documents (1 doc, 2 docs ?)
[Comment from mailing list]
I said that the discussion at this point is strictly editorial on document
organization.
-- Andy Malis
[End Comment from mailing list]
-----------------------------------------------------------------------
ITU developments in ATM encapsulations SG13 -Ghassem Koleyni
ATM-MPLS Network Interworking
ITU has agreed on a compromise that allows both "Martini" style encapsulations
and ATMf style encapsulations
Two cell modes
one to one mode (based on ATMF cell mode - includes VCI present bit, PTI,CLP)
N to one mode (original Martini encap - includes VPI/VCI,PTI,CLP)
Frame modes
AAL5 PDU
AAL5 SDU
Ghassem shows the encapsulation for each mode
ITU has produced two documents
cell modes defined in Y.atmplsC
frame modes defined in Y.atmplsF
Stewart - why are the control words different?
Please repeat part about security
Ghassem - OAM security cell needs to be sent right away, can't re-order these
admin cells with user cells
Danny - wants to see compromise encapsulations posted to mailing list
Ghassem - people involved should get together this week to combine drafts
Scott - it has been a problem in the past when multiple standards bodies come up
with solutions to the same problem - random movement of bits is not a good idea
-----------------------------------------------------------------------
Discussion of Martini ATM and Ethernet drafts - Luca Martini
draft-martini-atm-encap-mpls-01.txt
changes since 00
merged draft-martini-atm-encap-mpls-00 and draft-brayley-pwe3-atm-service-01
added appendix about defect handling
cell port mode moved to appendix
removed AAL5 PDU mode, will put it back in based on draft-fischer
added applicability statements
Will merge content with draft-fischer-pwe3-atm-service-02
draft-martini-ethernet-encap-mpls-01.txt
merged draft-so-pwe3-ethernet
??? - Why two modes? One strips vlan from packet before sending on the tunnel
and one keeps VLAN tag
Luca - Most vendors use VLAN tag mode since it is easy to implement on routers.
The goal is to produce encapsulations that most vendors are able to implement
Stewart and Mark Townsley - use principle of minimal intervention and keep VLAN
tag, don't strip the VLAN tag
Scott - at minimum we should have one required mode
Ragu - why is this different from FR encapsulation?
Kireeti - Ethernet switches don't switch VLAN tags but FR switches do switch
DLCIs
Discussion of draft-martini-l2circuit-trans-mpls-09.txt
Add requirement for VLAN translation at egress (currently an option)
Move IANA considerations to separate document
Scott - Split references for normative and non-normative references in documents
Other items
need to provide inter-domain solution
IANA guideline document
Kireeti - Should this work be done in PPVPN or PWE3? (exchanging VC labels)
Danny - Endpoint discovery is PPVPN, signaling setup and maintenance is PWE3
Kireeti - Why is VPLS in PPVPN and not in PWE3?
Scott - We have been assuming that all circuit establishment is in PWE3
Scott - What is different at byte level between intra- and inter-domain PW
emulation?
Luca - byte level is not different but maintenance is different one domain
should not be able to establish circuits across another domain
-----------------------------------------------------------------------
Danny - please reword documents to align with protocol layering documents - most
are not
Danny - Security considerations are currently very weak - must be addressed or
docs will not be progressed
Scott - Hackers are really interested in seeing wide-area layer 2 networks
Kireeti - It is sad that we have converged on a single encapsulation because we
could make the hackers guess at which mode is being used!
Scott - This is called security through obscurity...
********
Meeting adjourned at 11:15.
Slides
Agenda
Extending SONET/SDH CEP for Low Rate Signals
- Prayson Pate
- Ron Cohen
- David Zelig
- Ashwin Moranganti
TDM Common Applicability Statement
TDMoIP Real - world issues
ATM and Ethernet Encapsulation
Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks
PWE3 Protocol Layering
- Stewart Bryant
- Danny McPherson
- Mark Townsley
- Lloyd Wood
An Update on CESoPSN
- Sasha Vainshtein
- Israel Sasson
- Akiva Sadovski
- Eduard Metz
- Tim Frost
- Prayson Pate
PWE3 Protocol Layering
- Stewart Bryant
- Danny McPherson
- Mark Townsley
- Lloyd Wood
ITU-T Compromised Solution on ATM - MPLS NETWORK INTERWORKING