2.8.12 Pseudo Wire Emulation Edge to Edge (pwe3)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-14

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

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

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

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

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

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

Assumptions

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

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

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

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

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

WG Objectives (in order of priority):

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

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

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

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

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

Deliverables

General documents:

Requirements Document

Framework Document

Common Edge-to-Edge Emulation/Maintenance Protocol Requirements for PW Traceroute (if distinct from tunnel-specific or CCAMP traceroute).

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

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

Frame Relay

ATM

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

MPLS (over IP or L2TP only)

Out of Scope

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

Methods to signal underlying network.

Other Working Groups We Will Coordinate With

L2TPEXT, DIFFSERV, AVT, CCAMP, PPVPN, MPLS, TEWG, ROHC

Goals and Milestones:
Done  PWE3 WG started, organize editing teams.
Done  Hold interim meeting, including discussion of priority of service-specific documents and consider pruning some deliverables
JUN 02  Accept drafts of service-specific documents as WG items
JUN 02  Framework Documents Last Call
JUN 02  Requirements Document Last Call
DEC 02  TDM Circuit Documents Last Call
DEC 02  SONET Documents Last Call
DEC 02  ATM Documents Last Call
DEC 02  Ethernet Documents Last Call
DEC 02  Frame Relay Documents Last Call
MAR 03  PWE3 MIBs Last Call
MAR 03  PWE3 WG Charter Review, Additional Work or Ends
Internet-Drafts:
  • - draft-ietf-pwe3-requirements-04.txt
  • - draft-ietf-pwe3-framework-01.txt
  • - draft-ietf-pwe3-protocol-layer-00.txt
  • - draft-ietf-pwe3-pw-mib-00.txt
  • - draft-ietf-pwe3-pw-mpls-mib-00.txt
  • - draft-ietf-pwe3-pw-tc-mib-00.txt
  • - draft-ietf-pwe3-sonet-01.txt
  • - draft-ietf-pwe3-sonet-vt-00.txt
  • - draft-ietf-pwe3-ethernet-encap-02.txt
  • - draft-ietf-pwe3-control-protocol-01.txt
  • - draft-ietf-pwe3-cep-mib-01.txt
  • - draft-ietf-pwe3-enet-mib-00.txt
  • - draft-ietf-pwe3-arch-02.txt
  • - draft-ietf-pwe3-fragmentation-00.txt
  • - draft-ietf-pwe3-frame-relay-00.txt
  • - draft-ietf-pwe3-atm-encap-01.txt
  • - draft-ietf-pwe3-tdm-requirements-00.txt
  • - draft-ietf-pwe3-iana-allocation-00.txt
  • No Request For Comments

    Current Meeting Report

    soon.PWE3 @IETF56 -- San Francisco, CA  March 19, 2003
    
    Minutes Recorded by Vach Kompella
    
    No agenda bashing allowed - lack of time
    
    Progress (Danny)
     - security considerations needs more work
     - need feedback from security wg
     - terminology, and refs need to be cleaned up
    
     3 week last call on new rev of pwe3 requirements
    
    Architecture (Stewart)
    
     - all feedback incorporated except
      - all syntax/terminology is more ietf-oriented
      - ref models retained from the reqmts draft
    
     - generic control word
      - need more flag bits
      - specify ttl = 2
      - use pid to make a first level determination that the packet is NOT ip
       - propose pid=0 for pwe3
       - reject control words that use 4 for the first nibble
       - itu-based control word violate this (stewart)
       - dave allan: isn't this iana issue
       - yaakov s: at least 2 in violation of the basic limitation != 0, 4, 6
       - chris l: why assume that it is always ip?
       - mark t: this is for pw that requires control, or requires all pws to 
    implement cw
       - mark t: can't accidentally use 4 or 6
       - stewart b: can't squander the bits, so can't limit to not using 0, 4, 6
       - mustafa: don't use that position (1st nibble) for anything
       - andy m: mpls implied that ipv4/ipv6 carried by mpls
          need lot more discussion
       - andy m: make it self-describing, not this half-baked approach
       - luca m: don't call pid because it is not a protocol id, but maybe a 
    class
       - find out packet is ip by computing checksum, other methods 
    (general groans from audience)
       - george swallow: for better or worse, mpls decided not to have 
    protocol
           - need some way to find what is in there, to identify flows
           - various hacks out there
       - eric r: original encap did have pid but it was deemed 
    unnecessary
       - mark t: need to have defined value that is pw
       - vach k: this is really version, so can use 1, 2, 3, 5
       - dave mcdysan: 5 may still be in use
    
     - congestion
       - pwe3 may be used by end-user and so it will be
       - text from rtp wg
       - if known to carry tcp, then its own backoff mech kicks in so no need 
    for extra work
       - if not, pw must provide a loss-sensitive backoff mech
         - done by nsp, and out of scope
         - long term avg for tcp throughput
    
     - issues
       - do we need cong ctrl
       - is perfect emulation more important than congestion mgmt
       - what to do if we detect congestion?
       - how to identify a traffic class to do measurements on?
       - run over dccp?
       - congestion mech like red and yellow cards - backoff or drop 
       - need more description on the pwe3 congestion approach?
    
       - rahul a: if qos sla is broken, what to do?  We haven't reached that 
    point because we don't know what to do yet
       - rahul a: some measuring mechanism is required [Stewart Agrees]
       - steve casner: perfect emulation means that when congestion occurs, the 
    pw is probably breaking anyway,
         - what about other protocols over ip?  who is responsible for better 
    behavior, pw mgmt or just regular internet behavior
           - sb: whatever the internet does
       - mustafa: how to make some AS's take action, across admin 
    boundary.  can't take unilateral action to curb traffic
          - how to provide enough info so that the feeder of the 
    congestion is notified of what is causing congestion
          - need fault notification
       - mark t: hope i'm not hearing that p routers have to worry about 
    congestion
    
    OAM reqmts (Tom Nadeau)
       - promised not to bore us
       - sp reqmts
       - common set of oam reqmts for mpls networks
       - read the draft
    
    VCCV (Tom Nadeau)
       - mech for pwe3 using inband diagnostic
       - two approaches
         - use a bit in the flags (although none are left)
         - use a pid
         - mustafa: can't use existing tools to test PWs.  use existing tools - 
    there are already existing approaches.
           - tom: using those mechs you can't tell whether a p router is 
    broken
           - mustafa: if you have native oam, then you can determine pw 
    connectivity
              - lsp-ping for tunnel, and native oam for pw
              - not needed
              - but what fixes the problem with vc lsp and tunnel 
    connectivity
       - dave allan: use a bit to identify the packet is an inband test 
    packet
           - the reply is back over the vc
           - tom: yes, the pw is bi-di
           - what identifies what comes in the test packet? read the draft
       - shahram: can't use lsp-ping? because of ecmp?
           - tom: not necessarily, want to follow the disposition path of the 
    egress, so we want the packet to be encapped correctly
           - george: you can't just ping the vc lsp, you need to identify the 
    packet as a test packet
       - george swallow: (off-mike) something about informal survey of ecmp 
    hashing methods - if detected to be ip, then fish in packet header , etc.
       - yaakov s: pws are defined as uni-directional
       - george s: always send the reply in the control plane
       - single-sided downstream unsolicited - incorrect in draft
       - still need to find a way to identify the test nature of a packet
    
       - take to wg for discussion
    
    
    Mesg mapping (Tom Nadeau)
        - based on a customer oam reqmt
    
        - translation of failures in lsp-ping or vccv to atm oam or other l2 oam 
    messages
    
        - what to do about ethernet?
    
        - mustafa: mapping of state: need to check several things
              - cv is pro-active
              - but need defect indication (e.g., mpls tunnel failure needs to be 
    used to generate ais type messages)
              - look into the proper oam and mapping of defects, rather than 
    looking at it as a mapping of messages (which sounds like 
    interworking of the native and mpls oam)
              - reactive mechanisms need to be addressed
              - tom n: this is not the be-all end-all, look at all the tools to 
    solve the problems, this is only part of the solution
        - dave a: use of withdrawal of label as failure manifestation - so need 
    to address in data plane
    
    ATM mib (Tom Nadeau)
        - adds to the basic structure of the mibs for pwe3
    
    TDM (Tim Frost filling in for tom johnson)
        - why another?
        - 2 years of deadlock, and no compromises have worked
        - tom put in charge of dt to address this
        - draft-johnson
          - same control word structure more or less as sonet draft
          - unstructured em mode: pure bitstream, normal segmentation
          - (see draft for details)
          - broad agreement on this mode from dt (debate on default size of 
    payload)
    
          - structured em (NxDS0 w/ CAS)
          - similar to atm cem doc
    
          - structured em (NxDS0 w/o CAS)
          - based on tdm multiframe format
    
          - discussion on how to choose the arbitrary payload length
          - need feedback from list as to whether this draft breaks the 
    deadlock
          - yaakov: unstruct mode - everyone agrees
                    struct mode: disagreement because the optional 
    mandatory mode is not well-defined
          - tim: why pick a size that fits the tdm network when we are going 
    into a pkt network that can have
          - alex: how many advantages of the other drafts are preserved?
          - tim: succeeds in preserving structure, uses the same cas 
    structure (atm interworking is more difficult)
          - alex: why not preserve draft-anavi advantage (atm 
    interworking)
          - tim: because it is not possible to solve both problems
          - alex: but draft-anavi is for unstruct mode
          - danny: if you have a draft that preserves all advantages then we'd be 
    happy, but we need a compromise
          - danny: bring it to the mailing list
          - steve (axerra): big picture - lot of activity suggesting 
    solutions or identifying problems - what changes are in the offing?
          - tim: in the area of how to segment it into different payload 
    sizes, with the tradeoff into efficiency or latency
          - steve: what about areas like lost packets?
          - tim: needs to be addressed, but probably minor (in terms of 
    controversy)
          - shahram: ask list which is more important. constant delay from pe to 
    pe regardless of the bit rate, or ease of atm interworking
    
    
    TDM reqmts (Max Riegel)
        - init draft covered t1, e1, t3, e3
        - needed to cover sdh/sonet
        - rest from the slides
        - revised edition out beginning of may, continue discussion on list
    
    TDMOIP-LE (Yaakov Stein)
        - loop emulation for congestion control
        - form id does not conflict with pid
        - aal2 is variable bit rate so allows more nsp processing (e.g., vad, 
    compression, etc.)
        - tcp is 1st class citizen, and tdm is dropped with congestion (which is 
    contrary to service provider needs)
        - if pw traffic is small, and not all of it is tdm.  so for 
    statistical peak situation by dropping packets and conceal with nsp 
    techniques
        - to deal with congestion avoidance
           - we must have vbr mode
           - cw must have length field
           - form id is needed (since we can't change modes in control plane)
        
    
    TDM Structured Em (Sasha - who subbed for him?)
       - mostly stuff right from the slides
       - main concept: nsp function allows for less perfect structure
       - see convergence on tdm in the offing
    
       - Why there has been difficulty in obtaining consensus for TDM work, and 
    how to resolve it?
    
       - Good news -
         - consensus on emulation of unstructured TDM (E1,T1,E3,T3) is close
       - Bad news
         - situation with structured tDM, because different people mean 
    different things
       - clear WG position on scope, reqts and arch lacking for 
    structured TDM.
    
       - Tried to clarify what structured TDM means and why we care about it.
       - Bandwidth saving on psn by skipping unused channels
         - efficiency
         - resilience of attachment circuit and specific applications to 
    packet loss
         - application-specific BW mgmt
    
       - Piece of wire vs. Distributed DXC approaches.
    
       - Conclusion - optimistic for consensus on different approaches.
    
    MPLS FORUM liaison (Andy Malis)
    
       - current draft "TDM Emulation over MPLS using AAL1" is ready
       - please read and comment
    
    PWE3 control and maintenance changes (Luca)
       - changes include
        - refs
        - single sided mode
        - atm modes
        - numeric allocations to separate iana draft
    
        atm-encap
        - n-to-1 cell mode default
        - need some defs in 1-to-1 mode
        - may conflict with the arch doc
    
        ethernet-encap
        - tagged option needs reworking: move to nsp function
        - resolve and move to wg last call
    
        danny: need to resolve other docs before ethernet encap moves 
    forward even though it is ready
    
        - rahul a: don't understand need to change. the tagged mode 
    supports tagged mode and the spec should be left unchanged.   
        - rahul a: there are existing implementations and some deployment 
    around the tagged mode.
        - luca m: tagged mode is needed to overcome limitations of ip 
    routers
        - ali s: both modes are useful
        - luca m: send comments to mailing list
    
    AAL1 transport (Shahram)
        - does not introduce new protocol
        - suggest move to informational wg
        - andy m: third suggestion - don't use pdu mode
           - also, l&r bits handling is not just informational, adds 
    protocol changes so draft can't be info
        - yaakov s: support the draft, need atm encap draft changes
    
    L2TPV3 (Mark Townsley)
        - draft is in hands of iesg
        - companion drafts are in last call
        - will post to the list on the status
    
    David Allan
        - y1711 and lsp-ping are complementary
        - for pwe3: easy to do oam interworking with y1711
        - with oam in dp, will prevent overloading control plane and label 
    removal
        - danny: send points to mailing list
    
    Danny: work on documents between meetings, and not just near the IETFs
    

    Slides

    Agenda
    PWE3 Architecturel
    'draft-sathappan-pw-atm-mib-00'
    'draft-nadeau-pwe3-vccv-00'
    'draft-nadeau-ietf-oam-requirements-01'
    'draft-nadeau-pwe3-msgmap-00'
    TDM Circuit Emulation over Packet (CEP-TDM)
    Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switched Networks
    Using TDMoIP Loop Emulation for congestion control
    Edge-to-edge Emulation of Structured TDM Services over PSN: Open Issues
    MPLS Forum Liaison
    PW Setup & Maintenance Using LDP
    Y.1711 & LSP-PING
    Transport of AAL1 Frames over PSN