2.8.12 Pseudo Wire Emulation Edge to Edge (pwe3)

Last Modified: 2003-08-18

Chair(s):
Stewart Bryant <stbryant@cisco.com>
Danny McPherson <danny@tcb.net>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
Technical Advisor(s):
Mark Townsley <mark@townsley.net>
Mailing Lists:
General Discussion: pwe3@ietf.org
To Subscribe: pwe3-request@ietf.org
In Body: subscribe your_email_address
Archive: http://www.ietf.org/mail-archive/working-groups/pwe3/
Description of Working Group:
Service providers (SP) are seeking to offer multiple services across
a common packet switched network (PSN), such that the result is
emulations of e.g. Frame Relay or ATM circuits, or SONET/SDH.
Multiple services on common infrastructure can be offered using
pairwise conversions, so for instance, if the native link is
ATM, FR could be offered over it by having modules that convert
FR to ATM going in and ATM into FR coming out.

An alternative approach is to provide multiple services, each
as an emulation in a tunnel over an IP packet switched network.
There are many proprietary service-specific implementations in
in the market now that use this approach.  The PSN can transport PDUs
for multiple services, and the conversion/interworking functions per
service pair are not needed.  We term the tunnels used in this approach
"pseudo wires" (with no implication that what is emulated is copper
or otherwise is restricted to real world wires, but rather with
the commonly used metaphorical sense of wire, as when a mobile
device designer speaks of the "on the wire" packet formats!)

The basic idea of this working group is to develop standards for
the encapsulation and service emulation of pseudo wires: encapsulating
service-specific PDUs arriving at an ingress logical port and carrying
them across a tunnel, managing their timing, order or other aspects
entering and leaving the tunnel, to emulate the behavior and
characteristics of the service as well as possible.  Applicability
statements for each service will describe expected shortfalls of
the emulation's faithfulness.

From the customer perspective, the pseudo wire is perceived as an
unshared link or circuit (or the appropriate unit) of the chosen
service (although it will not be a perfect emulation of the service).

Pseudo wires require the edge devices providing service interfaces
to use common service-specific techniques for encapsulating PDUs and
maintaining the service characteristics and behavior in the data flow.

The purpose of the WG is to pursue standardization of the framework and
the service-specific techniques for pseudo wires.

Assumptions

  PWE3 protocols and implementation focus on the edge-to-edge
  emulation and maintenance of service-specific pseudo-wires.
  Creation and placement of the tunnels is outside of the scope.

  Tunnels for PWE3 encapsulations will use IP (both versions), L2TP,
  or MPLS.  PWE3 will coordinate closely with the L2TP WG and its
  technologies.  PWE3 pseudo wires will have the same specification
  for all underlying PSNs (i.e. there will not be specific adaptation
  of a pseudo wire technology for MPLS that is distinct from what is
  used for IP and L2TP, or differences will be the minimum necessary
  and will be called out clearly).

  PWE3 will not exert controls on the underlying PSN, but only
  function at the endpoints of the pseudo wire, though the endpoints
  may be configured to set diffserv codepoints in the tunneling
  datagrams.

  PWE3 will use RTP where necessary to perform clock recovery and
  other real-time signaling functions.  This work will be
  coordinated with the AVT WG and payloads will follow RFC 2736.

  PWE3 will not strive for pseudo wires to perfectly emulate the
  characteristics of the native service.  For each type of pseudo
  wire, an applicability statement will describe the degree of
  similarity of a pseudo wire to the native service it emulates.


WG Objectives (in order of priority):

  Develop a requirements document to define the specific services and
  technology to be defined by the working group.

  Specify methods with RTP (and possibly using header compression
  where needed) to ensure in-order final PDU delivery, perform clock
  recovery inband emulation and maintenance functions across the PSN,
  where required.

  Research the statistics and other network management information
  needed for tunnel operation and management, for example, to be able
  to determine when a circuit's up/down state has changed.  Coordinate
  closely with the CCAMP WG on this.

  Specify the security mechanisms to be used to protect the control of
  the PWE3 technology.  These are likely to be security mechanisms
that
  are part of the tunnel creation technology and not be developed by
  PWE3, but cited by PWE3 specifications.  Requirements may be
  ommunicated to the PPVPN, L2TPEXT and CCAMP WGs.  The protection of
  the encapsulated content of the pseudo wire is outside of scope.

  The WG will determine the requirements for having a pseudo wire pass
  across an administrative boundary.  An edge could be a native
  hand-off or hand-off to a further pseudo-wire.  The WG may
  analyze requirements for both security and performance for the
  inter-administration technology.

Deliverables

  General documents:

    Requirements Document

    Framework Document

    Common Edge-to-Edge Emulation/Maintenance Protocol

    Requirements for PW Traceroute (if distinct from tunnel-specific or
    CCAMP traceroute).

Individual encapsulation and emulation/maintenance document(s) for each
of the following transported protocols, as well as applicability
statements for each:

    Ethernet (DIX Ethernet (100M, 1G, 10G), IEEE 802.3, 802.1q (VLAN)

    Frame Relay

    ATM

    TDM (e.g. DS1, DS3, SONET)

    MPLS (over IP or L2TP only)

Out of Scope

  Any multicast service not native to the emulated medium.
  Thus, Ethernet transmission to a "multicast" IEEE-48 address is in
  scope, while multicast services like MARS that are implemented on top
  of the medium are out of scope.

  Methods to signal underlying network.

Other Working Groups We Will Coordinate With

  L2TPEXT, DIFFSERV, AVT, CCAMP, PPVPN, MPLS, TEWG, ROHC
Goals and Milestones:
Done  PWE3 WG started, organize editing teams.
Done  Hold interim meeting, including discussion of priority of service-specific documents and consider pruning some deliverables
Done  Accept drafts of service-specific documents as WG items
Done  Requirements Document Last Call
Oct 03  TDM Circuit Documents Last Call
Oct 03  ATM Documents Last Call
Oct 03  Ethernet Documents Last Call
Oct 03  Frame Relay Documents Last Call
Dec 03  PWE3 MIBs Last Call
Dec 03  SONET Documents Last Call
Mar 04  PWE3 WG Charter Review, Additional Work or Ends
Mar 04  TDM Documents Last Call
Internet-Drafts:
  • - draft-ietf-pwe3-requirements-06.txt
  • - draft-ietf-pwe3-pw-mib-01.txt
  • - draft-ietf-pwe3-pw-mpls-mib-01.txt
  • - draft-ietf-pwe3-pw-tc-mib-01.txt
  • - draft-ietf-pwe3-sonet-02.txt
  • - draft-ietf-pwe3-ethernet-encap-03.txt
  • - draft-ietf-pwe3-control-protocol-03.txt
  • - draft-ietf-pwe3-cep-mib-01.txt
  • - draft-ietf-pwe3-enet-mib-01.txt
  • - draft-ietf-pwe3-arch-05.txt
  • - draft-ietf-pwe3-fragmentation-02.txt
  • - draft-ietf-pwe3-frame-relay-01.txt
  • - draft-ietf-pwe3-atm-encap-02.txt
  • - draft-ietf-pwe3-tdm-requirements-01.txt
  • - draft-ietf-pwe3-iana-allocation-01.txt
  • - draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt
  • - draft-ietf-pwe3-vccv-00.txt
  • No Request For Comments

    Current Meeting Report

    PWE3 WG Meeting IETF-57, Wed 16th July 2003
    
    ===========================================
    
    
    Chairs: Stewart Bryant and Danny McPherson
    Minutes take by: Matthew Bocci
    
    
    "Danny McPherson" <danny@tcb.net>
    WG Document Status
    ------------------
    
    
    There has been good progress on Requirements and Architecture drafts. 
    Intend to send both to IESG next week. After this, most services stuff can 
    proceed. The intention is to wrap up a lot of the stuff in 3 or 4 
    months.
    
    
    There are some issues with Frame Relay which will hold it up a bit. 
    Authors should clean up docs to deal with ID nits before progressing them.
    
    
    
    "Thomas Narten" <narten@us.ibm.com>
    PWE3 move to Internet Area
    --------------------------
    
    
    Thomas is Internet Area co-AD. There is a plan to transition PWE3 to the 
    Internet Area. PPVPN has been split into L2 and L3 VPN. We should bring 
    PWE3 into the same area (L2TPv3 extensions is here too). Reason: It is 
    arguable which area, but this is all related to tunneling. Transport 
    originally took it because of congestion control issues.
    
    
    Transition will occur when architecture and requirements are done.
    
    
    
    "Thomas Nadeau" tnadeau@cisco.com
    
    http://www.ietf.org/internet-drafts/draf
    t-nadeau-pwe3-vccv-01.txt
    
    ----------------------------------------
    -------------------------
    
    
    Rahul Aggarwal Juniper Juniper, presented VCCV update.
    
    
    This stands for Virtual Circuit Connection Verification.
    
    
    Capabilities: Inband MPLS VCCV, Router alert label.
    Changes in v1:
    Inband MPLS VCCV: Message indicated in data flow by using first nibble of
    PW control header: 0001
    LS 16 bits specify protocol no.
    Router alert used to indicate an OAM flow
    Changes for L2TPv3: VCCV verifies session forwarding state at egress PE.
    Encodes LSP ping header.
    Message types are listed.
    2 Reply modes:
    Contains L2 circuit ID
    OAM capability must be signaled before a PE may send OAM messages.
    The presenter lists the cases for MPLS, L2TPv3 as PSN. VCCV control 
    channel indicated by receiving PE.
    Should L2 circuit ID be in LSP PING spec, OAM capability 
    advertisement: where should this be defined?
    
    
    The presenter request that this be made a WG document
    
    
    Sasha Vainshtein: What should happen with PWs that by default do not use CW?
    Rahul Aggarwal: still possible to use router alert label. If you want
    
    
    Luca Martini: supports this, but more belongs here. Might belong 
    somewhere else.
    Rahul Aggarwal: why? Several issues related to PWs. Capability 
    advertisement, open to what WG wants.
    Luca: Could limit it in this draft
    George Swallow: If you think your objects belong in MPLS, send them over 
    MPLS
    Mustapha Aissaoui (Alcatel): What about MPLS payload ID?
    George Swallow: We define IP control channel associated with PWE3 
    circuit. and put IP in code point.
    Mustapha Aissaoui: OK, but we are using MPLS PID in Arch document, not CW. 
    Must get terminology right. It is PW PID, not control word.
    Rahul Aggarwal: OK, get the same picture.
    
    
    Rough consensus was tested and there was majority support to accept the 
    document as a WG draft. This support to be further tested by asking the 
    list.
    
    
    
     "Mustapha Aissaoui" 
    <mustapha.aissaoui@alcatel.com>
     
    http://www.ietf.org/internet-drafts/draf
    t-aissaoui-extended-pid-00.txt
    
    ----------------------------------------
    -------------------------------
    
    
    Presenter describes MPLS PID in architecture doc. Allows multiple user 
    plane protocols in same PW. PW PID can be used for control plane to ID 
    control channel. Allows different control planes, (LSP PING, Y.1711, etc). 
    Also resolves OAM packets sharing path of user packets in case of ECMP. 
    Allows interworking of different link layers over MPLS network. This is not 
    an alternative to current paradigm. Does not require PID. Shows example 
    application.  GigE link through MPLS to FR VC Could extend FR to remote PE 
    across MPLS.
    
    
    Issues: remote PE would have to understand FR over MPLS Could 
    terminate FR VC on PE, and create multiple PWs, one for each payload type. 
    3rd option, to do PID translation between FR, PW, and Ethernet. This is 
    addressed here.
    
    
    Most straightforward option is to use PW PID. But, Used value of 0001 for 
    first nibble, and removed alert bit.
    
    
    Relationship between CW and PID: precedes PW CW in architecture
    
    
    Proposal is to reverse this to use the control word to consistently solve
    IP aliasing issue.
    No major other issues.
    Would like to keep current order of PID and CW as in architecture draft.
    Would like to progress this in PWE3.
    
    
    Yakov Stein: Understand, and it is a good idea, but looks like service 
    interworking. Trying to not use this word.
    
    
    Mustapha Aissaoui: Had thought about this issue. Key point is that we have an 
    issue to solve. I believe this is part of PWE3 because it allows 
    migration of existing installed base.
    
    
    Luca Martini: why do you need PW ID, when you could use a simple label?
    Mustapha Aissaoui: that is the second option above. You must assign a 
    label for each protocol type. Issue is that for each FR VC, you must have 
    multiple PWs
    
    
    Luca Martini: must still do the lookup for forwarding. This makes 
    hardware complex.
    Mustapha Aissaoui: translating PID is straightforward. You do this if you 
    support FR over ATM.
    
    
    George Swallow: It's not the right hand side that does translation. Don't 
    want to force other side to know what protocol is. Luca's point is that you 
    can do this from label context.
    Mustapha Aisasoui: not sufficient
    
    
    Danny McPherson: take to mailing list as this is a new charter item.
    Ali Sajassi: not as simple as a PW ID. There is a dependency of L3 over L2 
    medium. Need to be careful. My draft suggests IP PW and then all non IP to 
    used bridged encap. Need to look at bigger picture.
    Sasha Vainshtein: draft-sharc-arp-mediation describes a solution
    
    
    
    "Dave Allan" <dallan@nortelnetworks.com>
    
    http://www.ietf.org/internet-drafts/draf
    t-allan-mpls-a-bit-00.txt
    
    ----------------------------------------
    -------------------------
    
    
    This was presented in MPLS yesterday. It has implications for PWE3 and 
    MPLS. MPLS aspects will be discussed on list. Recast today to 
    illustrate thought process that lead to solution, and make clear why we got 
    here.
    
    
    Motivation: MPLS reserve label functions don't fate share with 
    associated LSPs/PWs in presence of ECMP. Directions in proactive network 
    supervision complicate fault detection. Faults can be 
    simultaneously detected by multiple uncoordinated means. Fault 
    correlation is an issue. Need to increase locality of detection. One way is 
    for probes to examine OAM flows. MPLS router alert has limitations. Use of 
    label stacking for demarcation has limitations: useful for security 
    reasons, push testing as close to CE as possible, ability to do OAM on a 
    portion of an LSP. In Dave's opinion, there is a progressive 
    divergence of PWs and LSPs. Driving commonality has utility. Multi-hop or 
    spliced LSPs may require more commonality. PID perceived as a point of 
    commonality between PWs and MPLS. Allows control and OAM flows to be muxed 
    with PWs/LSPs.
    
    
    A bit proposal is about migrating reserved label functions to PID. 
    Diagram shows the position of the A-bit.
    This is a Data Plane change: issues with b/w compatibility. E.g. what if 
    payload aliases with an RA. In summary: ECMP breaks reserve labels. 
    Reserved labels do not exists for PWs. PID+A
    
    
    George Swallow: no problem with ECMP. Should not use ECMP if you need 
    ordering. That's what you get.
    
    
    Dave Allan: What about problem statements
    
    
    George Swallow: Happy to use TTL
    
    
    Rahul Aggarwal: Not clear what problem we are trying to solve. ECMP works
    just fine. Reserved labels in MPLS are used for specific purposes. Leave 
    this alone.
    Dave Allan: ECMP implementations are sensitive to where reserved label is in 
    stack.
    
    
    Rahul Aggarwal: use inband VCCV
    Dave Allan: in absence of control word, depends on implementation
    
    
    Rahul Aggarwal: borderline case
    George Swallow: do you want to put 4 bytes into header?
    
    
    Danny McPherson: Take to list
    
    
    
    Overview of Y.17iw
    Dave Allan
    
    http://www.ietf.org/internet-drafts/draf
    t-allan-y17iw-overview-00.txt
    
    ----------------------------------------
    -----------------------------
    
    
    Put in as information on ITU work on OAM interworking. May be of 
    utility. Scope of Y.17iw. Interworking of I.610 and Y.1711 in network 
    interworking and service interworking scenarios. Approach is not to try and 
    interwork OAM protocols , but instead to use 'trigger state'. 
    Summarizes actions if PW breaks in ATM over MPLS.
    
    
    Applicability: directly applicable to encapsulations for ATM over M PLS 
    here, where Y.1711 and ATM OAM is properly supported. Also shows 
    applicability to service interworking i.e. ATM and MPLS peers. Similar or 
    OAM interworking in FRF.8 Work in progress. Proposed for consent at July 
    SG13 meeting.
    
    
    
    "Sasha Vainshtein" <Sasha@AXERRA.com>
    
    http://www.ietf.org/internet-drafts/draf
    t-vainshtein-cesopsn-06.txt
    
    ----------------------------------------
    ---------------------------
    
    
    Presents some of the discussion. First presented at IETF-52. Evolved in 
    mean time to cover additional functionality and remove 
    restrictions. Aligned with WG charter, requirements, architecture, TDM PW 
    requirements, RFC 2736, and SONET emulation draft.
    
    
    Summary of updates: Requested to adopt as a WG draft as the basis for 
    further WG work posted in June 03.
    4 successful interop tests.
    Few technical issues remain.
    No conceptual objections to unstructured services: 
    draft-stein-pwe3-stpp-00. 
    Specific technical issues: non ECMP compliant control word, because it is 
    aligned with SONET.
    
    
    Technically possible to use control word : sufficient flags (4 flags 
    needed), sufficient sequence number space, use fragmentation bits for 
    splitting basic structures of trunk specific Nx64
    
    
    Second issue: Usage of RTP header.
    
    
    Minor issues: default packet latency of unstructured E1, Frame 
    alignment for unstructured services, ?.
    
    
    Danny McPherson: presentation in a few minutes will affect this, so hold off 
    for progression discussion.
    
    
    
    "Yaakov Stein" <yaakov_s@rad.com>
    
    http://www.ietf.org/internet-drafts/draf
    t-stein-pwe3-stpp-00.txt
    
    ----------------------------------------
    ------------------------
    
    
    Simple TDM Pseudo-Wire Protocol Draft-anavi first presented at 50th IETF. 
    Several compromises reached and rejected. Multiple main modes for 
    special cases. These are there for good reason. Also, various special 
    mechanisms for clock recovery etc. Simple interworking with existing 
    AAL1/2 networks. Claimed draft-Vainshtein has evolved into a long and 
    complex draft. Single main mode with plethora of sub-modes.
    
    
    STPP was supposed to be a 'dumb' draft. Draft is only 11 pages, 
    readable by non-TDMers. Designed to cover common TDM cases. Simply 
    encapsulate arbitrary length TDM packets. No special payload 
    treatment, and highest possible b/w efficiency.
    
    
    Proposal: accept STPP for most common (simplest) TDM cases: broad 
    support, easy to implement.
    
    
    Accept TDMoIP and CESoPSN for special cases.
    
    
    Sasha Vainshtein: You listed four issues. Packet loss concealment is the 
    only one that has been addressed I a draft.
    
    
    Yaakov Stein:  No. Loss avoidance has been covered as well.
    
    
    
    "Danny McPherson" <danny@tcb.net>
    "Stewart Bryant" <stbryant@cisco.com>
    Discussion: Getting Traction on TDM
    ------------------------------------
    
    
    Put together as a result of lots of consideration by chairs. TDM is the 
    long pole test. Every encap except TDM has pretty firm. TDM 
    Unstructured TDM consensus is plausible. However, structured consensus is 
    difficult and as far away as ever.
    
    
    2 problems: commercial interests, and not enough TDM experts in IETF
    
    
    Chairs cannot allow TDM work to continue to defocus group
    
    
    4 options:
    
    
    draft-Vainshtein goes to WG, and draft-anavi becomes 
    informational. Or draft-anavi goes to WG, and draft-vainshtein becomes 
    informational. But, not clear consensus which way to go.
    
    
    Could remove structured work, in which case this would cease and we would 
    pick one of the unstructured approaches from the draft. Structured 
    approached become informational.
    
    
    Alternatively, drop TDM altogether.
    
    
    Draft-stein-pwe3-stpp-00.txt is the only current draft. Short. May need RTP 
    support. Could take draft Vainshtein unstructured as alternate starting 
    point.
    
    
    Decision: Chairs pick a neutral editor to pick best of both. Split 
    structured and unstructured work. Editor to take it forward.
    
    
    Yakov Stein: other possibility is to make one common draft that we can 
    agree on. No issues with STPP, issue is wording, so perhaps we could 
    consider a short time frame of one month to do this.
    
    
    Tim Fross: unstructured draft is fine whichever. Structured drafts will 
    have to be rewritten, so as a refinement to chairs approach, rewrite 
    draft-stein and draft-anavi with just unstructured and then have WG run 
    off.
    
    
    Tim Fross: unstructured draft is fine whichever. Structured drafts will 
    have to be rewritten.  I support the  chairs suggestion of 
    progressing the structured versions of draft-vainshtein and 
    draft-anavi as informational.
    
    
    Yakov Stein: lack of support for either draft is not the problem. Agrees we 
    should remove unstructured portions out, clean up.
    
    
    Stewart: About time we stopped the beauty contest. Time to stop it. 
    Concerned about RTP should it be dropped off?
    
    
    Yakov Stein: no problem with RTP as an option for whoever wants it.
    
    
    Danny McPherson: Sasha & Yakov to get back to chairs on this and come up 
    with unstructured draft. Need to see something by Sept 1st.
    
    
    Sasha Vainshtein: Agree with proposal for split to structured and 
    unstructured and will produce something in around one month.
    
    
    Stewart Bryant: The chairs will look for some one to edit 
    unstructured draft after September, if we need to.
    
    
    Sasha Vainshtein: tight timetable is reasonable.
    
    
    Outcome:
    
    
    1) Yaakov Stein and Sasha Vainshtein agreed to produce a joint 
    unstructured draft by 1st September
    
    
    2) WG Chairs will hold off seeking neutral editor unless this effort fails
    
    
    3) Yaakov Stein and Sasha Vainstein invited to re-present their 
    structured work as individual drafts.
    
    
    
    Luca Martini <luca@level3.net>
    draft-ietf-pwe3-control-protocol-03.txt
    
    ----------------------------------------
    
    
    Rewritten ATM Oam procedures. Added status TLV section. Updated 
    diagrams. More work? Add clarification to generalized FEC? Could do in 
    PPVPN. Would like to go for last call after next revisions.
    
    
    draft-ietf-pwe3-ethernet-encap-03.txt
        Stable for a long time and would like to go for last call.
    
    
    draft-ietf-pwe3-iana-allocation-01.txt
        Cleaned up some allocation conflicts, and added PW status TLV bit 
    allocations. Should I rewrite the status TLV?
    
    
    Sahsa V: assuming unstructured TDM will be done soon, can we have PW types 
    for this included?
    
    
    Stewart: assume this is a convenient method for talking to IANA?
    
    
    Luca Martini: Yes.  Will put allocations in.
    
    
    Danny: good, we have progress for some things to last call.
    
    
    draft-ietf-pwe3-atm-encap-02.txt
        This is a major revision. Consolidated applicability statements and 
    control word. Updated OAM. Aligned control word with architecture draft. 
    Other list of updates. Should be ready to go for last call.
    
    
    Stewart: does this align with ITU Recommendation?
    Luca: yes. No major technical change.
    
    
    
    "Himanshu Shah" <hshah@ciena.com>
    
    draft-shah-pwe3-control-protocol-extension-01.txt
    
    -------------------------------------------------
    
    
    Extension to control protocol for dynamic parameter signaling. Draft 
    proposes mechanism for 2 PEs to exchange attributes without tearing down the 
    PW. E.g. IP address for ARP mediation, and IP+MAC for IPLS.
    
    
    Claims simple and easy and easy to implement.
    
    
    PEs learn each others capability for exchanging dynamically.
    Dynamic signaling: two methods to signal updates to PW attributes 
    without withdrawing the FEC. Both methods work, but draft recommends LDP 
    notification message. Would like feedback from WG. Shows example of PW 
    status signaling., but other attributes can be exchanged e.g. IP address 
    TLV, IP+MAC address TLV, etc.
    Conclusion: need generic mechanism to extend signaling in backward 
    compatible fashion to include capability signaling. Requests draft 
    adopted as WG item.
    
    
    Sasha Vainshtein: this mechanism would be very helpful in solving 
    congestion detection problem. Would like to support this draft. Also 
    resolves issue of ARP mediation, where you cannot 
    Luca Martini: Status indication is already in control draft. Other TLVs are 
    all useful and should be defined. Question is where? Doesn't 
    necessarily fit in control draft You are proposing list of parameters for 
    PW. Most useful for VPLS.
    
    
    H.Shah: not limited to VPLS
    Luca Martini: we can do the agreeable parts if there is another 
    interest on the mailing list.
    
    
    Hamid Ould-Brahim: additions are just a particular provisioning model. 
    Signaling capability is an important aspect.
    Luca Martini: that's why we have L2VPN WG.
    
    
    Danny: take to the list.
    Ali Sajassi: good to have this mechanism, but TLVs are not right for PWE3.
    
    
    Stewart: continue on list, and decide which parts to take in PWE3
    
    
    
    "Ghassem Koleyni" <ghassem@nortelnetworks.com>
    Update on activities in ITU-T SG13 regarding interworking topics
    
    ----------------------------------------
    ------------------------
    
    
    Update on what is happening on Q5 of SG13. Shows the general network 
    interworking model.  Two Recommendations will be published: cell mode and 
    frame mode. Cell mode has two modes: N-to-one and one-to-one. Aligned with 
    IETF and ATM forum. Thanks all authors.
    
    
    Frame mode document (AAL5 PDU mode and SDU mode) expected to go for 
    consent at July SG13 meeting.
    
    
    Other topics: FR-MPLS network interworking, TDM-MPLS network 
    interworking, voice services over MPLS, and general service 
    interworking where networks either side of MPLS core are dissimilar. Have 
    started to work on requirements for ATM-MPLS-FR. OAM aspects are jointly 
    handled by Q5 and Q3.
    
    
    Andy Malis: suggest SG13 should follow SG17 work on X.84 on FR 
    interworking.
    
    
    Andy Malis: Work here in FR interworking has been kept aligned with SG17 
    work.
    
    
    Ghassem Koleyni: need as much synergy as possible if multiple parties work on 
    the same draft.
    
    
    Stewart: would like to receive contribution drafts on how to tackle 
    congestion.
    
    
    MEETING CLOSES
    

    Slides

    Agenda
    PWE3
    Getting Traction on TDM
    Summary of Discussion
    PW Setup & Maintenance
    Dynamic Parameter Signaling
    The Case for the ‘A’ bit in the MPLS/PW PID (redux)
    Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV) Update
    Extended MPLS/PW PID
    Simple TDM Pseudowire Protocol
    ITU-T SG13 activities related to interworking between networks