Internet Draft                                               XiPeng Xiao
Document: draft-ietf-pwe3-requirements-02.txt              Photuris Inc.
Expires: May 2002                                        Danny McPherson
                                                          Amber Networks
                                                            Prayson Pate
                                                 Overture Networks, Inc.
                                                             Craig White
                                            Level 3 Communications, LLC.
                                                        Kireeti Kompella
                                                  Juniper Networks, Inc.
                                                              Vijay Gill
                                          Metromedia Fiber Network, Inc.
                                                        Thomas D. Nadeau
                                                     Cisco Systems, Inc.

       Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
                  draft-ietf-pwe3-requirements-02.txt


                          Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.  Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   Material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   This document describes generic requirements for Pseudo-Wire
   Emulation Edge to Edge (PWE3). It provides guidelines for other
   working group documents that will define mechanisms for providing
   pseudo-wire emulation of specific services such as Ethernet, ATM,
   Frame Relay, TDM, and MPLS. It should be noted that the PWE3 Working
   Group (PWE3 WG) standardizes mechanisms that can be used to provide
   PWE3 services, but not the services themselves.


Copyright Notice

   Copyright (C) The Internet Society (2001). All Rights Reserved.






Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

                             Table of Contents

   1 Introduction .................................................    4
   1.1 Reference Model of PWE3 ....................................    4
   1.2 Terminology ................................................    5
   2 Packet Processing ............................................    6
   2.1 Encapsulation ..............................................    6
   2.1.1 Conveyance of Necessary L2/L1 Header Information .........    7
   2.1.2 Support of Variable Length PDUs ..........................    7
   2.1.3 Support of Multiplexing and Demultiplexing ...............    7
   2.2 Frame Ordering .............................................    7
   2.3 Frame Duplication ..........................................    7
   2.4 Segmentation and Reassembly ................................    7
   2.5 Handling Control Messages of the Native Services ...........    8
   2.6 Consideration of PSN Tunnel Header Overhead ................    8
   3 Maintenance of Emulated Services .............................    8
   3.1 Setup and Teardown of Pseudo-Wires .........................    8
   3.2 Status Monitoring ..........................................    9
   3.3 Notification of Status Changes .............................    9
   3.3.1 Up/Down Notification .....................................    9
   3.3.2 Misconnection and Payload Mistype ........................    9
   3.3.3 Packet Loss, Corruption, and Out-of-order Delivery .......   10
   3.3.4 Other Status Notification ................................   10
   3.3.5 Collective Status Notification ...........................   10
   3.4 Keep-alive .................................................   10
   3.5 Clock Recovery .............................................   10
   4 Management of Emulated Services ..............................   11
   4.1 MIBs .......................................................   11
   4.2 General MIB Requirements ...................................   11
   4.3 Configuration and Provisioning .............................   11
   4.4 Performance Monitoring .....................................   11
   4.5 Fault Management and Notifications .........................   11
   4.6 Pseudo-Wire Traceroute .....................................   12
   5 Faithfulness of Emulated Services ............................   12
   5.1 Characteristics of an Emulated Service .....................   12
   5.2 Service Quality of Emulated Services .......................   13
   6 Scalability ..................................................   13
   7 Other Generic Requirements ...................................   14
   7.1 RFC 2914 Conformance .......................................   14
   8 Non-Requirements .............................................   14
   9 Quality of Service (QoS) Considerations ......................   15
   10 Inter-domain Pseudo-Wires ...................................   15
   11 Security Considerations .....................................   15
   11.1 Security Considerations for  Signaling/Control  Channels
        ...........................................................   15
   11.2  Security Considerations for PW PDUs ......................   15
   11.3  Security Considerations for  Use  of  Non-path-oriented
        PWs .......................................................   15
   12 Deployment Considerations ...................................   16
   13 Acknowledgments .............................................   16
   14 References ..................................................   16
   15 Authors' Addresses ..........................................   17

Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau    [Page 2]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001
   16 Full Copyright Section ......................................   19





















































Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau    [Page 3]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

1.  Introduction

1.1.  Reference Model of PWE3

   A pseudo-wire (PW) is a connection between two provider edge (PE)
   devices which connects two pseudo-wire end-services (PWESs) of the
   same type. A PWES is either:
     - an Ethernet link or a VLAN link between two ports, or
     - an ATM VC or VP, or
     - a Frame Relay VC, or
     - a TDM circuit, or
     - an MPLS LSP
   between a customer edge (CE) device and a PE (See Figure 1).  During
   the setup of a PW, the two PEs will be configured or will
   automatically exchange information about the service to be emulated
   so that later they know how to process packets coming from the other
   end. After the PW is set up, layer-2 (e.g. Ethernet, ATM, Frame Relay
   and MPLS) or layer-1 (e.g. SONET/SDH) PDUs from a PWES are
   encapsulated at the PW ingress. The encapsulated PDUs are then sent
   over the PW to the egress, where L2 or L1 headers are re-constructed
   and the resulted frames are forwarded in their native format to the
   other CE.

                    |<------- Pseudo Wire ------>|
                    |                            |
                    |    |<-- PSN Tunnel -->|    |
              PW    V    V                  V    V    PW
         End Service+----+                  +----+ End Service
   +-----+    |     | PE1|==================| PE2|     |    +-----+
   |     |----------|............PW1.............|----------|     |
   | CE1 |    |     |    |                  |    |     |    | CE2 |
   |     |----------|............PW2.............|----------|     |
   +-----+    |     |    |==================|    |     |    +-----+
         ^          +----+                  +----+     |    ^
         |      Provider Edge 1         Provider Edge 2     |
         |                                                  |
         |<-------------- Emulated Service ---------------->|

   Customer                                                 Customer
    Edge 1                                                   Edge 2

                     Figure 1: PWE3 Reference Model

   This document does not assume that a particular type of PWs is used.
   Instead, it describes generic requirements that apply to all PWs, for
   all services including Ethernet, ATM, Frame Relay, TDM and MPLS.

   This document is not an introductory document. For an architecture

Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau     [Page 4]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

   overview of PWE3, readers should refer to the PWE3 framework document
   [PATE].

1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

   Below are the definitions for the terms used throughout the document.

   Packet Switched Network
                      A Packet Switched Network (PSN) is a network using
                      IP or MPLS as the unit of switching.

   Pseudo Wire Emulation Edge to Edge
                      Pseudo Wire Emulation Edge to Edge (PWE3) is a
                      mechanism that emulates the essential attributes
                      of a service (such as a T1 leased line or Frame
                      Relay) over a PSN.

   Customer Edge      A Customer Edge (CE) is a device where one end of
                      an emulated service originates and terminates. The
                      CE is not aware that it is using an emulated
                      service rather than a "real" service.

   Provider Edge      A Provider Edge (PE) is a device that provides
                      PWE3 to a CE.

   Pseudo Wire        A Pseudo Wire (PW) is a connection between two PEs
                      carried over a PSN. The PE provides the adaptation
                      between the CE and the PW.

   Pseudo Wire PDU    A Pseudo Wire PDU (PW PDU) is a PDU sent on the PW
                      that contains all of the data and control
                      information necessary to provide the desired
                      service.

   PSN Tunnel         A PSN Tunnel is a tunnel inside which multiple PWs
                      can be nested so that they are transparent to core
                      network devices.

   Path-oriented PW   A Path-oriented PW is a PW for which the network
                      devices of the underlying PSN must maintain state
                      information.


Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau     [Page 5]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

   Non-path-oriented PW
                      A Non-path-oriented PW is a PW for which the
                      network devices of the underlying PSN need not
                      maintain state information.

   Service Interworking
                      In Service Interworking, the IWF (Interworking
                      Function) between two dissimilar protocols (e.g.,
                      ATM & MPLS, Frame Relay & ATM, ATM & IP, ATM &
                      L2TP, etc.) terminates the protocol used in one
                      network and translates (i.e. maps) its Protocol
                      Control Information (PCI) to the PCI of the
                      protocol used in other network for User, Control
                      and Management Plane functions to the extent
                      possible.

                      In general, since not all functions may be
                      supported in one or other of the networks, the
                      translation of PCI may be partial or non-existent.
                      However, this should not result in any loss of
                      user data since the payload is not affected by PCI
                      conversion at the service interworking IWF.

   Network Interworking
                      In Network Interworking, the PCI (Protocol Control
                      Information) of the protocol and the payload
                      information used in two similar networks are
                      transferred transparently by an IWF of the PE
                      across the PSN. Typically the IWF of the PE
                      encapsulates the information which is transmitted
                      by means of an adaptation function and transfers
                      it transparently to the other network.

2.  Packet Processing

   This section describes forwarding plane requirements for PWE3.

2.1.  Encapsulation

   Every PE MUST provide service interfaces for encapsulating PDUs from
   the PWESs.  It should be noted that the PDUs to be encapsulated may
   or may not contain L2 or L1 header information.  This is service
   specific.  Every PWE3 service MUST specify what the PDU is.

   A PW header consists of all the header fields in a PW PDU that are
   used by the PW egress to determine how to process the PDU. The PSN
   tunnel header is not considered as part of the PW header.

   Specific requirements on PDU encapsulation are listed below.

Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau     [Page 6]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

2.1.1.  Conveyance of Necessary L2/L1 Header Information

   The egress of a PW needs some information, e.g. which native service
   the PW PDUs belong to, and possibly some L2 or L1 header information,
   in order to know how to process the PDUs received.  A PWE3
   encapsulation approach MUST provide some mechanism for conveying such
   information from the PW ingress to the egress. It should be noted
   that not all such information must be carried in the PW header of the
   PW PDUs. Some information (e.g. service type of a PW) can be stored
   as state information at the egress during PW setup.

2.1.2.  Support of Variable Length PDUs

   A PWE3 approach MUST accommodate variable length PDUs, if variable
   length PDUs are allowed by the native service.  For example, a PWE3
   approach for Frame Relay MUST accommodate variable length frames.

2.1.3.  Support of Multiplexing and Demultiplexing

   If a service in its native form is capable of grouping multiple
   circuits into a "trunk", e.g. multiple ATM VCs in a VP or multiple
   Ethernet VLANs in a port, some mechanism SHOULD be provided so that a
   single PW can be used to connect two end-trunks.  From encapsulation
   perspective, the encapsulation header MUST carry sufficient
   information so that the egress of the PW can demultiplex individual
   circuits from the PW.

2.2.  Frame Ordering

   When packets carrying the PW PDUs traverse a PW, they may arrive at
   the egress out of order. For some services, the frames (either
   control frames only or both control and data frames) must be
   delivered in order. For such services, some mechanism MUST be
   provided for ensuring in-order delivery. Providing a sequence number
   in the PW header for each packet is one possible approach.

2.3.  Frame Duplication

   In rare cases, packets traversing a PW may be duplicated.  For some
   services, frame duplication is not allowed. For such services some
   mechanism MUST be provided to ensure that duplicated frames will not
   be delivered. The mechanism may or may not be the same as the
   mechanism used to ensure in-order frame delivery.

2.4.  Segmentation and Reassembly

   It is desirable to avoid packet Segmentation and Reassembly (SAR).
   One way to do this is to set the MTU of the links between the CEs and
   the corresponding PEs to a value smaller than (PW_Path_MTU -

Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau     [Page 7]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

   PW_header - PSN_tunnel_header), if that is possible.

   If SAR cannot be completely avoided, at a PW ingress, if the length
   of a packet resulted from encapsulation would exceed the PW_Path_MTU,
   the PDU MAY be dropped. In this case, the management plane of the
   ingress PE MAY be notified. Alternatively, a segmentation mechanism
   MAY be defined and used. At a PW egress, if the length of a L2/L1
   frame that is restored from a PW PDU exceeds the MTU of destination
   PWES, it MUST be dropped. In this case, the management plane of the
   egress PE MAY be notified.

2.5.  Handling Control Messages of the Native Services

   Some native services use control messages for maintaining the
   circuits. These control messages may be in-band, e.g. Ethernet flow
   control or ATM performance management, or out-of-band, e.g. the
   signaling VC of an ATM VP.

   It is desirable that the PEs participate as little as possible in the
   signaling and maintenance of the native services. However, it is up
   to each specific PWE3 approach to specify what the PEs MUST do in
   this regard.  For an emulated service, it is possible that some
   control messages (e.g. OAM) are processed at the PEs while others are
   passed through transparently like data messages to the remote CE.  If
   control messages are passed through, it MAY be desirable to provide
   higher reliability for them. The mechanisms for providing the high
   reliability NEED NOT be defined in the PWE3 WG.

2.6.  Consideration of PSN Tunnel Header Overhead

   In order to reduce PSN tunnel header overhead, multiple PDUs MAY be
   concatenated before a PSN tunnel header is added. Each PDU still
   carries its own PW header so that the egress of the PW knows how to
   process it. However, the benefit of concatenating multiple PDUs for
   header efficiency should be weighed against the resulting larger
   penalty incurred by packet loss.

3.  Maintenance of Emulated Services

   This section describes control plane requirements for PWE3.

3.1.  Setup and Teardown of Pseudo-Wires

   A PW must be set up before an emulated service can be established,
   and must be torn down when an emulated service is no longer needed.
   Setup and teardown of a PW can be triggered by a CLI command from the
   management plane of a PE, or by signaling (i.e. setup or teardown) of
   a PWES, e.g., an ATM SVC.

   Every PWE3 approach MUST define some setup mechanism for establishing

Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau     [Page 8]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

   the PWs. During the setup process, the PEs need to exchange some
   information (e.g. learn each other's capability).  The setup
   mechanism MUST enable the PEs to exchange all necessary information.
   For example, both endpoints must agree on methods for encapsulating
   PDUs and handling frame ordering. Which signaling protocol to use and
   what information to exchange are service specific. Every PWE3
   approach MUST specify them.  Manual configuration of PWs can be
   considered as a special kind of signaling and is explicitly allowed.

   Sessions in a [L2TPv3] tunnel or [MPLS] LSPs can be used as PWs.
   Selection of a particular type of PWs is carrier-dependent and is
   outside scope of the PWE3 WG.

3.2.  Status Monitoring

   Some native services have mechanisms for status monitoring. For
   example, ATM supports OAM for this purpose.  For such services, the
   corresponding emulated services MUST specify how to perform status
   monitoring.  The mechanisms NEED NOT be defined in this WG. Some
   status monitoring mechanisms defined in other WGs, e.g. [LSPPING] or
   [MPLSOAM], may be leveraged.

3.3.  Notification of Status Changes

3.3.1.  Up/Down Notification

   If a native service is bi-directional, the corresponding emulated
   service can only be signaled up when the associated PWs, and PSN
   tunnels if any, in both directions are functional.

   Because the two CEs of an emulated service are not adjacent, a
   failure may occur at a place such that one or both physical links
   between the CEs and PEs remain up. For example in Figure 1, if the
   physical link between CE1 and PE1 fails, the physical link between
   CE2 and PE2 will not be affected and will remain up. Unless CE2 is
   notified about the remote failure, it will continue to send traffic
   over the emulated service to CE1. Such traffic will be discarded at
   PE1.  Some native services have failure notification so that when the
   services fail, both CEs will be notified.  For such native services,
   the corresponding PWE3 service MUST provide a failure notification
   mechanism.

   Similarly, if a native service has notification mechanism so that
   when a network failure is fixed, all the affected services will
   change status from "Down" to "Up", the corresponding emulated service
   MUST provide a similar mechanism for doing so.

3.3.2.  Misconnection and Payload Mistype



Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau     [Page 9]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

   With PWE3, misconnection and payload mistype can occur. A PWE3
   approach MAY define some mechanism for detecting and handling
   misconnection and payload mistype.

3.3.3.  Packet Loss, Corruption, and Out-of-order Delivery

   A PW can incur packet loss, corruption, and out-of-order delivery.
   This can impact the working condition of an emulated service.  Packet
   loss, corruption, and out-of-order delivery can be considered as
   "generalized bit error" of a PW. If a native service has some
   mechanism to deal with bit error, the corresponding PWE3 service
   SHOULD provide a similar mechanism.

3.3.4.  Other Status Notification

   A PWE3 approach MAY provide mechanism for other status notification,
   if any.

3.3.5.  Collective Status Notification

   Status of a group of emulated services may be affected identically by
   a single network incidence.  For example, when the physical link
   between a CE and a PE fails, all the emulated services that go
   through that link will fail.  It is likely that there exists a group
   of emulated services which all terminate at a remote CE. (There can
   be multiple such CEs). Therefore, it is desirable that a single
   notification message be used to notify failure of the whole group of
   emulated services.  A PWE3 approach MAY provide some mechanism for
   notifying status changes of a group of emulated circuits.  One
   possible approach is to associate each emulated service with a group
   ID when the PW for that emulated service is set up. Multiple emulated
   services can then be grouped by associating them with identical group
   ID. In status notification, that group ID can be used to refer all
   the emulated services in that group.

3.4.  Keep-alive

   If a native service has keep-alive mechanism, the corresponding
   emulated service MUST define a similar mechanism for keep-alive.

3.5.  Clock Recovery

   For some services, the PEs need to maintain some kind of timing
   relationship (e.g. synchronization). The corresponding PWE3 services
   MUST provide some mechanism to support that. If time stamps need to
   be carried across the PSN, [RTP] MUST be used.




Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau    [Page 10]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

4.  Management of Emulated Services

   Each PWE3 approach SHOULD provide some mechanisms for network
   operators to manage the emulated service. These mechanisms can be in
   the forms described below.

4.1.  MIBs

   SNMP MIBs [SMIV2] MUST be provided for managing each emulated service
   as well as pseudo-wire in general. These MIBs SHOULD be created with
   the following requirements.

4.2.  General MIB Requirements

   New MIBs MUST augment or extend where appropriate, existing tables as
   defined in other existing service-specific MIBs for existing services
   such as MPLS or L2TP. For example, the ifTable as defined in the
   Interface MIB [IFMIB] MUST be augmented to provide counts of out-of-
   order packets. A second example is the extension of the MPLS-TE-MIB
   [TEMIB] when emulating circuit services over MPLS. Rather than
   redefining the tunnelTable so that PWES can utilize MPLS tunnels, for
   example, entries in this table MUST instead be extended to add
   additional PWES-specific objects. Doing so facilitates a natural
   extension of those objects defined in the existing MIBs in terms of
   management, as well as leveraging existing agent implementations.

   Interfaces implementing a PWES MUST appear as an interface in the
   ifTable.

4.3.  Configuration and Provisioning

   MIB Tables MUST be designed to facilitate configuration and
   provisioning of the PWES.

   The MIB(s) MUST facilitate intra-PSN configuration and monitoring of
   PWES connections.

4.4.  Performance Monitoring

   MIBs MUST collect statistics for performance and fault management.

   MIBs MUST provide a description of how existing counters are used for
   PW emulation and SHOULD not replicate existing MIB counters.

4.5.  Fault Management and Notifications

   Notifications SHOULD be defined where appropriate to notify the
   network operators of any interesting situations, including faults
   detected in the PWES.

Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau    [Page 11]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

   Objects defined to augment existing protocol-specific notifications
   in order to add PWES functionality MUST explain how these
   notifications are to be emitted.

4.6.  Pseudo-Wire Traceroute

   It can be desirable to know the exact path of a PW, especially for
   troubleshooting purpose. A PW emulation service MUST support PW
   traceroute.

5.  Faithfulness of Emulated Services

   An emulated service SHOULD be as similar to the native service as
   possible, but it is not REQUIRED that they should be identical. The
   applicability statement of a PWE3 service MUST report any limitations
   of the emulated service.  All limitations between an emulated service
   and the corresponding native service can be classified as either
   functional or non-functional.  Functional limitations are those that
   cause some features of the native service to become disabled in the
   emulated one. For example, if an emulated Ethernet service introduces
   some difference that can cause the Spanning Tree Protocol (STP) to
   malfunction, such a difference will be classified as a functional
   difference.  Other differences are non-functional.  For examples,
   differences in service quality between an emulated service and the
   native one are non-functional.

   Some basic requirements on faithfulness of an emulated service are
   described below.

5.1.  Characteristics of an Emulated Service

   Functionally, two CEs that are connected by an emulated service
   SHOULD appear directly connected by a native service, although
   service quality of the emulated service may be different from that of
   a native one. Specifically, the following requirements MUST be met:

   1) It MUST be possible to define type (e.g. Ethernet, which is
      inherited from the native service), speed (e.g. 100Mbps), and MTU
      size for an emulated service, if it is possible to do so for a
      native service.

   2) The two endpoints of emulated service #1 and the two endpoints of
      emulated service #2 may be connected to the same PE at each end,
      respectively. As a result, the PWs of these two emulated services
      may share the same physical paths between the two PEs.  But from
      the CEs' perspective, each emulated service MUST appear as
      unshared, that is, a CE MUST NOT be aware of existence of other
      CEs or other emulated services.

Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau    [Page 12]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

   3) If an emulated service fails (either at one of the PWESs or in the
      middle of the PW), both CEs MUST be notified in a timely manner,
      if they will be notified in the native service.  The definition of
      "timeliness" is service-dependent.

   4) If a routing protocol (e.g. IGP) adjacency can be established over
      a native service, it MUST be possible to be established over an
      emulated service as well. Spanning Tree Protocol (STP) is not
      considered as a routing protocol and requirements on support/non-
      support of STP is outside scope of this document.

   5) The TTL fields of the PW PDUs, if exist, MUST not be changed
      inside an emulated service.

5.2.  Service Quality of Emulated Services

   It is RECOMMENDED but not REQUIRED that an emulated service provide
   as high service quality as the native service.  However, the PWE3 WG
   only defines mechanisms for providing PW emulation, not the services
   themselves. What quality to provide for a specific emulated service
   is a matter between a service provider (SP) and its customers, and is
   outside scope of the PWE3 WG. In fact, different SPs can use the same
   PWE3 approach with different QoS mechanisms to provide the same
   emulated service with different service quality.

6.  Scalability

   Scalability requirements for PWE3 are described below.

   - Only PEs should be aware of existence of PWs and PWE3 services.
     Core network devices SHOULD NOT be exposed to a large number of
     PWs.

     PWs can be path-oriented or non-path-oriented. For path-oriented
     PWs, core network devices must maintain state information for them.
     If a large number of path-oriented PWs are used, core network
     devices will have to maintain a large amount of state information.
     In order to avoid scalability problem, PSN tunnels between PEs can
     be introduced. PWs from the same ingress to the same egress are
     nested inside the PSN tunnel that is from that ingress to that
     egress. By creating such a tunnel hierarchy, individual PWs are
     transparent to the core devices.  If a specific PWE3 approach uses
     path-oriented PWs, PSN tunnels SHOULD be used to improve
     scalability.  However, a PSN tunnel is not part of any PW.
     Signaling of PSN tunnels NEED NOT be defined in the PWE3 approach
     itself. As an example, if LSPs are used as PWs in a PWE3 approach,
     they can be nested inside a tunnel LSP from the PW ingress to the
     PW egress.  The tunnel LSPs can be signaled by any mechanism
     defined in [MPLS].

Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau    [Page 13]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

   - Circuit multiplexing: circuit multiplexing SHOULD be supported (see
     Section 2.1.3).

   - Collective status notification: collective status notification
     SHOULD be supported.

7.  Other Generic Requirements

7.1.  RFC 2914 Conformance

   [RFC2914] describes the need for congestion control in the Internet,
   and discusses what constitute correct congestion control. Any PWE3
   approach MUST conform to RFC 2914 and be TCP-friendly in its response
   to congestion. The applicability document of a PWE3 approach MUST
   provide a statement on RFC 2914 conformance.

8.  Non-Requirements

   Some non-requirements are mentioned in various sections of this
   document. Those work items are outside scope of the PWE3 WG.  The
   non-requirements are listed below:

   - Service interworking;

   - Selection of a particular type of PWs;

   - Striving to make the emulated services perfectly match their native
     services;

   - Defining mechanisms for signaling the PSN tunnels;

   - Defining how to perform traffic management on packets that carry PW
     PDUs;

   - Providing security for the PW PDUs;

   - Providing any multicast service that is not native to the emulated
     medium.

     To illustrate this point, Ethernet transmission to a multicast
     IEEE-48 address is considered in scope, while multicast services
     like [MARS] that are implemented on top of the medium are out of
     scope;




Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau    [Page 14]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

9.  Quality of Service (QoS) Considerations

   In this document, QoS means satisfactory service quality.  It should
   not be confused with QoS mechanisms such as Weighted Fair Queuing
   (WFQ) or Random Early Detection (RED).

   QoS is essential for ensuring that the emulated services are similar
   (but not necessarily identical) to their native forms. It is up to
   network operators to decide how to provide QoS - They can choose to
   rely on over-provisioning and/or deploy some QoS mechanisms.

   In order to take advantage of QoS mechanisms defined in other working
   groups, e.g. the traffic management schemes defined in DiffServ WG,
   it is desirable that some mechanisms exists for differentiating the
   packets resulted from PDU encapsulation. These mechanisms NEED NOT be
   defined in the PWE3 approaches themselves. For example, if the
   packets are MPLS or IP packets, their EXP or DSCP fields can be used
   for marking and differentiating.  A PWE3 approach MAY provide
   guidelines for marking and differentiating, e.g. what fields in the
   original L2 or L1 headers should be used for determining the EXP/DSCP
   value. But the exact procedure of how to perform marking and
   differentiating, e.g. specifying the mapping function from Ethernet
   .1P field to EXP field, is out of scope.

10.  Inter-domain Pseudo-Wires

   The PWE3 WG will determine the requirements for having a PW pass
   across an administrative boundary.  An edge could be a native hand-
   off or hand-off to a further PW.  The working group may analyze
   requirements for both security and performance for the inter-
   administration technology. This topic is for further study.

11.  Security Considerations

11.1.  Security Considerations for Signaling/Control Channels

   If signaling/control channels are used in a PWE3 approach, some
   security mechanism MUST be provided to ensure integrity of the
   information transmitted across the signaling/control channels.

11.2.   Security Considerations for PW PDUs

   Providing security for PW PDUs is outside scope of the PWE3 WG.

11.3.   Security Considerations for Use of Non-path-oriented PWs

   If Non-path-oriented PWs are used, some security mechanism MUST be
   provided to ensure that packets received at an egress PE are indeed

Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau    [Page 15]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

   sent from the corresponding ingress PE.

12.  Deployment Considerations

   Transition from using separate networks for TDM, ATM, Frame Relay and
   IP services to using a single network for multiple services requires
   careful planning and execution.  This is an important topic for
   further study.

13.  Acknowledgments

   Some requirements specified in this document were originally
   articulated in a number of documents including [MARTINI1],
   [MARTINI2], [CES], and [SFBS].  The authors would like to acknowledge
   authors of those documents. The authors would also like to
   acknowledge the input and comments from Eric Rosen, Tricci So and Ron
   Cohen.

14.  References

[CES]       A. Malis et al, "SONET/SDH Circuit Emulation Service Over
            MPLS (CEM) Encapsulation" <draft-malis-sonet-ces-mpls-
            05.txt>, work in progress, July 2001.

[IFMIB]     K. McCloghrie, and F. Kastenholtz, "The Interfaces Group MIB
            using SMIv2", RFC 2233, Nov. 1997.

[L2TPv3]    J. Lau, M. Townsley, A. Valencia, G. Zorn, I. Goyret, G.
            Pall, A. Rubens, B. Palter, "Layer Two Tunneling Protocol
            (L2TP)", <draft-ietf-l2tpext-l2tp-base-01.txt>, work in
            progress, Oct. 2001.

[LSPPING]   P. Pan, N. Sheth, and D. Cooper, G. Swallow, S. Wadhwa, R.
            Bonica, "Detecting Data Plane Liveliness in RSVP-TE",
            <draft-pan-lsp-ping-02.txt>, work in progress, Nov. 2001.

[MARS]      G. Armitage, "Support for Multicast over UNI 3.0/3.1 based
            ATM Networks", RFC2022, November 1996

[MARTINI1]  L. Martini et al, "Transport of Layer 2 Frames Over MPLS",
            <draft-martini-l2circuit-trans-MPLS-07.txt>, work in
            progress, July 2001.

[MARTINI2]  L. Martini et al, "Encapsulation Methods for Transport of
            Layer 2 Frames Over MPLS", <draft-martini-l2circuit-encap-
            MPLS-03.txt>, work in progress, July 2001.


Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau    [Page 16]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

[MPLS]      E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol
            Label Switching Architecture", RFC3031, January 2001

[MPLSOAM]   N. Harrison, P. Willis, S. Davari, et. al., "Requirements
            for OAM in MPLS Networks", <draft-harrison-mpls-oam-req-
            00.txt>, work in progress, May 2001.

[TEMIB]     C. Srinivasan, A. Viswanathan, and T. Nadeau, "MPLS Traffic
            Engineering Management Information Base Using SMIv2",
            <draft-ietf-mpls-te-mib-05.txt>, work in progress, November
            2000.

[PATE]      P. Pate, X. Xiao, T. So, C. White, and K. Kompella, A.
            Malis, T. Johnson, T. Nadeau, "Framework for Pseudo-Wire
            Emulation Edge-to-Edge (PWE3)", <draft-pate-pwe3-framework-
            02.txt>, work in progress, Sept. 2001.

[RFC2914]   S.Floyd, "Congestion Control Principles", RFC 2914, Sept.
            2000.

[RTP]       H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson,
            "RTP: A Transport Protocol for Real-Time Applications",
            RFC1889, January 1996.

[SFBS]      B. St-Denis, D. Fedyk, A. Bhatnagar, A. Siddiqui, R.
            Hartani, and T. So, "Multi-service over MPLS", <draft-
            stdenis-ms-over-mpls-00.txt>, work in progress, Nov. 2000.

[SMIV2]     J. Case, K. McCloghrie, M. Rose, and S. Waldbusser,
            "Structure of Management Information for Version 2 of the
            Simple Network Management Protocol (SNMPv2)", RFC 1902,
            January 1996.


15.  Authors' Addresses

   XiPeng Xiao
   Photuris, Inc.
   2025 Stierlin Court
   Mountain View, CA 94043
   Email: xxiao@photuris.com

   Danny McPherson
   Amber Networks, Inc.
   48664 Milmont Drive
   Fremont, CA 94538
   Email: danny@ambernetworks.com


Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau    [Page 17]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

   Prayson Pate
   Overture Networks
   P. O. Box 14864
   RTP, NC, USA 27709
   Email: prayson.pate@overturenetworks.com

   Craig White
   Level 3 Communications, LLC.
   1025 Eldorado Blvd.
   Broomfield, CO, 80021
   e-mail: Craig.White@Level3.com

   Kireeti Kompella
   Juniper Networks, Inc.
   1194 N. Mathilda Ave.
   Sunnyvale, CA 94089
   Email: kireeti@juniper.net

   Vijay Gill
   Metromedia Fiber Network Inc.
   8075 Leesburg Pike, Suite 300
   Vienna, VA  22182
   Email: vgill@mfnx.net

   Thomas D. Nadeau
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA 01824
   Email: tnadeau@cisco.com























Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau    [Page 18]


Internet Draft      draft-ietf-pwe3-requirements-02            Nov. 2001

16.  Full Copyright Section

Copyright (C) The Internet Society (2000). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Expires 5/02 Xiao/McPherson/Pate/White/Kompella/Gill/Nadeau    [Page 19]