2.3.21 Pseudo Wire Emulation Edge to Edge (pwe3)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-09-20


Stewart Bryant <stbryant@cisco.com>
Danny McPherson <danny@tcb.net>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Mark Townsley <townsley@cisco.com>


Matthew Bocci <matthew.bocci@alcatel.co.uk>

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/web/pwe3/index.html

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.


  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

  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
  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.


  General documents:

    Requirements Document

    Framework Document

    Common Edge-to-Edge Emulation/Maintenance Protocol

    Requirements for PW Traceroute (if distinct from tunnel-specific
    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


    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
  of the medium are out of scope.

  Methods to signal underlying network.

Other Working Groups We Will Coordinate With


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
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 2004  Fragmentation LC
Jan 2004  TDM Requirements LC
Feb 2004  SONET Documents Last Call
Mar 2004  TDM Documents Last Call
Mar 2004  PWE3 WG Charter Review, Additional Work or Ends
Apr 2004  Frame Relay Documents Last Call
Apr 2004  PWE3 MIBs Last Call
Apr 2004  SONET Documents Last Call
Apr 2004  FCS retention Last Call
May 2004  VCCV Last Call


  • draft-ietf-pwe3-pw-mib-06.txt
  • draft-ietf-pwe3-pw-mpls-mib-07.txt
  • draft-ietf-pwe3-pw-tc-mib-06.txt
  • draft-ietf-pwe3-sonet-11.txt
  • draft-ietf-pwe3-ethernet-encap-10.txt
  • draft-ietf-pwe3-control-protocol-17.txt
  • draft-ietf-pwe3-cep-mib-06.txt
  • draft-ietf-pwe3-enet-mib-06.txt
  • draft-ietf-pwe3-fragmentation-09.txt
  • draft-ietf-pwe3-atm-encap-10.txt
  • draft-ietf-pwe3-iana-allocation-14.txt
  • draft-ietf-pwe3-hdlc-ppp-encap-mpls-05.txt
  • draft-ietf-pwe3-vccv-07.txt
  • draft-ietf-pwe3-satop-03.txt
  • draft-ietf-pwe3-fcs-retention-04.txt
  • draft-ietf-pwe3-cesopsn-05.txt
  • draft-ietf-pwe3-tdmoip-04.txt
  • draft-ietf-pwe3-tdm-mib-04.txt
  • draft-ietf-pwe3-cell-transport-04.txt
  • draft-ietf-pwe3-oam-msg-map-03.txt
  • draft-ietf-pwe3-cw-06.txt
  • draft-ietf-pwe3-ms-pw-requirements-01.txt
  • draft-ietf-pwe3-segmented-pw-01.txt
  • draft-ietf-pwe3-tdm-control-protocol-extensi-00.txt

    Request For Comments:

    RFC3916 I Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
    RFC3985 I PWE3 Architecture
    RFC4197 I Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks

    Current Meeting Report

    PWE3 IETF63, Thursday November 10th 2005.
    CHAIRS: Stewart Bryant (stbryant@cisco.com) & Danny McPherson 
    MINUTES: Matthew Bocci with additional notes from Yaakov Stein
    SLIDES: Available at http://pwe3.tcb.net
    Agenda: Stewart Bryant
    Requested to move fibre channel to after MS-PW presentations, then OAM and then some other issues.
    No other comments on the agenda.
    Danny is not available this week and send his apologies. All but two sets of slides available. No slides, no presentation. This is a final warning!
    Status of WG drafts: Stewart Bryant
    Now have 3 RFCs 4197 is the new one: TDM reqs.
    Control draft is now in the RFC editors queue.
    Then a small batch in IESG review: went through IETF last call.
    Ethernet has a discuss on it saying that it needs an applicability statement. This will be added. 
    Needs to remove some text and a bunch of detailed edits.
    Blocking on a need for an IEEE review.
    Mark Townsley: not technically an IEEE review, rather asking some people in IEEE to review it. Asks for some people in the room who is involved or who know someone and who can comment on the flow control. Want to avoid invoking overhead of a formal IEEE review.
    IANA draft: one remaining issue to discuss, and some AVT related code points from the IANA draft. 
    Plan is to do this, then once in RFC editors queue IANA will create the registry. AVT will have to go though IANA process.
    ATM: needs applicability statement.
    Control word is in the RFC editor's queue.
    SAToP is ready, but Stewart needs to write proto questionnaire.
    Final WG last call: fragmentation, FCS retention, SONET, ATM cell transport. 
    Stewart asks for other people to review!
    David Black: Have heard that if no one reviews a document, then ceratin WGs won't progress it.
    Andy Malis: These documents have been reviewed many times
    Mark Townsley: just needs to be reviewed at some
    Outstanding WG last comments: the following need minor edits: FR, HDLC, CESoPSN, TDMoIP
    Work in progress: mostly MIBS. Also need MIBs for ATM, FR etc
    All else is work in progress.
    Charter: Danny sent last call on the charter. Added PW protection. This will go to the IESG in a week or so.
    An Architecture for Multi-Segment PWE3 
    Matthew Bocci (matthew.bocci@alcatel.co.uk) 
    Presents an overview of the updates since the last version. 
    The terminology has changed: a U-PE is now called a T-PE
    Added maintenance reference model, and S-PE functionality
    Matthew shows the reference model (end-end signalling and hop-hop as well)
    S-PE capabilities: S-PEs do not have NSPs and do not see native service circuits 
    Service up only if both directions up in all segments
    Mechanisms need to be provided to prevent misconnection, e.g. ensuring PW types are compatible 
    Security section (based on 3985): if S-PEs are dynamically selected, they need ASBR like behaviour
    Need mechanisms to prevent misconnection of segment into an AC
    Asks for comments and text and proposes to make this a WG draft
    Luca Martini: if there is a set of providers, need authenticate originator, not just other provider
    Yakov Rekhter: Authentication originator is similar to Secure Origin BGP, which is known to be fairly complex. For now we should focus on authenticating peers, rather than source authentication.
    Sasha Vainstein: MS PW up if both directions of all segments are up - isn't this already implied?
    Matthew: Need to traverse same S-PEs, but there is no implication if you set up all segments in one direction, followed by all in the other direction, or if you do both directions simultaneously in a hop-by-hop manner. This statement says that either way, you must wait until all segments in both directions are up.
    Stewart Bryant: Who agrees with making this a WG draft? There is an overwhelming majority
    Dynamic Multi-Segment Pseudo Wire Signaling Procedures Using LDP
    Florin Balus (balus@nortel.com) 
    Matthew Bocci presents the first section.
    Background: set and maintenance by extending standard PWE LDP protocol and there is the segmented PW draft, where you must configure S-PEs. In the last IETF there were two drafts for using LDP to dynamically select S-PEs. These have subsequently been merged. 
    This new draft works for SS and MS PWs, with a minimal number of provisioning touches (only T-PEs).
    The same T-PEs and S-PEs are used in both directions. The signalling of TE parameters and CAC is supported, as well as  end-end negotiation of OAM.
    Florin Balus takes over the presentation. 
    Addressing format that allows dynamic selection and summarisation.
    Allows tracing without revealing private layer 3 addresses.
    Shows example of MS-PW information model - unique identification of the PW endpoint.
    Claims it is consistent with the existing addressing.
    Shows an example of the signalling procedures. MS-PWs effectively behave as a superset of SS-PWs
    Routing information is disseminated using static provisioning or dynamic advertisement e.g. with MP-BGP.
    Other related procedures: QoS TLV, Explicit routing, OAM negotiation, FEC 128 support
    Next steps: need feedback on the hybrid FEC128/129 usage case
    High level of interest so would like to progress to a WG draft.
    Sasha Vainstein: how are roles of initiator and responder of signalling determined?
    Florin Balus: compare TAII and SAII, or provisioning
    Yakov Rekhter: Explicit route LDP: is that from CR-LDP? 
    Yakov Rekhter: Are you using RSVP T-SPEC?
    Florin: yes
    Yakov Rekhter: How hard would it be to use CR-LDP?
    Florin: no need to ask for a new type. There was a draft on mapping to TSPEC
    Easy to use RSVP-TE tspec. CR-LDP uses a mapping to TSPEC object. 
    Yakov Rekhter: How do you do reroutes around failures in static routing
    Florin: can use a default gateway configuration
    Yakov Rekhter: How can you do loop avoidance?
    Florin: Routing protocol will do this, or can use PW switching TLV
    Rahul Aggarwal: On next steps, at last IETF we had a section on MS-PWs. There was a decision that the requirements draft needed to be revised with required/optional requirements. We need to continue this. Not sure it is constructive to go to WG draft at the moment.
    Florin: if there is another interest, should go ahead. Don't see a reason to peg the two solutions together.
    Stewart Bryant: The question is reasonable, just as you asked for RSVP draft. However, it is also appropriate to ask about the revisions to the requirements document.
    Luca Martini: we have revised requirements document in this way
    Peter Busschbach: At some point we had a discussion that QoS was needed for the intermediate points as well as the end points. Is QoS relevant only to end-points or to intermediates? 
    Florin: May or may not use it if you need CAC 
    Peter Busschbach: Must it be?
    Florin: Cannot mandate a must.
    Peter Busschbach : Should clarify this point.
    Dave McDyson: do we really need one solution? Trying to strive for one size fits all may not be possible.
    Stewart Bryant: I will ask individually if each draft should be a WG draft. 
    Dave McDyson: by saying that you support this, you are not excluding the other draft.
    Stewart Bryant: Each draft has to independently justify its existence
    Yakov Rekhter: If you do carry T-SPEC, should you use this to select next hop, and do you need extensions to BGP? That is, information that may be matched to TSPEC.
    Florin: we just advertise reachability at the moment. Can use IGP
    Yakov Rekhter: IGP doesn't do this. Do you want to extend BGP for inter provider case?
    Luca Martini: Think we can use mechanisms that we have today. We have had extensive discussion on the list about the RSVP-TE draft. Result was no consensus to progress this work. It is still missing major parts of the design. We need to make a choice.
    Rahul Aggarwal:  In the IETF in Paris, the room was polled for both versions. My view from the audience was that there similar support.
    Mark Townsley: would strongly urge the group to make a choice. If anyone believes that it is impossible with one or the other, say now.
    Luca Martini: It was 3:1 or 4:1 in Paris in favour of LDP
    Yakov Rekhter: The choice shouldn't be driven by the IETF, but by the market. 
    Dimitri Papadimitriou: What happens if there is an overlap in the markets?
    Mark Townsley: I am asking that if they apply to substantially the same environments, make the choice now. 
    Kireeti Kompella: Heard Dave McDyson saying "I don't know which one I want now". This is different from saying that if they are for the same environments, choose now. We may not have enough information to choose now. This is different from RSVP vs CR-LDP : they were much closer. Need to put a line in the sand saying that we do not go forward to draft standard. It is not impossible to do 
    this with either LDP or RSVP. That is not the issue. Should do both because there are different ways of doing things and come back to the discussion when we are at draft standard status. 
    Dave McDyson: The way to do this is to add applicability statements to each draft. Would like to see both progress and understand the applicability.
    Mark Townsley: I asked if this impossible with either. Kireeti answered that. So, I asked, is it impossible with both? Is it a requirement that the T-PE initiator is single hop or multi-hop? 
    Stewart Bryant: How important is it to co-exist with single hop? Personally, I think so.
    Kireeti Kompella: Need to take consensus independently on progressing them. 
    Ping Pan: This is up to the market to decide. There is an implementation available: got it working already between last IETF and this IETF.
    Luca Martini: How many tests of consensus do you want?
    Stewart Bryant: Who here thinks we need to come to a firm conclusion that we 
    Mark Townsley: How many want one solution, how many want two?
    Stewart Bryant: How many want one solution before progressing?: Quite a few
    Stewart Bryant: How many want to take them both progressed and make a decision later?: substantially more.
    Yaakov Stein: if we go forward like this, and we have a QoS issue, do we have to have RSVP for single segment?
    Luca Martini: how many people want three or four?
    Stewart Bryant: Who thinks this should be a WG draft? Large number in favour
    Setup and Maintenance of Pseudowires using RSVP-TE
    Dimitri Papadimitriou 
    Dimitri presents the status of the draft.
    The authors have progressed on refining the text and the procedures. Sender_TSPEC clarified.
    Discussion: do we need to document how this fits the requirements?
    Authors ask for this to be a WG document
    Luca Martini: We discussed this document at length on the mailing list. We didn't have consensus then. What has changed? My questions were things like how you do status, addressing.
    Dimitri: The document discussed after Minneapolis was not as presented today. 
    Stewart Bryant: there was a discussion and no consensus. Are there outstanding technical issues?
    Luca Martini: we have not addressed how you do the addressing and status messaging. This document has a sketch of how you do it, but someone has to write it down in detail.
    Rahul Aggarwal: PW FECs can be used. Does the choice of which is ready to be implemented need to be addressed yet? No.
    Luca Martini: Needs an addressing scheme for layer 2. In the LDP draft, made a big effort to specify all of the addressing details.
    Stewart Bryant: There should be a reasonable expectation that it will be a viable technical solution
    Stewart Bryant: Asks who agrees with making this a WG draft: A moderate number.
    Should put both to the list.
    Rahul Aggarwal: I think we should progress both and ask the question a bit more carefully
    Eric Rosen: Sometimes a WG is willing to accept a document because they think the alternative is that the authors will mount a DoS attack on the WG, and I wonder if that's the case here.
    Dave McDyson: It would be helpful to have applicability statements and additional work e.g. references to use cases.
    Stewart Bryant: I agree that there needs to be clear applicability statements.
    Himanshu Shah: would like to see this
    MarK Townsley: There must be a section in each draft explaining how they co-exist.
    Stewart Bryant: That includes co-existence with the old stuff
    George swallow: Does this also mean interoperability in the inter-provider case?
    Mark Townsley: It means interworking.
    Dimitri: What's a coexistence section? 
    Stewart Bryant: We do have an existing single hop solution that is deployed, so they both need a section showing this.
    Stewart Bryant: Do we have to co-exist with existing PW control? Strong support.
    So all solutions will have to describe how they co-exist.
    Morin Roth: can write this.
    Stewart Bryant: Who is against making this a WG draft? A few. Will ask the question to the list.
    [Note: This topic was discussed at length on PWE3 mailing list following the meeting. The reader is referred to this for further information. ]
    Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks
    Ronen Solomon (RonenS@corrigent.com) 
    Presents an overview of the draft. This was originally presented in Paris.
    T11 approved FC-BB4, which allows MPLS transparent p2p FC transport over PW.
    Idea is to take FC ACs and have PW emulate end to end service. NSP is handled by T11
    For the new version of the draft, we added applicability. Faithfulness improved by providing low loss, low reordering of event, low delay, NSP handles bandwidth-controlled behaviour during congestion.
    FC data frame, control and primitive sequences use the same PW.
    Shows an overview of the signalling.
    MTU: the PSN should be able to transport the largest FC encapsulation.
    Control word: must use the PW control word.
    Assign new PW type for FC
    Would like to go to WG draft
    David Black: there is no RFC2581-class (TCP-class) congestion control in
    Fibre Channel, hence leaving congestion control to the NSP (i.e., Fibre Channel) will not be acceptable (to the Transport Area) in all cases. Need you to write up an applicability to networks as you move from low loss, tightly constrained networks, to where you have congested anything goes IP network. Need to identify where you do need TCP congestion control, and where this is therefore not applicable. I will run this by some transport area experts.
    The applicability statement needs to be carefully written, particularly with respect to the expectations on the PSN.
    Stewart Bryant: If they accept a controlled environment then this would clearly work, and can work on it if there is interest.
    There were no objections to Fibre Channel draft becoming a working group document. It will be asked once again on the list.
    Link Aggregation Member Interface Status Signal
    Zi Kang (zikang@huawei.com) 
    Presents motivation 
    PWE3 requires same BW on each AC
    Shows a use case: all ports are a member of a trunk. Handles case if one AC on a trunk fails.
    Introduces a new TLV indicating BW.
    Asks for comments.
    Ping Pan: why can't do this with VCCV? Also, can't RSVP deal with this if you do link aggregation?
    Zi: No VCCV for RSVP
    Stewart Bryant: Isn't he worried about external link rather than internal?
    Himanshu Shah: There is a common solution to QoS on PW. This has already been documented in the PW QoS signalling draft so doesn't see any need to do this.
    Sasha Vainstein: You say PWE3 requires the two ACs to have same BW. Apart form TDM, I do not remember this as a requirement for anything else.
    Stewart Bryant: There is no such requirement for any packet or cell services.
    Luca Martini: You are trying to create a PW type for trunks. That might be a useful solution, but today people are deploying one AC for one PW, and using trunks over this. We can make this work today by just provisioning.
    Scott Brim: Compare with what you would do in a physical environment. If one port fails, don't you just kill the whole trunk?. Don't think you should require something in PW technology.
    George Swallow: This just makes you drop earlier. 
    Stewart Bryant: can I ask that you articulate the requirement more precisely to the group on the list.
    Scott Brim: and a little more clarity about the specific service that you are carrying over the PW
    Operation and Maintenance for Multi-segment Pseudo Wire
    Jixiong Dong (dongjixiong@huawei.com) 
    Two levels: segment and end to end OAM.
    End to end OAM packets transparent to the S-PE.
    Proposes an in band FDI generated on a PW segment failure. This results in an RDI from the remote T-PE, or PW status.
    In order to distinguish end-to-end OAM, includes a new VCCV packet type.
    Next steps: RDI and PW mismatch
    Monique Morrow: What is the difference between this and what is already in the PW segmented draft?
    Ping Pan: PW segmented draft doesn't have OAM
    Jixiong: Segment OAM is only for faults on one segment. 
    George Swallow: the way this is built, it will be a lot easier to do the end-to-end bit. Only way to catch this is TTL. 
    Dinesh Mohan: The framework is the right way to look at it. I'm not sure of the specific solution. This seems to imply a change to the existing SS-PW OAM. Need to avoid this.
    VCCV Extensions
    Yaakov Stein (yaakov_s@rad.com) 
    Two PW OAM methods: original TDMoIP had one OAM PW per tunnel, and assumed defects are the same for all PWs.
    VCCV OAM: OAM packets in each PW. Higher overhead when there are many PWs in same tunnel. The second is probably easier to do architecturally. So proposal is to go to the VCCV style OAM, but add additional things we need: PM such as delay, PDV, packet loss ratio. For TDM PWs it is also useful to monitor backup PWs for fast switch over without timing degradation.
    Shows a VCCV-style performance OAM packet format.
    What should time format be? RTP, NTP, ICMP, IEEE1588 style
    How many timestamps?: 1, for approximate round trip, 2 for approximate one way, 3 - for round trip with delta T, 4 - for ICMP
    Peter Busschbach: VCCV is primarily to carry other OAM protocols over PWs. We need a performance monitoring method generally applicable to MPLS.
    Yaakov: So you want to go back to the original method of monitoring per MPLS tunnel?
    Peter Busschbach: the point is if you want to do delay/packet loss, should apply to MPLS in general. Then you can run them over MPLS layer.
    Yaakov: I am particularly interested in TDM PWs, but may need some PM for MPLS in general.
    Peter Busschbach: expand to general MPLS problem.
    Sasha Vainstein: applicable to non-TDM PWs as well.  Measurement of packet loss have discussed in the PW congestion draft by Eric, which has withered since. He has indicated severe problems for non-TDM PWs. 
    Yaakov: In the PWE3 model, i/w model starts in the PE. But there is the issue of when the PW starts before the PE. 
    George Swallow: It is not clear that the way to measure packet loss for TDM would be the same for other types. I did intend that we should do other things with VCCV. I support this work, and it is appropriate to look at what could be moved into MPLS. The control channel issue was not the be all and end all of VCCV.
    Monique Morrow: needs a little more discussion, including mitigating against the complexities here.
    Yaakov: thinking of the functions, if it is at the PW layer, this is simper than at the MPLS layer.
    Dinesh Mohan: need to think about the role of VCCV. It is a control channel today, and you run other protocols in the payloads. But, we need extensions because there are some new requirements that are coming out. 
    Ping Pan: We have used per PW OAM. Needed to support non-MPLS tunnels. Should apply to non TDM PWs. On the time stamps, probably don't want to get involved in timestamps again. 
    George Swallow: I was misunderstood. There are a few things here that may be generally used. If there are some things that can be put into LSP ping, then we can do that. But, the control word is designed so that we can make extensions for specific applications that do not.
    Stewart Bryant: Take it to the list, partitioning work between general and specialised.
    AII Types for Aggregation  
    Chris Metz (chmetz@cisco.com) 
    Luca Martini presents the changes from 00.
    Shows the AII type I which is in the , and type II which includes an global ID that should be RD i.e. an AS#
    Shows the long prefix version. This has no structure, so could work for IPv6
    Next steps: synced with L2VPN signalling and dynamic MS-PW placement.
    Ping Pan: AII type II is suitable for MS-PW , George has a PNNI i/w type... there are a lot coming along
    Luca: I don't have an objection to documenting more
    Ping Pan: just need to be consistent
    Target Choice of FEC Type  
    George Swallow (swallow@cisco.com) 
    Title of the draft should say PW type, not FEC type.
    Background: 2 years ago brought in a draft that interworked with ATM S-PVC.
    MFA Forum took this up because only a small bits and pieces affect PWE.
    Those pieces brought back here.
    Shows the reference application. Transitioning ATM endpoints to PEs. and also redundancy with no single failure points.
    Sometimes you can tell clearly if the S-PVC if frame relay / ATM, and sometimes you cannot at the boundary.
    If it is FR, would be nice to be able to reassemble at that point.
    Don't know what PW type to put in at the boundary, but want the target to make the decision.
    Ping Pan: Your previous draft expired? We are doing this and the customer asks where the draft is.
    George: This is being progressed at the MFA.
    Ping Pan: why not do this here?
    George: There are lots of details about how you interwork with ATM so not really right place here
    Florin Balus: how do you prevent misconfigurations?
    Andrew Dolganow: it would be a very old signalling message that doesn't tell me 
    Stewart Bryant: ask to the list if this needs to be done and if it should be a WG draft.
    Pseudo Wire Security 
    Yaakov Stein (yaakov_s@rad.com) 
    The time has come to look into this. There are PW specific attacks and certain things that are specific to PWs.
    Shows a list of the threats to PWs.
    Out of scope is anything related to the customer network, the AC, considerations to all MPLS networks, L2TPv3 (done in L2TP extensions) and considerations specific to MS PWs.
    Security weaknesses: PW label is the only identifier, CW sequence number can be used for DoS attack, PWE3 control doesn't mandate authentication, VPLS, auto discovery and MS-PWs all introduce new problems.
    Security strengths: most attacks require compromising a router at some place, adequate protection of the control traffic can help with this, can't insert a packet with proper format outside the SP network. 
    Gives an example of PW man in the middle. Man in the middle looks like an S-PE. Not the same as MPLS-layer man in the middle. 
    Should also look at encryption of PW packet: as the PW does not provide packet integrity, and thus the encryption mechanism must be per-packet and history independent. Cannot encrypt PW label (not legal MPLS), or control word since loose 0000 from first 4 bits. So how is this different from service encryption? No packet reliability (retransmission) at PW layer so PW level encryption should work with packet loss, while service layer may be stream cypher.
    Work on draft has started, but would appreciate co-authors.
    Don O'Connor: Ethernet security in 802.1 suggests we would want to do this on every frame.
    PW Type for ATM Virtual Trunks
    Peter Busschbach (busschbach@lucent.comi)
    A few words on the liaison sent from MFA Forum on ATM-MPLS-ATM control plane interworking. Two approaches: clinet-to-client with a 1:1 mapping from ATM VCs to PWs. Virtual trunks (related to this liaison statement): establish single PW between PEs, and run a single PW for all ATM VCs. Separates ATM and MPLS control plane functionality. Shows the details of how you translate VPI ranges. VPI ranges are locally significant, so MEs translate VPI ranges. 
    None of the existing PW types apply, because N:1 mode explicitly does not change the VPI values. Asks for a new PW type for VTs.
    Luca Martini: where is the liaison statement? I would have put the code point in if I had seen it.
    Andy Malis: I did upload it!
    Stewart Bryant: should wait for the registry to be set up
    Meeting closes.


    Status of WG drafts
    An Architecture for Multi-Segment PWE3
    Dynamic Multi-Segment Pseudo Wire Signaling Procedures Using LDP
    Setup and Maintenance of Pseudowires using RSVP-TE
    Link Aggregation Member Interface Status Signal
    Operation and Maintenance for Multi-segment Pseudo Wire
    VCCV Extensions
    AII Types for Aggregation
    Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks
    Target Choice of FEC Type
    Pseudowire Security
    PW Type for ATM Virtual Trunks