Skip to main content

Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5254.
Authors Dr. Nabil N. Bitar , Matthew Bocci , Luca Martini
Last updated 2020-01-21 (Latest revision 2008-06-09)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 5254 (Informational)
Action Holders
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Mark Townsley
Send notices to, Dan Romascanu <>
Network Working Group                               Nabil Bitar (Editor)
Internet Draft                                                   Verizon
Intended status: Informational
Expiration Date: December 2007

Luca Martini (Editor)                             Matthew Bocci (Editor)
Cisco Systems Inc.                                        Alcatel-Lucent

                                                               June 2007

Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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

   The list of Internet-Draft Shadow Directories can be accessed at


   This document describes the necessary requirements to allow a service
   provider to extend the reach of pseudowires across multiple domains.
   These domains can be autonomous systems under one provider
   administrative control, IGP areas in one autonomous system, different

Bitar, et al.                                                   [Page 1]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

   autonomous systems under the administrative control of two or more
   service providers, or administratively established pseudowire

Bitar, et al.                                                   [Page 2]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

Table of Contents

    1        Specification of Requirements  ........................   4
    2        Acknowledgments  ......................................   4
    3        Introduction  .........................................   4
    3.1      Scope  ................................................   4
    3.2      Architecture  .........................................   4
    4        Terminology  ..........................................   7
    5        Use Cases  ............................................   8
    5.1      Multi-Segment Pseudowire Placement Mechanisms  ........  11
    6        Multi-Segment Pseudowire Requirements  ................  11
    6.1      All Mechanisms  .......................................  11
    6.1.1    Architecture  .........................................  11
    6.1.2    Resiliency  ...........................................  12
    6.1.3    Quality Of Service  ...................................  13
    6.1.4    Congestion Control  ...................................  14
    6.2      Generic Requirements for MS-PW Setup Mechanisms  ......  15
    6.2.1    Routing  ..............................................  16
    6.3      Statically configured MS-PWs  .........................  16
    6.3.1    Architecture  .........................................  17
    6.3.2    MPLS-PWs  .............................................  17
    6.3.3    Resiliency  ...........................................  17
    6.3.4    Quality of service  ...................................  17
    6.4      Signaled PW-segments  .................................  18
    6.4.1    Architecture  .........................................  18
    6.4.2    Resiliency  ...........................................  18
    6.4.3    Quality of Service  ...................................  19
    6.4.4    Routing  ..............................................  19
    6.5      Signaled PW / Dynamic Route  ..........................  20
    6.5.1    Architecture  .........................................  20
    6.5.2    Resiliency  ...........................................  20
    6.5.3    Quality of Service  ...................................  20
    6.5.4    Routing  ..............................................  20
    7        Operations and Maintenance (OAM)  .....................  21
    8        Management of Multi-Segment Pseudowires  ..............  22
    8.1      MIB Requirements  .....................................  23
    8.2      Management Interface Requirements  ....................  23
    9        Security Considerations  ..............................  23
    9.1      Inter-Provider MS-PWs  ................................  23
    9.1.1    Data-plane Security Requirements  .....................  24
    9.1.2    Control-plane Security Requirements  ..................  25
    9.2      Intra-Provider MS-PWs  ................................  27
   10        Intellectual Property Statement  ......................  27
   11        Full Copyright Statement  .............................  28
   12        IANA Considerations  ..................................  28
   13        Normative References  .................................  28

Bitar, et al.                                                   [Page 3]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

   14        Informative References  ...............................  29
   15        Author Information  ...................................  29

1. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119.

2. Acknowledgments

   The editors gratefully acknowledge the following contributors:
   Dimitri Papadimitriou (Alcatel-Lucent), Peter Busschbach (Alcatel-
   Lucent), Sasha Vainshtein (Axerra), Richard Spencer (British
   Telecom), Simon Delord (France Telecom), Deborah Brungard (AT&T),
   David McDyson (Verizon), Rahul Aggawal (Juniper), Du Ke (ZTE),
   Cagatay Buyukkoc (ZTE) and Stewart Bryant (Cisco).

3. Introduction

3.1. Scope

   This document specifies requirements for extending pseudowires across
   more than one packet switched network (PSN) domain and/or more than
   one PSN tunnel.  These pseudowires are called multi-segment
   pseudowires (MS-PW).  Requirements for single-segment pseudowires
   (SS-PW) that extend edge to edge across only one PSN domain are
   specified in [RFC3916]. This document is not intended to invalidate
   any part of [RFC3985].

   This document specifies additional requirements that apply to MS-PWs.
   These requirements do not apply to PSNs that only support SS-PWs.

3.2. Architecture

   The following three figures describe the reference models which are
   derived from [RFC3985] to support PW emulated services.

Bitar, et al.                                                   [Page 4]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

         |<-------------- Emulated Service ---------------->|
         |                                                  |
         |          |<------- Pseudowire ------->|          |
         |          |                            |          |
         |          |    |<-- PSN Tunnel -->|    |          |
         | PW End   V    V                  V    V  PW End  |
         V Service  +----+                  +----+  Service V
   +-----+    |     | PE1|==================| PE2|     |    +-----+
   |     |----------|............PW1.............|----------|     |
   | CE1 |    |     |    |                  |    |     |    | CE2 |
   |     |----------|............PW2.............|----------|     |
   +-----+  ^ |     |    |==================|    |     | ^  +-----+
         ^  |       +----+                  +----+     | |  ^
         |  |   Provider Edge 1         Provider Edge 2  |  |
         |  |                                            |  |
   Customer |                                            | Customer
   Edge 1   |                                            | Edge 2
            |                                            |
            |                                            |
    Attachment Circuit (AC)                    Attachment Circuit (AC)
      Native service                              Native service

                Figure 1: PWE3 Reference Configuration

   Figure 1 shows the PWE3 reference architecture [RFC3985]. This
   architecture applies to the case where a PSN tunnel extends between
   two edges of a single PSN domain to transport a PW with endpoints at
   these edges.

Bitar, et al.                                                   [Page 5]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

         Native  |<--------Multi-Segment Pseudowire----->|  Native
         Service |         PSN              PSN          |  Service
          (AC)   |     |<-Tunnel->|     |<-Tunnel->|     |  (AC)
           |     V     V     1    V     V     2    V     V   |
           |     +-----+          +-----+          +---- +   |
   +---+   |     |T-PE1|==========|S-PE1|==========|T-PE2|   |    +---+
   |   |---------|........PW1.......... |...PW3..........|---|----|   |
   |CE1|   |     |     |          |     |          |     |   |    |CE2|
   |   |---------|........PW2...........|...PW4..........|--------|   |
   +---+   |     |     |==========|     |==========|     |   |    +---+
       ^         +-----+          +-----+          +-----+        ^
       |     Provider Edge 1         ^        Provider Edge 3     |
       |                             |                            |
       |                             |                            |
       |                     PW switching point                   |
       |                                                          |
       |                                                          |
       |<------------------- Emulated Service ------------------->|

                Figure 2: PW switching Reference Model

   Figure 2 extends this architecture to show a multi-segment case.
   Terminating PE1 (T-PE1) and Terminating PE3 (T-PE3) provide PWE3
   service to CE1 and CE2.  These PEs terminate different PSN tunnels,
   PSN Tunnel 1 and PSN Tunnel 2, and may reside in different PSN or
   pseudowire domains. One PSN tunnel extends from T-PE1 to S-PE1 across
   PSN1, and a second PSN tunnel extends from S-PE1 to T-PE2 across

   PWs are used to connect the Attachment circuits (ACs) attached to T-
   PE1 to the corresponding ACs attached to T-PE2. Each PW on PSN tunnel
   1 is switched to a PW in the tunnel across PSN2 at S-PE2 to complete
   the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 is
   therefore the PW switching point and will be referred to as the PW
   switching provider edge (S-PE). PW1 and PW3 are segments of the same
   MS-PW while PW2 and PW4 are segments of another pseudowire. PW
   segments of the same MS-PW (e.g., PW1 and PW3) MAY be of the same PW
   type or different types, and PSN tunnels (e.g., PSN Tunnel 1 and PSN
   Tunnel 2) can be the same or different technology. This document
   requires support for MS-PWs with segments of the same PW type only.
   An S-PE switches a MS-PW from one segment to another based on the PW
   identifiers (e.g., PW label in case of MPLS PWs). In Figure 2, the
   domains that PSN Tunnel 1 and PSN Tunnel 2 traverse could be IGP
   areas in the same IGP network, or simply PWE3 domains in a single
   flat IGP network for instance.

Bitar, et al.                                                   [Page 6]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

                |<------Multi-Segment Pseudowire------>|
                |         AS                AS         |
            AC  |    |<----1---->|     |<----2--->|    |  AC
            |   V    V           V     V          V    V  |
            |   +----+     +-----+     +----+     +----+  |
   +----+   |   |    |=====|     |=====|    |=====|    |  |    +----+
   |    |-------|.....PW1..........PW2.........PW3.....|-------|    |
   | CE1|   |   |    |     |     |     |    |     |    |  |    |CE2 |
   +----+   |   |    |=====|     |=====|    |=====|    |  |    +----+
        ^       +----+     +-----+     +----+     +----+       ^
        |       T-PE1       S-PE2       S-PE3     T-PE4        |
        |                     ^          ^                     |
        |                     |          |                     |
        |                  PW switching points                 |
        |                                                      |
        |                                                      |
        |<------------------- Emulated Service --------------->|

         Figure 3: PW switching inter provider Reference Model

   Note that although Figure 2 only shows a single S-PE, a PW may
   transit more than one S-PE along its path. For instance, in the
   multi-AS case shown in Figure 3, there can be an S-PE (S-PE2), at the
   border of one AS (AS1) and another S-PE (S-PE3) at the border of the
   other AS (AS2). A MS-PW that extends from the edge of one AS (T-PE1)
   to the edge of the other AS (T-PE4) is composed of three segments:
   (1) PW1, a segment in AS1, (2) PW2, a segment between the two border
   routers (S-PE2 and S-PE3) that are switching PEs, and (3) PWE3, a
   segment in AS2. AS1 and AS2 could be belong to the same provider
   (e.g., AS1 could be an access network or metro transport network, and
   AS2 could be an MPLS core network) or to two different providers
   (e.g., AS1 for Provider 1 and AS2 for Provider2).

4. Terminology

   RFC 3985 [RFC3985] provides terminology for PWE3. The following
   additional terminology is defined for multi-segment pseudowires:

     - PW Terminating Provider Edge (T-PE).  A PE where the customer-
       facing attachment circuits (ACs) are bound to a PW forwarder. A
       Terminating PE is present in the first and last segments of a
       MS-PW. This incorporates the functionality of a PE as defined in
       RFC 3985.

Bitar, et al.                                                   [Page 7]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

     - Single-Segment Pseudowire (SS-PW). A PW setup directly between
       two PE devices. Each direction of a SS-PW traverses one PSN
       tunnel that connects the two PEs.

     - Multi-Segment Pseudowire (MS-PW).  A static or dynamically
       configured set of two or more contiguous PW segments that behave
       and function as a single point-to-point PW. Each end of a MS-PW
       by definition MUST terminate on a T-PE.

     - PW Segment. A part of a single-segment or multi-segment PW, which
       is set up between two PE devices, T-PEs and/or S-PEs.

     - PW Switching Provider Edge (S-PE).  A PE capable of switching the
       control and data planes of the preceding and succeeding PW
       segments in a MS-PW. The S-PE terminates the PSN tunnels
       transporting the preceding and succeeding segments of the MS-PW.
       It is therefore a PW switching point for a MS-PW. A PW Switching
       Point is never the S-PE and the T-PE for the same MS-PW. A PW
       switching point runs necessary protocols to setup and manage PW
       segments with other PW switching points and terminating PEs.

5. Use Cases

   PWE3 defines the signaling and encapsulation techniques for
   establishing SS-PWs between a pair of terminating PEs (T-PEs) and in
   the vast majority of cases this will be sufficient. MS-PWs may be
   useful in the following situations:

        -i. Inter-Provider PWs:  An Inter-Provider PW is a PW that
            extends from a T-PE in one provider domain to a T-PE in
            another provider domain.

       -ii. It may not be possible, desirable or feasible to establish a
            direct PW control channel between the T-PEs, residing in
            different provider networks, to setup and maintain PWs. At a
            minimum, a direct PW control channel establishment (e.g.,
            targeted LDP session) requires knowledge of and reachability
            to the remote T-PE IP address. The local T-PE may not have
            access to this information due to operational or security
            constraints.  Moreover, a SS-PW would require the existence
            of a PSN tunnel between the local T-PE and the remote T-PE.
            It may not be feasible or desirable to extend single,
            contiguous PSN tunnels between T-PEs in one domain and T-PEs
            in another domain for security and/or scalability reasons or
            because the two domains may be using different PSN

Bitar, et al.                                                   [Page 8]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

      -iii. MS-PW setup, maintenance and forwarding procedures must
            satisfy requirements placed by the constraints of a multi-
            provider environment. An example is the inter-AS L2VPN
            scenario where the T-PEs reside in different provider
            networks (ASs) and it is the current practice to MD5-key all
            control traffic exchanged between two networks. A MS-PW
            allows the providers to confine MD5 key administration for
            the LDP session to just the PW switching points connecting
            the two domains.

       -iv. PSN Interworking: PWE3 signaling protocols and PSN types may
            differ in different provider networks. The terminating PEs
            may be connected to networks employing different PW
            signaling and /or PSN protocols. In this case it is not
            possible to use a SS-PW. A MS-PW with the appropriate
            interworking performed at the PW switching points can enable
            PW connectivity between the terminating PEs in this

        -v. Traffic Engineered PSN Tunnels and bandwidth-managed PWs:
            There is a requirement to deploy PWs edge to edge in large
            service provider networks. Such networks typically encompass
            hundreds or thousands of aggregation devices at the edge,
            each of which would be a PE. Furthermore, there is a
            requirement that these PWs have explicit bandwidth
            guarantees. To satisfy these requirements, the PWs will be
            tunneled over PSN TE-tunnels with bandwidth constraints. A
            single segment pseudowire architecture would require that a
            full mesh of PSN TE-tunnels be provisioned to allow PWs to
            be established between all PEs. Inter-provider PWs riding
            traffic engineered tunnels further add to the number of
            tunnels that would have to be supported by the PEs and the
            core network as the total number of PEs increases.

            In this environment, there is a requirement either to
            support a sparse mesh of PSN TE-tunnels and PW signaling
            adjacencies, or to partition the network into a number of
            smaller PWE3 domains. In either case, a PW would have to
            pass through more than one PSN tunnel hop along its path. An
            objective is to reduce the number of tunnels that must be
            supported, and thus the complexity and scalability problem
            that may arise.

       -vi. Pseudowires in access/metro metworks: Service providers wish
            to extend PW technology to access and metro networks in
            order to reduce maintenance complexity and operational
            costs.  Today's access and metro networks are either legacy
            (TDM, SONET/SDH, or Frame Relay/ATM), Ethernet or IP based.

Bitar, et al.                                                   [Page 9]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

            Due to these architectures, circuits (e.g., Ethernet VCs,
            ATM VCs, TDM circuits) in the access/metro are traditionally
            handled as attachment circuits, in their native format, to
            the edge of the IP-MPLS network where the PW starts. This
            combination requires multiple separate access networks and
            complicates end-to-end control, provisioning, and
            maintenance. In addition, when a TDM or SONET/SDH access
            network is replaced with a packet-based infrastructure,
            expenses may be lowered due to moving statistical
            multiplexing closer to the end-user and converging multiple
            services onto a single access network.

            Access networks have a number of properties that impact the
            application of PWs. For example, there exist access
            mechanisms where the PSN is not of an IETF specified type,
            but uses mechanisms compatible with those of PWE3 at the PW
            layer. Here, use case (iv) may apply. In addition, many
            networks consist of hundreds or thousands of access devices.
            There is therefore a desire to support a sparse mesh of PW
            signaling adjacencies and PSN tunnels.  Use case (v) may
            therefore apply. Finally, Access networks also tend to
            differ from core networks in that the access PW setup and
            maintenance mechanism may only be a subset of that used in
            the core.

            Using the MS-PWs, access and metro network elements need
            only maintain PW signaling adjacencies with the PEs to which
            they directly connect. They do not need PW signaling
            adjacencies with every other access and metro network
            device. PEs in the PSN backbone in turn maintain PW
            signaling adjacencies among each other. In addition, a PSN
            tunnel is setup between an access element and the PE to
            which it connects. Another PSN tunnel needs to be
            established between every PE pair in the PSN backbone. A
            MS-PW may be setup from one access network element to
            another another access element with three segments: (1)
            access-element - PSN-PE, (2) PSN-PE to PSN-PE, and (3) PSN-
            PE to access element. In this MS-PW setup, access elements
            are T-PEs while PSN-PEs are S-PEs. It should be noted that
            the PSN backbone can be also segmented into PWE3 domains
            resulting in more segments per PW.

Bitar, et al.                                                  [Page 10]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

5.1. Multi-Segment Pseudowire Placement Mechanisms

   This requirements document assumes that the above use cases are
   realized using one or more of the following mechanisms:

        -i. Static Configuration: The switching points (S-PEs), in
            addition to the T-PEs, are manually provisioned for each

       -ii. Pre-determined Route: The PW is established along an
            administratively determined route using an end-to-end
            signaling protocol with automated stitching at the S-PEs.

      -iii. Signaled Dynamic Route: The PW is established along a
            dynamically determined route using an end-to-end signaling
            protocol with automated stitching at the S-PEs. The route is
            selected with the aid of one or more dynamic routing

   Note that we define the PW route to be the set of S-PEs through which
   a MS-PW will pass between a given pair of T-PEs. PSN tunnels along
   that route can be explicitly specified or locally selected at the S-
   PEs and T-PEs. The routing of the PSN tunnels themselves is outside
   the scope of the requirements specified in this document.

6. Multi-Segment Pseudowire Requirements

   The following sections detail the requirements that the above use
   cases put on the MS-PW setup mechanisms.

6.1. All Mechanisms

   The following generic requirements apply to the three MS-PW setup
   mechanisms defined in the previous section.

6.1.1. Architecture

        -i. If MS-PWs are tunneled, across a PSN that only supports SS-
            PWs, then only the requirements of [RFC3916] apply to that
            PSN. The fact that the overlay is carrying MS-PWs MUST be
            transparent to the routers in the PSN.

Bitar, et al.                                                  [Page 11]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

       -ii. The PWs MUST remain transparent to the P-routers. A P-router
            is not an S-PE or an T-PE from the MS-PW architecture
            viewpoint. P-routers provide transparent PSN transport for
            PWs and MUST not have any knowledge of the PWs traversing

      -iii. The MS-PWs MUST use the same encapsulation modes specified
            for SS-PWs.

       -iv. The MS-PWs MUST be composed of SS-PWs.

        -v. A MS-PW MUST be able to pass across PSNs of all technologies
            supported by PWE3 for SS-PWs. When crossing from one PSN
            technology to another, an S-PE must provide the necessary
            PSN interworking functions in that case.

       -vi. Both directions of a PW segment MUST terminate on the same

      -vii. S-PEs MAY only support switching PWs of the same PW type. In
            this case, the PW type is transparent to the S-PE in the
            forwarding plane, except for functions needed to provide for
            interworking between different PSN technologies.

     -viii. Solutions MAY provide a way to prioritize the setup and
            maintenance process among PWs.

6.1.2. Resiliency

   Mechanisms to protect a MS-PW when an element on the existing path of
   a MS-PW fails MUST be provided. These mechanisms will depend on the
   MS-PW setup. Following are the generic resiliency requirements that
   apply to all MS-PW setup mechanisms:

        -i. Configuration and establishment of a backup PW to a primary
            PW SHOULD be supported. Mechanisms to perform a switchover
            from a primary PW to a backup PW upon failure detection
            SHOULD be provided.

       -ii. The ability to configure an end-to-end backup PW path for a
            primary PW path SHOULD be supported. The primary and backup
            paths may be statically configured, statically specified for
            signaling or dynamically selected via dynamic routing
            depending on the MS-PW establishment mechanism. Backup and
            primary paths should have the ability to traverse separate
            S-PEs. The backup path MAY be signaled at configuration time
            or after failure.

Bitar, et al.                                                  [Page 12]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

      -iii. The ability to configure a primary PW and a backup PW with a
            different T-PE from the primary SHOULD be supported.

       -iv. Automatic Mechanisms to perform a fast switchover from a
            primary PW to a backup PW upon failure detection SHOULD be

        -v. A mechanism to automatically revert to a primary PW from a
            backup PW MAY be provided. When provided, it MUST be

6.1.3. Quality Of Service

   Pseudowires are intended to support emulated services (e.g., TDM and
   ATM) which may have strict per-connection quality of service
   requirements. This may include either absolute or relative guarantees
   on packet loss, delay, and jitter. These guarantees are in part
   delivered by reserving sufficient network resources (e.g. bandwidth),
   and by providing appropriate per-packet treatment (e.g. scheduling
   priority and drop precedence) throughout the network.

   For SS-PWs, a traffic engineered PSN tunnel (i.e., MPLS-TE) may be
   used to ensure that sufficient resources are reserved in the P-
   routers to provide QoS to PWs on the tunnel. In this case, T-PEs MUST
   have the ability to automatically request the PSN tunnel resources in
   the direction of traffic (e.g. admission control of PWs onto the PSN
   tunnel and accounting for reserved bandwidth and available bandwidth
   on the tunnel). In cases where the tunnel supports multiple classes
   of service (CoS) (e.g., E-LSP), bandwidth management is required per

   For MS-PWs, each S-PE maps a PW segment to a PSN tunnel. Solutions
   Must enable S-PEs and T-PEs to automatically bind a PW segment to a
   PSN-tunnel based on CoS and bandwidth requirements when these
   attributes are specified for a PW. Solutions SHOULD also provide the
   capability of binding a PW segment to a tunnel as a matter of policy
   configuration. S-PEs and T-PEs must be capable of automatically
   requesting PSN-tunnel resources per CoS.

   S-PEs and T-PEs MUST be able to associate a CoS marking (e.g., EXP
   field value for MPLS PWs) with PW PDUs. CoS marking in the PW PDUs
   affects packet treatment. The CoS marking depends on the PSN
   technology. Thus, solutions must enable the configuration of
   necessary mapping for CoS marking when the MS-PW crosses from one PSN
   technology to another. Similarly, different administrative domains
   may use different CoS values to imply the same CoS treatment.
   Solutions MUST  provide the ability to define CoS marking maps on S-

Bitar, et al.                                                  [Page 13]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

   PEs at administrative domain boundaries to translate from one CoS
   value to another as a a PW PDU crosses from one domain to the next.

   [RFC3985] requires PWs to respond to path congestion by reducing
   their transmission rate. Alternatively, RFC3985 permits PWs that do
   not have a congestion control mechanism to transmit using explicitly
   reserved capacity along a provisioned path. Because MS-PWs are a type
   of PW, this requirement extends to them as well. RFC3985 applied to
   MS-PWs consequently requires that MS-PWs employ a congestion control
   mechanism that is effective across a MS path, or requires an explicit
   provisioning action that reserves sufficient capacity in all domains
   along the MS path before the MS-PW begins transmission. S-PEs are
   therefore REQUIRED to reject attempts to establish MS-PW segments for
   PW types that either do not utilize an appropriate congestion control
   scheme or when resources that are sufficient to support the
   transmission rate of the PW cannot be reserved along the path.

6.1.4. Congestion Control

   [RFC3985] requires all PWs to respond to congestion, in order to
   conform to [RFC2914]. In the absence of a well-defined congestion
   control mechanism, [RFC3985] permits PWs to be carried across paths
   that have been provisioned such that the traffic caused by PWs has no
   harmful effect on concurrent traffic that shares the path, even under
   congestion. These requirements extend to the MS-PWs defined in this

   Path provisioning is frequently performed through QoS reservation
   protocols or network management protocols. In the case of SS-PWs,
   which remain within a single administrative domain, a number of
   existing protocols can provide this provisioning functionality. MS-
   PWs, however, may transmit across network domains that are under the
   control of multiple entities. QoS provisioning across such paths is
   inherently more difficult, due to the required inter-domain
   interactions. It is important to note that these difficulties do not
   invalidate the requirement to provision path capacity for MS-PW use.
   Each domain MUST individually implement a method to control
   congestion. This can be by QoS reservation, or other congestion
   control method. MS-PWs MUST NOT transmit across unprovisioned, best
   effort, paths in the absence of other congestion control schemes, as
   required by [RFC3985].

   Solutions MUST enable S-PEs and T-PEs on the path of a MS-PW to
   notify other S-PEs and T-PEs on that path of congestion when it
   occurs. Congestion may be indicated by queue length, packet loss
   rate, or bandwidth measurement (among others) crossing a respective
   threshold. The action taken by a T-PE that receives a notification of

Bitar, et al.                                                  [Page 14]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

   congestion along the path of one of its PWs could be to reroute the
   MS-PW to an alternative path, including an alternative T-PE if
   available. If a PE, or an S-PE has knowledge that a particular link
   or tunnel is experiencing congestion , it MUST not setup any new MS-
   PW that utilize that link or tunnel. Some PW types, such as TDM PWs,
   are more sensitive to congestion than others. The reaction to a
   congestion notification MAY vary per PW type.

6.2. Generic Requirements for MS-PW Setup Mechanisms

   The MS-PW setup mechanisms MUST accommodate Service Provider's
   practices, especially in relation to security, confidentiality of SP
   information and traffic engineering. Security and confidentiality are
   especially important when the MS-PWs are setup across Autonomous
   Systems in different administrative domains. Following are generic
   requirements that apply to the three MS-PW setup mechanisms defined

        -i. The ability to statically select S-PEs and PSN tunnels on a
            PW path MUST be provided. Static selection of S-PEs is by
            definition a requirement for the static configuration and
            signaled/static route setup mechanisms. This requirement
            satisfies the need for forcing a MS-PW to traverse specific
            S-PEs to enforce service provider security and
            administrative policies.

       -ii. Solutions SHOULD minimize the amount of configuration needed
            to setup a MS-PW.

      -iii. Solutions should support different PW setup mechanisms on
            the same T-PE, S-PE and PSN network.

       -iv. Solutions MUST allow T-PEs to simultaneously support use of
            SS-PW signaling mechanisms as specified in [RFC4447] as well
            as MS-PW signaling mechanisms.

        -v. Solutions MUST ensure that a MS-PW will be setup when a path
            that satisfies the PW constraints for bandwidth, CoS and
            other possible attributes does exist in the network.

       -vi. Solutions must clearly define the setup procedures for each
            mechanism so that a MS-PW setup on T-PEs can be interpreted
            as successful only when all PW segments are successfully

Bitar, et al.                                                  [Page 15]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

      -vii. Admission control to the PSN tunnel needs to be performed
            against available resources, when applicable. This process
            MUST be performed at each PW segment comprising the MS-PW.
            PW admission control into a PSN tunnel MUST be configurable.

     -viii. In case the PSN tunnel lacks the resources necessary to
            accommodate the new PW, an attempt to signal a new PSN
            tunnel, or increase the capacity of the existing PSN tunnel
            MAY be made. If the expanded PSN tunnel fails to setup the
            PW MUST fail to setup.

       -ix. The setup mechanisms must allow the setup of a PW segment
            between two directly connected S-PEs without the existence
            of a PSN tunnel. This requirement allows a PW segment to be
            setup between two (Autonomous System Border Routers (ASBRs)
            when the MS-PW crosses AS boundaries without the need for
            configuring and setting up a PSN tunnel. In this case,
            admission control must be done, when enabled, on the link
            between the S-PEs.

6.2.1. Routing

   An objective of MS-PWs is to provide support for the following

        -i. MS-PWs MUST be able to traverse multiple Service Provider
            administrative domains.

       -ii. MS-PWs MUST be able to traverse multiple Autonomous Systems
            within the same administrative domain.

      -iii. MS-PWs MUST be able to traverse multiple Autonomous Systems
            belonging to different administrative domains.

       -iv. MS-PWs MUST be able to support any hybrid combination of the
            aforementioned connectivity scenarios, including both PW
            transit, and termination in a domain.

6.3. Statically configured MS-PWs

   When the MS-PW segments are statically configured the following
   requirements apply in addition to the generic requirements previously

Bitar, et al.                                                  [Page 16]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

6.3.1. Architecture

   There are no additional requirements on the architecture.

6.3.2. MPLS-PWs

   Solutions should allow for the static configuration of MPLS labels
   for MPLS-PW segments and the cross-connection of these labels to
   preceding and succeeding segments. This is especially useful when a
   MS-PW crosses provider boundaries and two providers do not want to
   run any PW signaling protocol between them. A T-PE or S-PE that
   allows the configuration of static labels for MS-PW segments should
   also simultaneously allow for dynamic label assignments for other
   MS-PW segments. It should be noted that when two interconnected S-PEs
   do not have signaling peering for the purpose of setting up MS-PW
   segments, they should have in-band PW OAM capabilities that relay PW
   or attachment circuit defect notifications between the adjacent S-

6.3.3. Resiliency

   The solution should allow for the protection of a PW-segment, a
   contiguous set of PW-segments, as well as the end-end path. The
   primary and protection segments paths must share the same segments
   endpoints. Solutions should allow for having the backup paths setup
   prior to the failure or as a result of failure. The choice should be
   made by configuration. When resources are limited and cannot satisfy
   all PWs, the PWs with the higher setup priorities should be given
   preference when compared with the setup priorities of other PWs being
   setup or the holding priorities of existing PWs.

   Solutions should strive to minimize traffic loss between T-PEs.

6.3.4. Quality of service

   The CoS and bandwidth of the MS-PW must be configurable at T-PEs and

Bitar, et al.                                                  [Page 17]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

6.4. Signaled PW-segments

   When the MS-PW segments are dynamically signaled the following
   requirements apply in addition to the generic requirements previously

   These signaled MS-PW segments can be on the path of a statically
   configured MS-PW, signaled/statically routed MS-PW or
   signaled/dynamically routed MS-PW.

   There are four different SS-PW signaling protocols that are defined
   to signal PWs:

        -i. Static setup of the SS-PW (MPLS or L2TPv3 forwarding).

       -ii. LDP using PWid FEC 128

      -iii. LDP using the generalized PW FEC 129

       -iv. L2TPv3

   The MS-PW setup mechanism MUST be able to support PW segments
   signaled with any of the above protocols, however the specification
   of which combinations of SS-PW signaling protocols is supported by a
   specific implementation is outside the scope of this document.

   For the signaled/statically routed and signaled/dynamically routed
   MS-PW setup mechanisms the following requirements apply in addition
   to the generic requirements previously defined.

6.4.1. Architecture

   There are no additional requirements on the architecture.

6.4.2. Resiliency

   Solutions should allow for the signaling of a protection path for a
   PW segment, sequence of segments or end-to-end path. The protection
   and primary paths for the protected segment(s) share the same
   respective segments endpoints. When admission control is enabled,
   systems must be careful not to double account for bandwidth
   allocation at merged points (e.g., tunnels).  Solutions should allow
   for having the backup paths setup prior to the failure or as a result
   of failure. The choice should be made by configuration at the
   endpoints of the protected path. When resources are limited and
   cannot satisfy all PWs, the PWs with the higher setup priorities

Bitar, et al.                                                  [Page 18]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

   should be given preference when compared with the setup priorities of
   other PWs being setup or the holding priorities of existing PWs.
   Procedures must allow for the primary and backup paths to be

6.4.3. Quality of Service

   When the T-PE attempts to signal a MS-PW the following capability is

        -i. Signaling must be able to identify the CoS associated with a
       -ii. Signaling must be able to carry the traffic parameters for a
            MS-PW per CoS.  Traffic parameters should be based on
            existing INTSERV definitions and must be used for admission
            control when admission control is enabled.

      -iii. The PW signaling MUST enable separate traffic parameter
            values to be specified for the forward and reverse
            directions of the PW.

       -iv. PW traffic parameter representations MUST be the same for
            all types of MS-PWs.

        -v. The signaling protocol must be able to accommodate a method
            to prioritize the PW setup and maintenance operation among

6.4.4. Routing

   See the requirements for "Resiliency" above.

   Following are further requirements on signaled MS-PW setup

        -i. The signaling procedures MUST be defined such that the setup
            of a MS-PW is considered successful if all segments of the
            MS-PW are successfully setup.

       -ii. The MS-PW path MUST have the ability to be dynamically setup
            between the T-PEs by provisioning only the T-PEs.

Bitar, et al.                                                  [Page 19]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

      -iii. Dynamic MS-PW setup requires that a unique identifier be
            associated with a PW and be carried in the signaling
            message. That identifier must contain sufficient information
            to determine the path to the remote T-PE through
            intermediate S-PEs.

       -iv. In a single-provider domain it is natural to have the T-PE
            identified by one of its IP addresses. This may also apply
            when a MS-PW is setup across multiple domains operated by
            the same provider. However, some service providers have
            security and confidentiality policies that prevent them from
            advertising reachability to routers in their networks to
            other providers (reachability to an ASBR is an exception).
            Thus, procedures MUST be provided to allow dynamic setup of
            MS-PWs under these conditions.

6.5. Signaled PW / Dynamic Route

   The following requirements apply, in addition to those in Section 6.1
   and Section 6.2, when both dynamic signaling and dynamic routing are

6.5.1. Architecture

   There are no additional architectural requirements.

6.5.2. Resiliency

   The PW Routing function MUST support dynamic re-routing around
   failure points when segments are setup using the dynamic setup

6.5.3. Quality of Service

   There are no additional QoS requirements.

6.5.4. Routing

   Following are requirements associated with dynamic route selection
   for a MS-PW:

Bitar, et al.                                                  [Page 20]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

        -i. Routing must enable S-PEs and T-PEs to discover S-PEs on the
            path to a destination T-PE.

       -ii. The MS-PW routing function MUST have the ability to
            automatically select the S-PEs along the MS-PW path. Some of
            the S-PEs MAY be statically selected and carried in the
            signaling to constrain the route selection process.

      -iii. The PW Routing function MUST support re-routing around
            failures that occur between the statically configured
            segment endpoints. This may be done by choosing another PSN
            tunnel between the two segment endpoints or setting up an
            alternative tunnel.

       -iv. Routing protocols must be able to advertise reachability
            information of attachment circuit (AC) endpoints. This
            reachability information must be consistent with the AC
            identifiers carried in signaling.

7. Operations and Maintenance (OAM)

   OAM mechanisms for the attachment circuits are defined in the
   specifications for PW emulated specific technologies (e.g., ITU-T
   I.610 [i610] for ATM).  These mechanisms enable, among other things,
   defects in the network to be detected, localized and diagnosed. They
   also enable communication of PW defect states on the PW attachment

   Note that this document uses the term OAM as Operations and
   Management as per ITU-T I.610.

   The interworking of OAM mechanisms for SS-PWs between ACs and PWs is
   defined in [PWE3-OAM]. These enable defect states to be propagated
   across a PWE3 network following the failure and recovery from faults.

   OAM mechanisms for MS-PWs MUST provide at least the same capabilities
   as those for SS-PWs.

   In addition, it should be possible to support both segment and end-
   to-end OAM mechanisms for both defect notifications and connectivity
   verification in order to allow defects to be localized in a multi-
   segment network. That is, PW OAM segments can be T-PE to T-PE, T-PE
   to S-PE, or S-PE to S-PE.

   The following requirements apply to OAM for MS-PWs:

Bitar, et al.                                                  [Page 21]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

        -i. Mechanisms for PW segment failure detection and notification
            to other segments of a MS-PW MUST be provided.

       -ii. MS-PW OAM SHOULD be supported end-to-end across the network.

      -iii. Single ended monitoring SHOULD be supported for both
            directions of the MS-PW.

       -iv. SS-PW OAM mechanisms (e.g., [VCCV]) SHOULD be extended to
            support MS-PWs on both end-end basis and segment basis.

        -v. All PE routers along the MS-PW MUST agree on a common PW OAM
            mechanism to use for the MS-PW.

       -vi. At the S-PE, defects on an PSN tunnel MUST be propagated to
            all PWs that utilize that particular PSN tunnel.

      -vii. The directionality of defect notifications MUST be
            maintained across the S-PE.

     -viii. The S-PE SHOULD be able to behave as a segment endpoint for
            PW OAM mechanisms.

       -ix. The S-PE MUST be able to pass T-PE to T-PE PW OAM messages

        -x. Performance OAM, is required for both MS-PWs and SS-PWs to
            measure round-trip delay, one-way delay, jitter, and packet
            loss ratio.

8. Management of Multi-Segment Pseudowires

   Each PWE3 approach that uses MS-PWs SHOULD provide some mechanisms
   for network operators to manage the emulated service.  Management
   mechanisms for MS-PWs MUST provide at least the same capabilities as
   those for SS-PWs, as defined in [RFC3916].

   It SHOULD also be possible to manage the additional attributes for
   MS-PWs. Since the operator that initiates the establishment of an
   MS-PW may reside in a different PSN domain from the S-PEs and one of
   the T-PEs along the path of the MS-PW, mechanisms for the remote
   management of the MS-PW SHOULD be provided.

   The following additional requirements apply:

Bitar, et al.                                                  [Page 22]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

8.1. MIB Requirements

        -i. MIB Tables MUST be designed to facilitate configuration and
            provisioning of the MS-PW at the S-PEs and T-PEs.

       -ii. The MIB(s) MUST facilitate inter-PSN configuration and
            monitoring of the ACs.

8.2. Management Interface Requirements

        -i. Mechanisms MUST be provided to enable remote management of a
            MS-PW at an S-PE or T-PE. It SHOULD be possible for these
            mechanisms to operate across PSN domains. An example of a
            commonly available mechanism is the command line interface
            (CLI) over a telnet session.

       -ii. For security or other reasons, it SHOULD be possible to
            disable the remote management of a MS-PW.

9. Security Considerations

   This document specifies the requirements both for MS-PWs that can be
   setup across domain boundaries administered by one or more service
   providers (inter-provider MS-PWs), and for MS-PWs that are only setup
   across one provider (intra-provider MS-PWs).

9.1. Inter-Provider MS-PWs

   The security requirements for MS-PW setup across domains administered
   by one service provider are the same as those described under
   security considerations in [RFC4447] and [RFC3916]. These
   requirements also apply to interprovider MS-PWs.

   In addition, [RFC4111] identifies user and provider requirements for
   L2 VPNs that apply to MS-PWs described in this document. In this
   section, the focus is on the additional security requirements for
   interprovider operation of MS-PWs in both the control plane and data
   plane, and some of these requirements may overlap with those in

Bitar, et al.                                                  [Page 23]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

9.1.1. Data-plane Security Requirements

   By security in the "data plane", we mean protection against the
   following possibilities:

        -i. Packets from within an MS-PW traveling to a PE or an AC that
            the PW is not intended to be connected to, other than in a
            manner consistent with the policies of the MS-PW.

       -ii. Packets from outside an MS-PW entering the MS-PW, other than
            in a manner consistent with the policies of the MS-PW.

   MS-PWs that cross service provider (SP) domain boundaries may connect
   one T-PE in a SP domain to a T-PE in another provider domain. They
   may also transit other provider domains even if the two T-PEs are
   under the control of one SP. Under these scenarios, there is a chance
   that one or more PDUs could be falsely inserted into a MS-PW at any
   of the originating, terminating or transit domains. Such false
   injection can be the result of a malicious attack or fault in the S-
   PE. Solutions MAY provide mechanisms for ensuring the end-to-end
   authenticity of MS-PW PDUs.

   The data plane security requirements at a service provider border for
   MS-PWs are similar to those for inter-provider BGP/MPLS IP Virtual
   Private Networks [RFC4364]. In particular, an S-PE or T-PE SHOULD
   discard a packet received from a particular neighbor over the service
   provider border unless one of the following two conditions holds:

      -iii. any MPLS label processed at the receiving S-PE or T-PE, such
            the PSN tunnel label or the PW label, has a label value that
            the receiving system has distributed to that neighbor, or

       -iv. any MPLS label processed at the receiving S-PE or T-PE, such
            as the PSN tunnel label or the PW label, has a label value
            that the receiving S-PE or T-PE has previously distributed
            to the peer S-PE or T-PE beyond that neighbor (i.e., when it
            is known that the path from the system to which the label
            was distributed to the receiving system is via that

   One of the domains crossed by a MS-PW may decide to selectively
   mirror the PDUs of a MS-PW for eavesdropping purposes. It may also
   decide to selectively hijack the PDUs of a MS-PW by directing the
   PDUs away from their destination. In either case, the privacy of a
   MS-PW can be violated.

   Some types of PWs make assumptions about the security of the
   underling PSN.  The minimal security provided by an MPLS PSN might

Bitar, et al.                                                  [Page 24]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

   not be sufficient to meet the security requirements expected by the
   applications using the MS-PW. This document does not place any
   requirements on protecting the privacy of a MS-PW PDU via encryption.
   However, encryption may be required at a higher layer in the protocol
   stack, based on the application or network requirements.

   The data plane of an S-PE at a domain boundary MUST be able to police
   incoming MS-PW traffic to the MS-PW traffic parameters or to an
   administratively configured profile. The option to enable/disable
   policing MUST be provided to the network administrator. This is to
   ensure that a MS-PW or a group of MS-PWs do not grab more resources
   than they are allocated. In addition, the data plane of an S-PE MUST
   be able to police OAM messages to a pre-configured traffic profile or
   to filter out these messages upon administrative configuration.

   An ingress S-PE MUST ensure that a MS-PW receive the CoS treatment
   configured or signaled for that MS-PW at the S-PE. Specifically, an
   S-PE MUST guard against packets marked in the exp bits or IP-header
   DS field (depending on the PSN) for a better CoS than they should

   An ingress S-PE MUST be able to define per-interface or interface-
   group (a group may correspond to interfaces to a peer-provider) label
   space for MPLS-PWs. An S-PE MUST be configurable not to accept
   labeled packets from another provider unless the bottom label is a
   PW-label assigned by the S-PE on the interface on which the packet

   Data plane security considerations for SS-PWs specified in [RFC3985]
   also apply to MS-PWs.

9.1.2. Control-plane Security Requirements

   A MS-PW connects two attachment circuits. It is important to make
   sure that PW connections are not arbitrarily accepted from anywhere,
   or else a local attachment circuit might get connected to an
   arbitrary remote attachment circuit. The fault in the connection can
   start at a remote T-PE or an S-PE.

   Where a PW segment crosses a border between one provider and another
   provider, the PW segment endpoints (S-PEs) SHOULD be on ASBRs
   interconnecting the two providers. Directly interconnecting the S-PEs
   using a physically secure link, and enabling signaling and routing
   authentication between the S-PEs, eliminates the possibility of
   receiving a MS-PW signaling message or packet from an untrusted peer.
   Other configurations are possible, for example, P routers for the PSN

Bitar, et al.                                                  [Page 25]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

   tunnel between the adjacent S-PEs/T-PEs may reside on the ASBRs. In
   which case, the S-PEs/T-PEs MUST satisfy themselves of the security
   and privacy of the path.

   The configuration and maintenance protocol MUST provide a strong
   authentication and control protocol data protection mechanism. This
   option MUST be implemented, but it should be deployed according to
   the specific PSN environment requirements. Furthermore,
   authentication using a signature for each individual MS-PW setup
   messages MUST be available, in addition to an overall control
   protocol session authentication, and message validation.

   Since S-PEs in different provider networks SHOULD reside at each end
   of a physically secure link, or be interconnected by a limited number
   of trusted PSN tunnels, each S-PE will have a trust relationship with
   only a limited number of S-PEs in other ASs. Thus, it is expected
   that current security mechanisms based on manual key management will
   be sufficient. If deployment situations arise that require large
   scale connection of to S-PEs in other ASs, then a mechanism based on
   RFC 4107 [RFC4107] MUST be developed.

   Peer authentication protects against IP address spoofing but does not
   prevent one peer (S-PE or T-PE) from connecting to the wrong
   attachment circuit. Under a single administrative authority, this may
   be the result of a misconfiguration. When the MS-PW crosses multiple
   provider domains, this may be the result of a malicious act by a
   service provider or a security hole in that provider network. Static
   manual configuration of MS-PWs at S-PEs and T-PEs provides a greater
   degree of security. If an identification of both ends of a MS-PW is
   configured and carried in the signaling message, an S-PE can verify
   the signaling message against the configuration. To support dynamic
   signaling of MS-PWs, whereby only endpoints are provisioned and S-PEs
   are dynamically discovered, mechanisms SHOULD be provided to
   configure such information on a server and to use that information
   during a connection attempt for validation.

   An incoming MS-PW request/reply MUST NOT be accepted unless its IP
   source address is known to be the source of an "eligible" peer. An
   eligible peer is an S-PE or a T-PE with which the originating S-PE or
   T-PE has a trust relationship. The number of such trusted T-PEs or
   S-PEs is bounded and not anticipated to create a scaling issue for
   the contol plane authentication mechanisms.

   If a peering adjacency has to be established prior to exchanging
   setup requests/responses, peering MUST only be done with eligible
   peers. The set of eligible peers could be pre-configured (either as a
   list of IP addresses, or as a list of address/mask combinations) or
   automatically generated from the local PW configuration information.

Bitar, et al.                                                  [Page 26]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

   Furthermore, the restriction of peering sessions to specific
   interfaces MUST also be provided. The S-PE and T-PE MUST drop the
   unaccepted signaling messages in the data path to avoid a DoS attack
   on the control plane.

   Even if a connection request appears to come from an eligible peer,
   its source address may have been spoofed. So some means of preventing
   source address spoofing must be in place. For example, if eligible
   peers are in the same network, source address filtering at the border
   routers of that network could eliminate the possibility of source
   address spoofing.

   S-PEs that connect one provider domain to another provider domain
   MUST have the capability to rate-limit signaling traffic in order to
   prevent DoS attacks on the control plane. Furthermore, detection and
   disposition of malformed packets and defense against various forms of
   attacks that can be protocol-specific MUST be provided.

9.2. Intra-Provider MS-PWs

   Security requirements for pseudowires are provided in [RFC3916].
   These requirements also apply to MS-PWs.

   MS-PWs are intended to enable many more PEs to provide PWE3 services
   in a given service providers network than traditional SS-PWs,
   particularly in access and metro environments where the PE may be
   situated closer to the ultimate endpoint of the service. In order to
   limit the impact of a compromise of one T-PE in a service providers
   network, the data path security requirements for inter-provider MS-
   PWs also apply to intra-provider MS-PWs in such cases.

10. Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this

Bitar, et al.                                                  [Page 27]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-

11. Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

12. IANA Considerations

   This document has no IANA Actions.

13. Normative References

   [RFC3916] "Requirements for Pseudo-Wire Emulation Edge-to-Edge
         (PWE3)", X. Xiao, D. McPherson, P. Pate, September 2004

   [RFC3985] "PWE3 Architecture" Bryant, et al., RFC3985.

Bitar, et al.                                                  [Page 28]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

14. Informative References

   [VCCV] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection
        Verification (VCCV)", Internet Draft
        "draft-ietf-pwe3-vccv-15.txt", September 2007.(work in progress)

   [RFC4447]  L. Martini, Ed, et al., "Pseudowire Setup and
        Maintenance Using the Label Distribution Protocol (LDP)",
        RFC4447, April 2006

   [RFC4111] "Security Framework for
        Provider-Provisioned Virtual Private Networks (PPVPNs),"
        Fang. L., et al., RFC 4111, July 2005

   [PWE3-OAM] "Pseudo Wire (PW) OAM Message Mapping" Nadeau et al.,
        draft-ietf-pwe3-oam-msg-map-02.txt (work in progress),
        February 2005

   [RFC2914] "Congestion Control Principles", S. Floyd,
        September 2000

   [RFC4364] "BGP/MPLS IP Virtual Private Networks (VPNs)",
        E. Rosen et al, February 2006

  [RFC4107] "Guidelines for Cryptographic Key Management",
        S. Belloin et al, June 2005

15. Author Information

   Nabil Bitar
   40 Sylvan Road
   Waltham, MA 02145

   Matthew Bocci
   Alcatel-Lucent Telecom Ltd,
   Voyager Place
   Shoppenhangers Road
   Berks, UK

Bitar, et al.                                                  [Page 29]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-07.txt       June 2007

   Luca Martini
   Cisco Systems, Inc.
   9155 East Nichols Avenue, Suite 400
   Englewood, CO, 80112