2.3.22 Pseudo Wire Emulation Edge to Edge (pwe3)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-15


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>

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 04  Fragmentation LC
Jan 04  TDM Requirements LC
Feb 04  SONET Documents Last Call
Mar 04  TDM Documents Last Call
Mar 04  PWE3 WG Charter Review, Additional Work or Ends
Apr 04  Frame Relay Documents Last Call
Apr 04  PWE3 MIBs Last Call
Apr 04  SONET Documents Last Call
Apr 04  FCS retention Last Call
May 04  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-08.txt
  • draft-ietf-pwe3-frame-relay-05.txt
  • draft-ietf-pwe3-atm-encap-09.txt
  • draft-ietf-pwe3-tdm-requirements-08.txt
  • draft-ietf-pwe3-iana-allocation-11.txt
  • draft-ietf-pwe3-hdlc-ppp-encap-mpls-05.txt
  • draft-ietf-pwe3-vccv-05.txt
  • draft-ietf-pwe3-satop-02.txt
  • draft-ietf-pwe3-fcs-retention-03.txt
  • draft-ietf-pwe3-cesopsn-03.txt
  • draft-ietf-pwe3-tdmoip-03.txt
  • draft-ietf-pwe3-satop-mib-03.txt
  • draft-ietf-pwe3-tdm-mib-03.txt
  • draft-ietf-pwe3-cell-transport-03.txt
  • draft-ietf-pwe3-oam-msg-map-02.txt
  • draft-ietf-pwe3-cw-05.txt
  • draft-ietf-pwe3-ms-pw-requirements-00.txt
  • draft-ietf-pwe3-segmented-pw-00.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

    Current Meeting Report

    PWE3 IETF63, Tuesday August 2 & Wednesday August 3rd 2005.

    CHAIRS: Stewart Bryant (stbryant@cisco.com) & Danny McPherson

    MINUTES: Matthew Bocci (with additional notes from Mustapha Aissaoui &
    Yaakov Stein)
    SLIDES: Available at http://pwe3.tcb.net

    TUESDAY, August 2 1030-1230

    Agenda: Danny McPherson
    Agenda bashing fine.

    Status of WG drafts: Danny McPherson
    Slides on these have been posted on the web site, so won't go through at this stage.
    Things are progressing nicely under the new AD (Mark Townsley).

    Brief Charter Update Status
    Comment period on the updated charter is to be extended 2 weeks.
    Issues: Remove SVCs, scope PW types, ECMP text, FCS retention needs to be completed.


    Requirements for inter-domain Pseudo-Wires & Segmented Pseudo Wire
    Luca Martini (lmartini@cisco.com)
    Segmented Pseudo Wire
    Luca Martini (lmartini@cisco.com)

    This presentation covered both the segmented PW draft, and the multi-segment PW requirements.

    The Segmented PW draft was formerly called PW switching. Currently we have LDP, L2TPv3, static Do we need to add IP UDP? PWs are definied with IP UDP headers, do we need to add support for these?
    Usage examples: Should these remain here or be moved into the ms-pw requirement document?

    On the other drafts, work is pretty much done. CW draft had a few nits.
    IANA draft need to resolve hold ups on the list.

    On the requirements draft, we ran out of time to do a new version. We plan to reorganise the draft in ascending order of complexity.
    Yakov & Luca have some slides on how we should reorganise them in this way.
    A fair number of people have read the document.

    Comparing and contrasting the LDP and RSVP approaches
    Yakov Rekhter (yakov@juniper.net) and Luca Martini (lmartini@cisco.com)

    The presentation introduced as requirements and protocol selection.
    Requirements should be reorganised by technology area.
    Some requirements are optional.
    We need to reorganise into mandatory and optional.
    Luca showed the table of contents. Asks for help in what is mandatory and what is optional.
    Also, need a clear underatnding of what needs to be changed in LDP and RSVP to support MS-PWs.
    Ask authors to document, in a new section of the solutions drafts, what changes are needed as far as extensions.
    e.g. LDP needs QoS info, RSVP needs PW status

    Yakov Rekhter : need to explain exactly how new features could be implemented. Not just a bullet list.

    Sasha Vainstein: To the authors of the drafts, how much work is needed to reshuffle the drafts?

    Luca Martini: For requirements, its a couple of days of work.

    Himanshu Shah: RSVP mentions a lot of other drafts. We also need to include that in how they are used, for the sake of clarification.

    Yakov Rekhter : Yes, you need to say what part of the other RFCs you actually need to implement.

    Ali Sajassi: wrt protocol extensions, not just enough to list bullets.
    How can you objectively quantify cost associated with these?

    Yakov Rekhter: we are all human, so it is difficult. But this will help us to make an informed decision.

    Mark Townsley: Is this supposed to be a comparison between RSVP-TE etc for MS-only?

    Yakov Rekhter: MS only

    Mark Townsley; so would like to see how to migrate from the deprecation of LDP, or the coexistence of LDP for SS and RSVP for MS Would like to see transition covered.

    Yakov Rekhter: OK

    Kireeti Kompella: not sure why we are talking about deprecxating. We have 2 protocols for tunnels.

    Mark Townsley: This is an IF. If we are proposing RSVP for MS, we have to know a-priori which protocol to use. Does this violate requirements?
    If not, need to go with stitched RSVP, or stitched LDP, and go with one.
    This is a fundamental issue. Otherwise you end up with SS as a subset of MS functionality. WOuld like to get past that first.
    Don't want to have two of these things.

    Luca Martini: one of teh requirements was to try to extend single segment protocol to do multi-segment. Could be RSVP SS or LDP SS that is extended.

    Dimitri Papadimitriou: WHat was meant by it is not clear a-priori is it is SS or MS?

    Mark Townsley: I mean you have a PE setting up a PW to another PE. It doesn't know if you are going to be switched to an AC and so be SS, or a PW and so be MS. If he knows that, he knows which protocol to use. If they are truely separate, then can look at them separately.

    Rahul A: requirements docuemtn needs to have more details on coexistence of SS and MS, and what a-priori knowledge is needed.
    Also, need to break requirements into mandatory and optional. May have more than one protocol with different applicabilities.

    Mark Townsley: agree this is a requirements issue. Is this just looking at MS case? Is this realistic?

    Danny McPherson: there is a requirement that U-PE doesn't know.

    Kireeti Kompella: It is important that whoever starts the PW, they know where they are ending it.

    Dimitri Papadimitriou: are we going to use the architecture document for this?

    Luca Martini: the architecture puts a framework on this.

    Scott Brim: knowing what the endpoint is does not tell you how many segments you are going through.

    An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge
    Matthew Bocci (matthew.bocci@alcatel.co.uk)

    The objectives are to define the main network scenarios, what protocol functions are required.
    Key issues: applicability of MS-PW versus L2VPN: A single PW which is segmented into a number of segments. PWE3 will mainly work on S-Pe selection to reach a DU-PE.
    Protocol Layering: PWs may be considered a separate from PSN tunnel layer. But they could reuse the PSN protocols.
    PE reference model: processing in U-PE as in RFC 3985. No native service processing in the S-PE. 1:1 mapping between ingress and egress PW.
    Would like to achieve.

    Mustapha Aissaoui: Commented on protocol layering. One can use PSN information, e.g., reachability, for the PWs.

    Matthew Bocci: Yes, but you use it in a different way.
    Dimitri Papdimitriou: Do we need to explicitly state that Ms-PW is a separate layer? What do we gain or lose?

    Matthew Bocci: The point is to explicitly call out that we treat PWs differently from the PSN. However, it is not a major point and we do not want it to mean things that were not intended.

    Ron Cohen: Can you give example for policy that may be required?

    Matthew Bocci: You can apply policy on how to select the S-PE, or to use security at an inter-provider S-PE.

    Yaakov Stein: Would like to keep referring to a separate layer because of all the comments in the mailing list. this is an issue that we have avoided for a long time, but MS-PWs mean we really have to settle this issue.

    Setup and Maintenance of PW Using RSVP-TE
    Rahul Aggarwal (rahul@juniper.net)

    Gives a brief review of Why RSVP-TE should be used: This is interdomain TE PWs when tunnels are RSVP-TE LSPs.
    The functional blocks can be addressed with RSVP-TE mechanisms. This solves a large subset of these problems.
    We want to instantiate a multi-segment PW as an RSVP-TE LSP change since last versions: Can treat a PW as two unidirectional LSPs and/or one bidirectional.
    PW LSP is a nested LSP.
    This follows CCAMP work for nesting, protection, and PCE work for routing.

    Want to look at how this meets the requirements:
    - Scalability requirements: This avoids a full mesh of PSN tunnels.
    - Routing requirements: use RSVP-TE explicit routing e.g. RFC 3209,
    Inter-domain support using RSVP-TE inter-domain routing rerouting also using RSVP-TE mechanisms.

    - Interdomain signalling also already supported using CCAMP drafts
    - Path computation
    - Resiliency: RSVP TE allows primary and backup PWs to be associated with each other and share resources common segments
    Ability to traverse different S-PEs i.e. avoid fate sharing
    Mechanisms to perform fast switchover.
    Important case is S-PE protection: this is based on the fast reroute draft.
    PW segment protection is based on RSVP-TE mechanisms.
    QoS and CAC:
    - using QoS signalling - RFC 3209
    Can support diverse QoS models
    OAM requirements:
    - Use mechanisms already specified for LSP-ping, BFD for MPLS and VCCV
    - VCCV capability negotiation remains to be specified
    - Segment PW OAM requiremes extensions that remain to be specified.
    MS-PW and RSVP-TE: MPLS PW encapsulations
    Explains the relationship between MS PW and SS PW signalling protocols
    SS continues to be LDP or L2TPv3
    Can we use RSVP-TE for MS end to end, and on each segment use LDP?
    Extensions needed:
    - PW identification. This is carred in a new sernder_tspec object
    - Control word negotiation

    Service providers see no reason to not deploy a different technology for MS-PW
    It may turn out that there are different applicabilities and shouldn't close our minds to this.

    Mustapha Aissaoui: My previous comments on bidirectional PW was that it is always bidirectional, but existing RSVP-TE specs only talk about symmetric. The issue is that you need to specify two directions independently. Also need to specify PW interface parameters, and PW status.

    Rahul Aggarwal: if you use single directional, you can do asymetric

    Luca Martini: if you use FRR, you can envisage convergence happening symultaneously at the PW level, and also the PSN level. This is difficult to manage.

    Rahul Aggarwal: should clrify in the requirements document. Also should ask CCAMP why they want FRR to inter-AS LSPs, which have same issue

    Sasha Vainstein: SCalability issues are exactly the same for both methods, RSVP and LDP.

    Rahul Aggarwal: if you compare the two types of sessions, the differences are minimal. That was not the point that I was trying to make.

    Dimitri Papadimitriou: willing to accept that operators use tunnel resiliency. What are the SP requirements for S-PE resiliency?

    Danny McPherson: We understand that people are representing operators here.

    Multi-Segment Pseudowire Setup and Maintenance using LDP
    Florin Balus (balus@nortel.com)

    Presents the case for using using LDP.
    Existing deployments: SS-PW, VPLS implementations, deployments based on LDP signalling
    - reuse signalling procedures
    Operational consistency:
    - same management, provisioning models
    - OSS touches only at the U-PEs
    We want minimal changes.
    Presents th MS-PW requirements that are addressed.
    Diagram showing how operational consistency is maintained.
    Presents how the PW information model applies to this.
    Differences with SS-PW.
    We are keeping the same information model elements. U-PE prefixes are carried in the signaling messages.
    Shows how to carry the SU-PE dU-PE prefixes in the signalling.
    These are orthogonal to the procedures in the draft.
    Can use the MS-PW TLV, or can use the SAII/TAII in the generalised ID FEC. This keeps the layer 2 address in one spot
    Need to know if we should mandate use of generalised ID FEC.
    Uses the prefix for the U-PE to find the next signalling hop.
    Slide explains how this works in the forward and reverse direction.

    Kireeti Kompella: how do you find S-PE1 and S-PE2 etc?

    Florin Balus:In another slide.
    Related procedures include determining the next hop, QoS TLVs using TSPEC, CAC executed against tunel), resiliency (rerouting around failure)

    Kireeti Kompella: are you saying that the S-PE hops is independent of where you start?

    Florin Balus: No. Could use IGP, or BGP etc
    Next steps: need to know if we still need support for FEC 128? Do we need primary and backup PW?

    Lou Berger: You are defining a couple of new TLVs for the endpoint identification and QoS

    Florin Balus: not if you use the generalised ID FEC

    Lou Berger: in the past we have had standardised FECs to do thiese things

    Florin Balus: the scope is different

    Lou Berger: so why not just settle on generic TLVs that could be used by other applications.
    This has already been through a standardisation process in the IETF.

    Florin Balus: would be better to have a generalised

    Sasha Vainstein: Pretty sure that we should not preclude FEC 128
    Also: Assumption is that you know which U-PEs originate the signalling. This distinction is not made. You can use the proposal from draft-shah-bocci

    Dimitri Pimitriou: Where does the NSAP address requiremnent come from?

    Florin Balus: could support other types of addresses

    Mustapha Aissaoui: Still missing an explanation of what happens when a label mapping is released by an intermediate node.

    Florin Balus: this is described in the resiliency procedures

    Mustapha Aissaoui: This is about how to deal with blocking on setup.

    Florin Balus: We can move this into main signalling procedures

    Ali Sajassi: how does this apply to the different layers in the VPLS?

    Florin Balus: can use ASBR that doesn't use bridging

    Ali Sajassi: so you are talking about extending one of the segments?

    Multi-Segment Pseudo Wire Signaling
    Himanshu Shah (hshah@ciena.com)

    Presentation made by Matthew Bocci (matthew.bocci@alcatel.com)

    Why extend PW Control?:
    - Reuse existing SS-PW LDP-DU protocol.
    - Lightweight protocol to minimize complexity, particularly at S-PE.
    - PWs and PSN tunnels are different: PW is not a regular LSP.
    Guiding assumptions: U-PEs do not have full reachability info for S-PE/U-PE.
    Need to make a informed path selection by the upstream U-PE after the path was received by the D-UPE.
    Overview of the solution: defined a new MS-PW TLV and maintained the PW-Id FEC as a single hop parameters for backward compatibility with SS-PW. Use of controlled path discovery to discover a subset of all possible paths and D-UPE makes the path selection and may select a backup path.
    List of Requirement path met.
    Changes to PW control: added a new MS-PW TLV. Added the concept of
    Active and Passive PE. Added controlled path discovery.
    Walkthrough the path setup and selection.

    Jeff Sugimoto: It seems that path selection at S-PE is based on timing of the arrival of the first incoming label mapping message. This does not provide an optimal path selection.

    Matthew Bocci: the issue is that you cannot set up an optimal path withouth the U-PE having the full reachability information.

    Rahul Aggarwal: CCAMP and PCE have spent a lot of time developing mechanisms, have you considered?

    Matthew Bocci: could reuse mechanisms, could coordinate

    Dimitri Papadimitriou: how is explicit routing related (it is in doc)

    Matthew Bocci: Explicit routing could be used in simple cases

    Kireeti Kompella: Both of the LDP drafts are merely ways of not adding ERO TLVs to LDP. The path discovery described here is not appealing: it can become uncontrolled very quickly. Any LDP based mechanism will end up reinventing many of the CCAMP mechanisms.

    Matthew Bocci: this is a way of getting around the problem of partial information (only known after label distribution arrives)

    Kireeti Kompella: 3 ways to know which path to select: 1) flooding 2)crankback 3) oracle.

    Mustapha Aissaoui: do we need best E2E path, or is a compromise good enough.

    Bruce Davie: Agrees with Kireeti that shouldn't invent new mechanisms for path discovery.

    Adrian Farrel: If PCE does not address the requirements of PWE3 this could be because PWE3 has not brought its requirements to PCE.

    General Discussion of the MS-PW Signalling Drafts
    Sasha Vainstein: can the LDP authors merge the two drafts?

    Yaakov Stein: this clearly states the need to separate the optional versus the manadatory requirements.

    Himanshu Shah: does RSVP allow other PSN technologies?

    Lou Berger: How to resolve RSVP vs LDP? There have also been some mention of the term CR-LDP. I there seems to be sufficient momentum, let them move forward and let the market decide. This enables technology to move forward, and then decide. We should also not go down an application-specific path.

    Luca Martini: We have discussed this on the list. There is consensus on the list that there is not sufficient support for RSVP-TE

    Lou Berger: Should go forward based on a subset of CR-LDP then. Must not put application specific state in the network.

    Luca Martini: There is a reason why state is in particular points of the network.

    Mark Townsley: Market chooses when the WG fails to choose. We are not there yet.

    Lou Berger: If there is sufficient interest in the vendor and provider community.

    Luca Martini: RSVP doesn't work well for inter-provider, which is why we have a PCE working group.

    Jean-Louis Le Roux: we should not make a choce between the two. Sometimes we need explicit routing, sometimes we don't. So we should continue to work on both protocols

    Rahul Aggarwal: Doesn't agree with Luca's read on the list.

    Yakov Rekhter: There is a design principle that is applicable to all protocols that we should have as few mechanisms as possible and simple as possible. Who is going to decide? In the past it was IESG, but market is the best place for this.

    Dimitri Papadimitriou: what is the relevance of PCE?

    Mark Townsley: W.r.t. to what FT was saying. If we end up with MS being a separate thing to SS, then there is a choice. If we can walk into this with open eyes, we can save having to deprecate later on.

    George Swallow: if we have both, most likely we will be dealing with interoperability.

    Sense of the room: Support for both RSVP-TE and LDP in the room.

    WEDNESDAY, August 3 0900-1000

    Starts at 9am
    Danny summarises yesterday. We didn't accomplish as much as we hoped, but people got their points across.

    MPLS Liaison Statement
    Liaison Email
    George Swallow (swallow@cisco.com)

    Brought a draft a while back, but was out of charter because it was more
    ATM than MPLS. This is now being progressed at the MPLS/FR/ATM Forum (MFA Forum). This is for SPVC interworking between ATM and MPLS. Sometimes you want to do reassembly at the boundary, but don't have a-priori knowledge of what the payload is (ATM or FR).
    Suggestion was that there should be a general wild card PW type. If people are interested then they will bring a draft.

    AII Types for Aggregation
    Chris Metz (chmetz@cisco.com)

    The scenario is a provisioning model is "selective inter-domain VPWS". Provider triggers a circuit (PW) with signalling based on customer demand. PWE3 signalling must carry full qualified target attachment identifier.
    Lists a couple of issues: can stress this depending on the AII machinery.
    - Scalability: distributing O will stress address distributrion machinery
    - Security
    - Proposal is for a new AII type that enables the summarisation of AIIs into a single or few AII aggregates.
    - Option for globally unique
    - AII numbering flexibility, e.g.: v4, v6, NSAPs...
    Uses PWE3 FEC 129

    Presents the short prefix AII type
    MS-PW is a signalling and routing problem
    - when explicit paths are

    Yakov Rekhter: is this practical requirement?

    Chris Metz: you don't have to export individual addresses; people summarise reachable addresses today. Will also impact OAM tools because they are routable and reachable.

    Chris Metz: these were just addresses. Just an example.

    Scott Brim: just an example of what

    Luca Martini: the OAM tools should work fine because they are a PW. This address will be the end. The PW tools will need to work with this using some other address field, but need to do intermediate hops also. Not sure people allocating IPv6 addresses will want to allocate them for layer 2 PWs.

    Chris Metz: don't mandate what adrress type you use in the prefix.

    Danny McPherson: do you want to take forward here?

    Chris Metz: Yes

    Danny McPherson: take to mailing list

    Luca Martini: need a document that specifies how to use an AII

    Bruce Davie: L2VPN signalling draft was first to show how to use AII format. This can be made compatible with Chris' proposal.

    Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks
    Moran Roth (moranr@corrigent.com)

    Proposes an encapsulation for fibre channel over MPLS.
    Used to extend SAN applications for e.g. disaster recovery/business continuity Operational simplicity and transpareny is important.
    Presents reference model: connect N_Port, F_Port, E_Port.
    PE reference model has PSN tunnel, PW termination carrying FC framing; NSP converges FC! into PW encapsultion
    The NSP is being worked on in T.11
    Encapsulation guidelines:
    - FC data frame carried transparently in one PW PDU
    - NSP control frame is carried transparently in one PW PDU
    Local spoofing at PE
    Other FC signals include primitive sequences. These are carried transparently, but may be supressed to save BW. Primitive signals are terminated at the PE.
    Shows encapsulation over MPLS/PW.
    PWE3 requirements: need a new PW type: FC port mode

    George Swallow: need ordered frame delivery, so would urge tomake CW mandatory.

    Luca Martini: FC is 10 years old, but very timing sensitive. You have a control channel, ?

    Ronen Solomon: Same PW as FC frames, but control packets multiplexed into PW. FCBB control frames are generated by the NSP e.g. echo frames.

    Luca Martini: We probably want to mention that there is congestion control mechanism

    Ronen Solomon: there is control mechanism to prevent buffer overflow

    Luca Martini: You also need to clearly mention what status messages are relevant.

    ?: what does this give you that ? doesn't give you.

    Ronen Solomon: IP over PW; you have transparency to FC here. Also, we found that overhead should be minimal in order not to increase delay Seems natural if you compare it to PPP or HDLC.

    ?: Is there a proposal for SCSI over PWE3?

    Ronen Solomon: we are looking at it; but not a real requirement. Also it is parallel.

    Stewart Bryant: Others have shown interest.

    Peter Busschbach: Two modes for GFP: can you do same for FC?

    Ronen Solomon: The Current suggested model is Frame based FC over MPLS.

    Peter Busschbach: What about a circuit emulation approach?

    Ronen Solomon: We have been considering GFP-T over CEM, however this approach does not allow service offering for CIR/EIR service model as CEM offers CIR Guaranteed only approach , where FC over MPLS offers CIR/EIR approach.

    Mark Townsley: reliability is an issue. We are squarely in the area of transport (not IETF transport). This must be reviewed by transport people. Congestion mechanisms must cooperate . Chairs must do some liaison work before accepting as a working item.

    Danny McPherson: we did add this to the new charter.

    PWE3 Applications & OAM Scenarios
    Vasile Radoaca (radoaca@hotmail.com)
    Ali Sajassi (sajassi@cisco.com)

    Ali lists a numver of Service providers.
    The draft leverages work in ITU/IEEE regarding OAM layering and domain definition. Purpose is to make PWE3 OAM consistent with the others.
    Defines access domains in place of attachment circuits. 3 models:
    - service, network, ?
    Draft describes what scenario fits into these different models.
    Shows a set of models. Acronyms : MEP and MIP are used in ITU and are defined in the draft. Based on L2VPN OAM framework.
    This draft expands the applicability to PWE3. Model 3 is what has been defined in L2VPN OAM framework.
    Model 1: cannot insert OAM into service layer.
    Model 2: no hierarchy
    Model 3: hierarchical model
    This was presented back in Minneapolis with good reception. Would like to progress this as a working group draft.

    Mustapha Aissaoui: I am trying to recall the discussion last time. I think that the conclusion was that this document was going to focus on the PWE3 part., particularly the MS-PW issue. There still seems to be confusion between requirements and framework. WOuld like to reduce the scope to PWs and use it for our MS-PW work.

    Ali Sajassi: I agree. WOuld like to clean up and make applicable to PWE3.

    Dinesh Mohan: also agree with this. Given that it is being proposed as a WG draft, we can continue doing this work.

    Stewart asks for sense of the room. Seems mildly in favour. Will continue on the list.

    Requirements for Pseudo Wires carrying Timing and Synchronization
    Tim Frost (tim.frost@zarlink.com)

    The purpose is to define requirements on conveying timing and sych over PWs. Need this because there are requirements for converying sych information beyond those dealt with in TDM drafts e.g. wall clock.
    Could look at e.g. ntp, but they are not in this space
    Apps: Industrial, synch of PBXs, timing for cellular base stations.
    Shows a possible timing PW scenario.
    Main requirements include: performance (details not specified here, but generally ppb), rhobustness (need multiple timing servers), security and authentication. Compares with draft-ietf-ntp-reqs-00. Claims that there are a number of differences.
    Need to look at whether we can use NTP to also convey phase and frequency. Do we need a separate protocol to PWs?
    Shows a proposed packet structure using NTP.
    Next steps: we are still in the process of collecting applications. Asks for info on the requirements of other apllications.
    Need to decide if this work shuld be in NTP, and if draft has a life of its own.

    Stewart Bryant: The primary thing to do is collect requirements, and then decide.

    Yaakov Stein: In a PW solution, it looks like there a 3 ways: send NTP, send TDM, or do some special protocol for distributing timing. These do not match model. If you use NTP, this goes over IP now, and if you use TDM you can do that today. So, doesn't look like there is new work to do. But, good to gather requirements.

    Tim Frost: TDM PW could do this, but it is not absolute time.

    Stewart Bryant: take to list

    Control Protocol Extensions for Setup of TDM Pseudowires
    Sasha Vainshtein (Sasha@AXERRA.com)

    Presents rationale for this. Cannot exist if endpoints have not agreed on a few parameters.
    So should allow set up of PWs that will operate properly, but prevent those that won't.
    Next steps: need feedback from WG. Assess the effect of some parameters on success/failure of the PW setup has to be clarified. e.g., TDMoIP AAL2 options. Format of cause codes: do we need a minimum for them or shall we have detailed ones? The level of detail pertaining to the reason for PW setup rejection: needs some consistency

    Stewart Bryant: should it be a minimum or maximum level of detail? Take to the list.

    Luca Martini: there are a lot of editorial nits on the draft e.g. terminology; need to make clear by name what registries you are using.

    SONET/SDH Circuit Emulation over Packet (CEP)
    Ron Cohen (ronc@resolutenetworks.com)

    Quick reminder of what this means. Ring which is emulated using MPLS network. Emulate high and low order virtual containers by sending across a tunnel.
    Draft has been stable for a long time, but control word has evolved in that time. Now aligned to PWE3 control word, and also aligned to other TDM dratfs.The draft itself still maintains fractional VC4. Only change is that no indication if these is an extension or not.
    Shows configuration where you now have mix of CESoPSN, SATOP, and CEP over same network with same CWs etc.
    This draft has already passed to last call, but the authors would appreciate further comments.

    Managed Objects for TDM over Packet Switched Network (PSN)
    Orly Nicklass (orly_n@rad.com)

    Shows the conceptual layering. Changes since last draft are presented: merging some of the objects.

    PW Protection
    Ping Pan (pingpan@cs.columbia.edu)

    Presents a protection scheme for PWs.
    Need per-PW protection.
    Needs protocol extension for this.
    Next steps: gather feedback. Would like to go for WG doc soon.
    Mustapha: 2 issues: adding setup/pre-emption priority. AL issue is that you need to synchronise two sides on

    Taken to the list.

    Meeting closes.


    Status of WG drafts
    Requirements for inter domain Pseudo-Wires
    Comparing and contrasting the LDP and RSVP approaches
    An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge
    Setup and Maintenance of PW Using RSVP-TE
    Multi-Segment Pseudowire Setup and Maintenance using LDP
    Multi-Segment Pseudo Wire Signaling
    AII Types for Aggregation
    Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks
    PWE3 Applications & OAM Scenarios
    Requirements for Pseudo Wires carrying Timing and Synchronization
    Control Protocol Extensions for Setup of TDM Pseudowires
    SONET/SDH Circuit Emulation over Packet (CEP)
    Managed Objects for TDM over Packet Switched Network (PSN)
    PW Protection