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 |
Current Meeting Report
Pseudo Wire Emulation Edge to Edge (pwe3)
Wednesday, December 12, 1300-1500
=================================
Chairs: Danny McPherson <danny@tcb.net>
Luca Martini <luca@level3.net>
AGENDA:
1300-1315 Administrivia (15 minutes)
Agenda Bashing
Minutes
Blue Sheets
WG Document Status
1315-1325 PWE3 Protocol Layering Discussion
Stewart Bryant <stbryant@cisco.com>
http://www.ietf.org/internet-drafts/draft-bryant-pwe3-protocol-layer-00.txt
1325-1330 PWE3 Framework Draft
Xipeng Xiao <xxiap@photuris.com>
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-requirements-02.txt
1330-1335 PWE3 Requirements Draft
Prayson Pate <prayson.pate@overturenetworks.com>
http://www.ietf.org/internet-drafts/draft-pate-pwe3-framework-02.txt
PWE3 TDM Drafts
1335-1345 Prayson Pate <prayson.pate@overturenetworks.com>
Ron Cohen <ronc@lyciumnetworks.com>
David Zelig <davidz@corrigent.com>
http://www.ietf.org/internet-drafts/draft-pate-pwe3-tdm-02.txt
1345-1355 Sasha Vainshtein <sasha@axerra.com>
ftp://ftp.axerra.com/sasha/draft-vainshtein-cesopsn-01.txt
1355-1405 Discussion of TDM Drafts
Motty Anavi <motty@radusa.com>
http://www.ietf.org/internet-drafts/draft-anavi-tdmoip-02.txt
http://www.ietf.org/internet-drafts/draft-pate-pwe3-tdm-02.txt
http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-00.txt
PWE3 Ethernet
1405-1415 Tricci So <tso@caspiannetworks.com>
http://www.ietf.org/internet-drafts/draft-so-pwe3-ethernet-00.txt
PWE3 Frame Relay
1415-1425 Clause Kawa <kawa@nortelnetworks.com>
http://www.ietf.org/internet-drafts/draft-kamapabhava-fr-pwe3-00.txt
1425-1435 Stewart Bryant <stbryant@cisco.com>
http://www.ietf.org/internet-drafts/draft-bryant-pwe3-fr-encap-00.txt
http://www.ietf.org/internet-drafts/draft-bryant-pwe3-fr-compare-00.txt
PWE3 ATM
1435-1445 Discussion of ATM Drafts:
Matthew Bocci <matthew.bocci.alcatel.co.uk>
http://www.ietf.org/internet-drafts/draft-fischer-pwe3-atm-service-02.txt
http://www.ietf.org/internet-drafts/draft-brayley-pwe3-atm-service-01.txt
PWE3 SONET
1445-1455 Tom K. Johnson <tom_johnson@litchfieldcomm.com>
http://www.ietf.org/internet-drafts/draft-malis-pwe3-sonet-01.txt
1455-1500 Wrap Up
========================================================
IETF 52 WG Meeting Minutes
Recorded bv Richard Rabbat <richard@perth.mit.edu>
Danny McPherson, Opening Slides:
WG Objective:
o Try to merge competing proposals where it makes sense.
o Discuss chartered services briefly
o Review current drafts and try to reach consensus
o Comments welcome -- please send to mailing list
Document Status:
Requirements document accepted as WG document, need comments from WG.
Framework document went to last call (to become WG document). Lots of comments, need to move to WG doc.
If writing service drafts, read charter, frameworks document and requirements documents before going forward to WG.
Martini drafts were submitted to RFC Editor to be published as Experimental. IESG considering what to do with document, looking for comments -- iesg@ietf.org.
Xipeng Xiao: PWE3 Requirements Document
"Requirements for Pseudo-Wire Emulation Edge-to-Edge"
o current version is -02
o back in May, 00 version that got a lot of comments that were incorporated in 01, by London.
o very few comments since
o considered stable now
Changes with 01:
o organization of some sections:
- forwarding plane reqts
- control plane reqts
o most changes largely editorial
o feedback positive
In London IETF, people requested clarifications to be made to:
o packet ordering reqts: may be applied to control packets only or to both control and data packets
o pw's can be either MPLS LSPs or L2TP sessions
o added security consideration for use of non-path-oriented PWs
o cleaned up references
o request to add some mention in reqts of the kind of quality of service
o clarification: whether atm cells can be transported, or just frames
Q. what are the generic requirements?
Q. agreement to change faithfulness section
Q: in draft, when discussing L2TP 3, clarify whether it is L2TP 2 or 3
A: reference was change between L2TP 3 and 2
Q: wondering about deletion of IP
A: paragraph that if one wants to carry timestamp from one end to the other then use RTP.
Q: use IP underneath?
A:from chair: yes
CHAIR: please send any other comments to mailing list
Stewart Bryant: "PWE3 Protocol Layering"
Layering issues:
Current approach piecemeal: each payload design team has own solution
e.g.: ethernet and frame-relay, but not packet
e.g.: TDM services defining specific real-time support, requiring new packet services to define rt
Current layering approach diagram with current vertical stack approach.
Agreement on bottom layer up to IP v4, v6 and MPLS
Payload Framework:
o requesting generic types sent similarly on the wire shim-layer for specialist teams to design including bit-specific, cell-specific and packet-specific info payload commond support
o suggest common timing/sequencing layer, maybe working with the RTP folks
Proposed Protocol Layering
o focus of pwe3: above common multiplexing layer
o also suggested an alternative layering model agree to have common structure above the RTP layer switch the order of some layers. refer to diagram on slides
Recommendations:
o layering model be incorporated in the PWE3
o framework draft move to generic, rather than individual payload types
o send payload transparently rather than intermediate format, making translation for switch support a value-added service
o we define operation of PWE3 over IP and MPLS separately
Comment: reference model has value
Q: the RTP timing requirements are quite different for services like sonet vs. atm. with RTP-like timing mechanism, may add too much overhead and rtp may not be adequate for service jitter
A: one payload team has used RTP. let's talk to RTP guys
Comment: calling it RTP is fine, but it is not really RTP
Q: efficiency on the wire? move towards efficiency or layering?
Q: in frame-relay, length of header is local to the interface. more efficient to build the header at the egress
A: not convinced by argument. own implementations haven't seen this issue switching vs. frame relay
Steve Casner: implement t3 over RTP implementations and the clocking works fine
Yakov Stein: some issues: separate bit-serial vs. byte
vs. packet in tdm, bit-stream and both byte-stream for T1 and E1 payload is sent transparently.
AAL 1 over wire will also be different from tdm over wire
A: some packaging arrangement has to happen. trying to confine <>'s to smallest areas of protocol
Q: trade-off between efficiency and layering
A: team will have to work very carefully on how payload is designed
Comment to yaakov: unframed E1, etc. are all bit streams
PRAYSON PATE:
Update on framework draft
Changes:
o -01 was presented in London, then revised
o most changes editorial
o need to remove excess text, add input from Bryant and chairs draft will be updated and submitted for acceptance as WG item
Q: Has it been accepted as a WG item?
CHAIR: one reply said no, so waiting for more people to reply and more work needs to be done framework is NOT a wg document YET, now sending a last call to become a wg doc
YAAKOV & ANAVI:
Aagenda:
o draft-anavi-tdmoip
o draft-pate-pwe3-tdm
o draft-vainshtein-cesopsn
o comparison
o questions
Slide: classic telephony with access network of analog lines to CO switch class 5 to SONET/SDH, synchronous, 'non-packet based
New picture: TDMoIP, with packet network in the core (IP or MPLS) pseudo-wires over packet networks wants to transport:
o voice tones & fax and modem
Transmissions, signaling, timing lost packets for voice may not be very important but in other cases, very important problems with encapsulating T1/E1 frames.
Wants:
o fine-grain latency vs. efficiency
o efficiently handle fractional T1/E1
o No lost packets
o Avoid service interruption
o increase granularity
o add pointer to next (super)frame boundary
o only send desired timeslots
o add packet sequence number
AAL1 is inefficient if the timeslots are hard-wired to allow dynamic allocation, use AAL2 not just ATM
AAL1 and AAL2 are adaptation protocols
Suggest:
-----------------
ip header
-----------------
udp header
-----------------
optional rtp header
-----------------
TDMoIP header
-----------------
TDMoIP payload
-----------------
CHAIR Q: if you consider high-speed links, what kind of delay problems will arise?
A: this proposal for T1/E1 and maybe T3/E3, but not high-speed network
CHAIR Q: if you send over OC-192, what do you do?
A: solving efficiency problem, not timing problem
Q: how are u planning on muxing/demuxing multiple streams?
A: go back to draft to see bundle number, multiple bundles
Comment1: framework proposal has some work on bundling that may be used
Comment2: maybe not use the martini proposal
Prayson Pate:
-------------
o another approach
o looking at other applications, where interaction with
o SONET networks will be important
How to allow fractional STS encapsulation?
Requirements:
o circuit emulation from t1 to t3
o compatible with SONET/SDH CEP as defined in
draft-malis-pwe3-sonet
o use well-defined SONET/SDH
o extend OAM's
E1/T1 solution:
o VT encapsulation
o fractional T1 as well
VT encapsulation:
o use SONET/SDH CEP header
o pointer points to V5 byte
o up to multi-frame payload size
Fractional sts-1
o carry bytes of VTs
o maintain end-to-end BIP
Summary:
o simple extension to SONET/SDH CEP
o suggest adoption as wg item
Q: payload is 104 bytes, isn't VT different?
A: not setting
Q: why bring all the complexity of T1 and E1?
A: the mappings work fine
Q: you don't have sonet add/drop boxes
A: while it is attractive to use new protocols, this exists and works well and has silicon chips for that. we also have consistent approach from T1 and up
Comment: putting too much complexity
A: building boxes today
Stewart: are the boxes in-scope or added service?
A: # of discussions b/c of the way somebody wants to build a switch, fine line. my proposal proposes a convenient format.
SASHA VAINSHTEIN:
CESoPSN encapsulation for emulation of low-rate TDM circuits over PSN. FROM fractional to unstructured T1/E1 to up E3 and DS3 minor modifications to unstructured low-rate SONET application to class 5 networks.
Synchronization:
o minimal requirements to the PE synchronization
...
Highlights:
o configurable fixed size payload:
o limited by path MTU and packetized
Delay reqts
o fixed for PW life cycle
o multiple of the size of the natural
Delineation data chunk
o always octet-aligned
RTP header:
o carries clock of incoming ES from ingress to egress over PSN
o marking
o sequencing
o misconnection and mistype defects detection
o compatible with RTP header compression
Techniques
Control Word:
o dynamic bw allocation (save bandwidth in case of end service outage)
o signaling problems detected at ingress.
other issues
OAM issues:
Defects:
o hierarchy of defects considered
o PW loopbacks
Issues for further study were also listed
Based on working implementation
Proposed for wg document
----
COMPARISON:
Consensus comparison of 3 approaches:
*contentious issues intentionally left out*
o Chart on provided services
o IPR claims
Steve Thomas: Q: conclusions from interim meeting in tel-aviv were to merge 2 proposals and move one to SONET
A: nothing of the Tel-Aviv meeting agreement happened not found a way to combine approaches first and third approaches have sufficient overlap that may be worked out CEP people have a very different approach CEP people have been trying to work with SONET
Comment: if a box implements the 3 approaches, bad!
TRICCI SO:
Ethernet Pseudo-Wire Emulation Edge-to-Edge
draft document: draft-so-pwe3-ethernet-00.txt
References model & scope
o diagram with PSN tunnel from pe 1 to pe 2
o focus on the PW termination for the pt2pt configuration only multi-pt is referred to draft-lasserre-vkompella-ppvpn-tls
o support both raw and tagged virtual port modes considering MPLS, GRE, and L2TP as the tunneling technologies no new signaling mechanism
pt-to-pt reference configuration with PW termination processing
o setting up
o maintaining
o encap/decap
Did not consider on adaptation, leave it to Ethernet
o Emulate pt-to-pt Ethernet trunking and switching behaviour
o Setup Ethernet PW between PE devices over the PSN tunnel
o Encapsulate Ethernet PDUs
o Describe maintenance interactions,
Ethernet PW outsdanding issues:
1. lack of signaling support for Ethernet PW over GRE to coordinate VC/PW label distribution and maintenance support
option 1: develop new signaling
option 2: implement MPLS-in-GRE like approach to leverage GMPLS signalling
2. to convey the PW/VC ID for Ethernet PW over L2TP
3. need to determine if fragmentation is needed for the Ethernet pw
4. ethernet pw over mpls design is aligned with Martini draft
5. how to align the pw design approaches among different draft, e.g. PW over L2TP?
NEXT STEP
o Clarify with ADs if on right track
o requesting input from PW wg
o need to collaborate with L2TP WG on the PW ID reqts
o clarify how above issues can be solved
Conclusion
o requesting that the draft become the wg document
Chair: work is very good. enclined to move to wg doc.
Comment: in terms of identifying Ethernet at pw, it already exists; some fields may be leveraged, email back and forth to iron this out
Chair comment: please incorporate updates to wg document
A: sure, more discussion offline
CLAUDE KAWA: Frame-Relay over PW Emulation Edge-to-Edge
draft-kamapabhava-fr-pwe3-00
Ojective:
o write draft on frame relay on pw's
Header format (based on Martini draft)
Packet processing specification
o general procedures covering all types
o specific procedures for MPLS LSP, IP w/ or w/o GRE
Maintenance protocol
o lightweight protocol
2 functions:
o exchange PVC status between two PW edges
o perform keep-alive functions in the
Abense of user traffic
Remains to be done:
o bug fixing
o enhance section of frame relay over pw packet processing
o section on L2TP not done yet
o PVC maintenance protocol needs more work address QoS signalling for SVC and SPVC establishment
Q: is it appropriate to define a signaling mechanism or use pre-defined mechanism such as L2TP signaling?
A: can use different signaling include frame-specific LMI
Comment: maybe no need to send LMI in-band, and use specific L2TP
Q: don't understand why processing of frame-relay is very different depending on underlying layer
Q: what happens with frame relay control bits? are they just encapsulated?
A: we have to process bits. they will not be copied blindly
Q: no text in draft
A: not written yet
Q: may need additional bits
A: no answer
Q: need a way to signal PVC over pw, so we adopted technology used in FR
A: agree
Comment: Include in-band or out of band signaling (that will have the list of PVC signaling). Decide to use in-band as it is simpler on the operational side.
Q: single tunnel or multiple tunnels?
A: flexible
STEWART BRYANT AND LLOYD WOOD
Encapsulation Header
o 2 methods discussed for sending frame-relay PDUs over a pw
o why do we need 2 header translations?
o critical bits are in the right relative positions
o translation process is trivial
o: separate convergence and payload
Frame relay without abbreviation
o uses generic packet payload type
o simple and efficient
o draft-kamapabhava-fr-pwe3-00, easy micro-code operation
Proposed change to follow martini header twisted bits
recommendation:
o send frame-relay packets transparently and unchanged if we must use intermediate type, use efficient format
Q: assume blind copy of bits, whereas significant processing
A: customer doesn't care about bits. in addition, some send FR w/o calculated values
Q: discussion that we had during discussion of Martini header encapsulation in a lot of cases, header length is local to the local interface, maybe no need to carry it
moved to a discussion between 2 fellows
Comment: considerations implementation-dependent
Q: are we emulating pw or pw with some part of the box?
A: pw
Q: 2 modes of operation:
o per vc
o transparent
Why not do that in FR?
A: boxes from different vendors won't work
Kireeti: need some sequence number if we're doing signalling
Mark: which fits the layering model
Comment: as a provider, don't know what is sent, so I need sequence number
BOCCI: ATM service draft-fisher
draft-fisher compromise between draft-martini and draft-koleyni
support ATM over IP/GRE, l2tp and mpls
combines features /simplicity of drafts w/ bw efficiency/transparency
PW's can be:
o atm vcc's
o atm vpc's
o atm ports
Each mpls packet can carry
o 1 atm cell
o concatenated atm cells (for bw efficiency)
o aal5 pdu or sdu
Features:
o optional sequence number
o optional length field
Chair interrupted: interested people have read the draft. what are the differences?
A: o fisher does not send VCI and VPI fields unless needed
o bit positions in control word are different
o fischer maintains protocol layering
o layer 2 information nearest layer 2 payload
Comment (to Luca): Are you interrupting as chair or author of a draft?
Chair: chair. need to move on this
draft-fisher builds on and is compatible with workg going with ATM Forum and ITU-T
Working group document
Chair: please send summary to mailing list
Suhail: Fisher draft is more efficient in comparison
testing in labs
Comment: Fisher draft based on implementation.
compatible with ATM Forum draft work is progressing very fast with ITU-T come up with one unique solution?
Chair interrupted
MALIS:
draft-malis-pwe3-sonet
Current status: sonet design team consensus differences between cep and cep provides base Sonet EM functionality multiple implementations underway
o Going forward: payload compression enhanced performance monitoring
o sonet emulation is part of pwe3
o basic concepts stable for over 1 year
o please adopt in wg...
Slides
Agenda
TDM Circuit Emulation over Packet Switching Networks (CESoPSN)
ATM Service draft-fischer
PWE3 Framework Update
'draft-malis-pwe3-sonet-01'
Comparison of Three Approaches to TDM over Packet
PWE3 Frame Relay
PWE3 Protocol Layering