doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc5254.txt b/doc/rfc/rfc5254.txt
new file mode 100644
index 0000000..d4f68c8
--- /dev/null
+++ b/doc/rfc/rfc5254.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group                                      N. Bitar, Ed.
+Request for Comments: 5254                                       Verizon
+Category: Informational                                    M. Bocci, Ed.
+                                                          Alcatel-Lucent
+                                                         L. Martini, Ed.
+                                                     Cisco Systems, Inc.
+                                                            October 2008
+
+
+Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Abstract
+
+   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
+   autonomous systems under the administrative control of two or more
+   service providers, or administratively established pseudowire
+   domains.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bitar, et al.                Informational                      [Page 1]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Scope ......................................................3
+      1.2. Architecture ...............................................3
+   2. Terminology .....................................................6
+      2.1. Specification of Requirements ..............................6
+   3. Use Cases .......................................................7
+      3.1. Multi-Segment Pseudowire Setup Mechanisms ..................9
+   4. Multi-Segment Pseudowire Requirements ..........................10
+      4.1. All Mechanisms ............................................10
+           4.1.1. Architecture .......................................10
+           4.1.2. Resiliency .........................................11
+           4.1.3. Quality of Service .................................11
+           4.1.4. Congestion Control .................................12
+           4.1.5  Generic Requirements for MS-PW Setup Mechanisms ....13
+           4.1.6. Routing ............................................14
+      4.2. Statically Configured MS-PWs ..............................15
+           4.2.1. Architecture .......................................15
+           4.2.2. MPLS-PWs ...........................................15
+           4.2.3. Resiliency .........................................15
+           4.2.4. Quality of Service .................................16
+      4.3. Signaled PW Segments ......................................16
+           4.3.1. Architecture .......................................16
+           4.3.2. Resiliency .........................................16
+           4.3.3. Quality of Service .................................17
+           4.3.4. Routing ............................................17
+           4.3.5. Additional Requirements on Signaled MS-PW Setup
+                  Mechanisms .........................................17
+      4.4. Signaled PW / Dynamic Route ...............................18
+           4.4.1. Architecture .......................................18
+           4.4.2. Resiliency .........................................18
+           4.4.3. Quality of Service .................................18
+           4.4.4. Routing ............................................18
+   5. Operations and Maintenance (OAM) ...............................19
+   6. Management of Multi-Segment Pseudowires ........................20
+      6.1. MIB Requirements ..........................................20
+      6.2. Management Interface Requirements .........................21
+   7. Security Considerations ........................................21
+      7.1. Inter-Provider MS-PWs .....................................21
+           7.1.1. Data-Plane Security Requirements ...................21
+           7.1.2. Control-Plane Security Requirements ................23
+      7.2. Intra-Provider MS-PWs .....................................25
+   8. Acknowledgments ................................................25
+   9. References .....................................................25
+      9.1. Normative References ......................................25
+      9.2. Informative References ....................................25
+
+
+
+
+Bitar, et al.                Informational                      [Page 2]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+1.  Introduction
+
+1.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-PWs).  Requirements for single-segment pseudowires
+   (SS-PWs) 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.
+
+1.2.  Architecture
+
+   The following three figures describe the reference models that are
+   derived from [RFC3985] to support PW emulated services.
+
+         |<-------------- 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
+
+
+
+
+
+
+
+
+Bitar, et al.                Informational                      [Page 3]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+   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.
+
+         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 PSN2.
+
+   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-PE1 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.
+
+
+
+
+
+
+Bitar, et al.                Informational                      [Page 4]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+   An S-PE switches an 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.
+
+                |<------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-PEs 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).  An 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 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 Provider 2).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bitar, et al.                Informational                      [Page 5]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+2.  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 an MS-PW.  This incorporates the functionality of a
+         PE as defined in RFC 3985.
+
+      -  Single-Segment Pseudowire (SS-PW).  A PW setup directly between
+         two PE devices.  Each direction of an 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
+         an MS-PW by definition MUST terminate on a T-PE.
+
+      -  PW Segment.  A single-segment or a part of a 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 an 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 an 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 set up
+         and manage PW segments with other PW switching points and
+         terminating PEs.
+
+2.1.  Specification of Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bitar, et al.                Informational                      [Page 6]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+3.  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 set up 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, an 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
+          technologies.
+
+    -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.  An 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
+          an SS-PW.  An MS-PW with the appropriate interworking
+          performed at the PW switching points can enable PW
+          connectivity between the terminating PEs in this scenario.
+
+
+
+
+
+
+
+
+Bitar, et al.                Informational                      [Page 7]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+      -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 networks: 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 (Time
+          Division Multiplexed (TDM), Synchronous Optical
+          Network/Synchronous Digital Hierarchy (SONET/SDH), or Frame
+          Relay/Asynchronous Transfer Mode (ATM)), Ethernet, or IP
+          based.
+
+          Due to these architectures, circuits (e.g., Ethernet Virtual
+          Circuits (EVCs), 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.
+
+
+
+Bitar, et al.                Informational                      [Page 8]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+          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 set up 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.  An MS-PW may be set up from one access network
+          element to 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.
+
+3.1.  Multi-Segment Pseudowire Setup 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
+          segment.
+
+     -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
+          protocols.
+
+   Note that we define the PW route to be the set of S-PEs through which
+   an 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.
+
+
+
+Bitar, et al.                Informational                      [Page 9]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+4.  Multi-Segment Pseudowire Requirements
+
+   The following sections detail the requirements that the above use
+   cases put on the MS-PW setup mechanisms.
+
+4.1.  All Mechanisms
+
+   The following generic requirements apply to the three MS-PW setup
+   mechanisms defined in the previous section.
+
+4.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.
+
+     -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
+          them.
+
+    -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. An 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
+          S-PE/T-PE.
+
+    -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.
+
+
+
+
+
+
+
+
+Bitar, et al.                Informational                     [Page 10]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+4.1.2.  Resiliency
+
+   Mechanisms to protect an MS-PW when an element on the existing path
+   of an MS-PW fails MUST be provided.  These mechanisms will depend on
+   the MS-PW setup.  The 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.
+
+    -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
+          provided.
+
+      -v. A mechanism to automatically revert to a primary PW from a
+          backup PW MAY be provided.  When provided, it MUST be
+          configurable.
+
+4.1.3.  Quality of Service
+
+   Pseudowires are intended to support emulated services (e.g., TDM and
+   ATM) that may have strict per-connection quality-of-service (QoS)
+   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
+
+
+
+Bitar, et al.                Informational                     [Page 11]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+   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 CoS.
+
+   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-PEs at administrative domain boundaries to translate from one CoS
+   value to another as a PW PDU crosses from one domain to the next.
+
+   [RFC3985] requires PWs to respond to path congestion by reducing
+   their transmission rate.  Alternatively, RFC 3985 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.  RFC 3985
+   applied to MS-PWs consequently requires that MS-PWs employ a
+   congestion control mechanism that is effective across an 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.
+
+4.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
+   document.
+
+
+
+
+Bitar, et al.                Informational                     [Page 12]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+   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 an 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 congestion along the path of one of its PWs could be to re-route
+   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 set up 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.
+
+4.1.5.  Additional Generic Requirements for MS-PW Setup Mechanisms
+
+   The MS-PW setup mechanisms MUST accommodate the 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 set up across autonomous
+   systems in different administrative domains.  The following are
+   generic requirements that apply to the three MS-PW setup mechanisms
+   defined earlier:
+
+      -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 an 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 set up an MS-PW.
+
+
+
+Bitar, et al.                Informational                     [Page 13]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+    -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 an MS-PW will be set up 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 an MS-PW setup on T-PEs can be interpreted
+          as successful only when all PW segments are successfully set
+          up.
+
+    -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 set up, the PW MUST
+          fail to set up.
+
+     -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 set
+          up 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.
+
+4.1.6.  Routing
+
+   An objective of MS-PWs is to provide support for the following
+   connectivity:
+
+      -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.
+
+
+
+
+
+Bitar, et al.                Informational                     [Page 14]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+    -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.
+
+4.2.  Statically Configured MS-PWs
+
+   When the MS-PW segments are statically configured, the following
+   requirements apply in addition to the generic requirements previously
+   defined.
+
+4.2.1.  Architecture
+
+   There are no additional requirements on the architecture.
+
+4.2.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 an
+   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 Operations and
+   Maintenance (OAM) capabilities that relay PW or attachment circuit
+   defect notifications between the adjacent S-PEs.
+
+4.2.3.  Resiliency
+
+   The solution should allow for the protection of a PW segment, a
+   contiguous set of PW segments, as well as the end-to-end path.  The
+   primary and protection segments must share the same segment
+   endpoints.  Solutions should allow for having the backup paths set up
+   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
+   set up or the holding priorities of existing PWs.
+
+   Solutions should strive to minimize traffic loss between T-PEs.
+
+
+
+
+
+
+Bitar, et al.                Informational                     [Page 15]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+4.2.4.  Quality of Service
+
+   The CoS and bandwidth of the MS-PW must be configurable at T-PEs and
+   S-PEs.
+
+4.3.  Signaled PW Segments
+
+   When the MS-PW segments are dynamically signaled, the following
+   requirements apply in addition to the generic requirements previously
+   defined.  The 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 mechanisms that are defined to setup SS-PWs:
+
+      -i. Static set up of the SS-PW (MPLS or L2TPv3 forwarding)
+
+     -ii. LDP using PWid Forwarding Equivalence Class (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 are 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.
+
+4.3.1.  Architecture
+
+   There are no additional requirements on the architecture.
+
+4.3.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 set up 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.                Informational                     [Page 16]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+   should be given preference when compared with the setup priorities of
+   other PWs being set up or the holding priorities of existing PWs.
+   Procedures must allow for the primary and backup paths to be diverse.
+
+4.3.3.  Quality of Service
+
+   When the T-PE attempts to signal an MS-PW, the following capability
+   is required:
+
+      -i. Signaling must be able to identify the CoS associated with an
+          MS-PW.
+
+     -ii. Signaling must be able to carry the traffic parameters for an
+          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 PWs.
+
+4.3.4.  Routing
+
+   See the requirements for "Resiliency" above.
+
+4.3.5.  Additional Requirements on Signaled MS-PW Setup Mechanisms
+
+   The following are further requirements on signaled MS-PW setup
+   mechanisms:
+
+      -i. The signaling procedures MUST be defined such that the setup
+          of an MS-PW is considered successful if all segments of the
+          MS-PW are successfully set up.
+
+     -ii. The MS-PW path MUST have the ability to be dynamically set up
+          between the T-PEs by provisioning only the T-PEs.
+
+
+
+
+
+
+
+
+
+Bitar, et al.                Informational                     [Page 17]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+    -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 an MS-PW is set up 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 set up of MS-PWs
+          under these conditions.
+
+4.4.  Signaled PW / Dynamic Route
+
+   The following requirements apply, in addition to those in Sections
+   4.1 and 4.3, when both dynamic signaling and dynamic routing are
+   used.
+
+4.4.1.  Architecture
+
+   There are no additional architectural requirements.
+
+4.4.2.  Resiliency
+
+   The PW routing function MUST support dynamic re-routing around
+   failure points when segments are set up using the dynamic setup
+   method.
+
+4.4.3.  Quality of Service
+
+   There are no additional QoS requirements.
+
+4.4.4.  Routing
+
+   The following are requirements associated with dynamic route
+   selection for an MS-PW:
+
+      -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.
+
+
+
+Bitar, et al.                Informational                     [Page 18]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+    -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.
+
+5.  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 circuit.  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:
+
+      -i. Mechanisms for PW segment failure detection and notification
+          to other segments of an 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., [RFC5085]) SHOULD be extended to
+          support MS-PWs on both an end-to-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.
+
+
+
+
+Bitar, et al.                Informational                     [Page 19]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+     -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
+          transparently.
+
+      -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.
+
+6.  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:
+
+6.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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bitar, et al.                Informational                     [Page 20]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+6.2.  Management Interface Requirements
+
+      -i. Mechanisms MUST be provided to enable remote management of an
+          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 an MS-PW.
+
+7.  Security Considerations
+
+   This document specifies the requirements both for MS-PWs that can be
+   set up across domain boundaries administered by one or more service
+   providers (inter-provider MS-PWs), and for MS-PWs that are only set
+   up across one provider (intra-provider MS-PWs).
+
+7.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 inter-provider 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
+   inter-provider operation of MS-PWs in both the control plane and data
+   plane, and some of these requirements may overlap with those in
+   [RFC4111].
+
+7.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 to
+          which the PW is not intended to be connected, 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
+
+
+
+Bitar, et al.                Informational                     [Page 21]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+   chance that one or more PDUs could be falsely inserted into an 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:
+
+      -i. 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
+
+     -ii. 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 neighbor).
+
+   One of the domains crossed by an MS-PW may decide to selectively
+   mirror the PDUs of an MS-PW for eavesdropping purposes.  It may also
+   decide to selectively hijack the PDUs of an MS-PW by directing the
+   PDUs away from their destination.  In either case, the privacy of an
+   MS-PW can be violated.
+
+   Some types of PWs make assumptions about the security of the
+   underlying PSN.  The minimal security provided by an MPLS PSN might
+   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 an 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 an 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.
+
+
+
+
+
+
+Bitar, et al.                Informational                     [Page 22]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+   An ingress S-PE MUST ensure that an MS-PW receives 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
+   Differentiated Services (DS) field (depending on the PSN) for a
+   better CoS than they should receive.
+
+   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 arrived.
+
+   Data plane security considerations for SS-PWs specified in [RFC3985]
+   also apply to MS-PWs.
+
+7.1.2.  Control-Plane Security Requirements
+
+   An 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 an MS-PW signaling message or packet from an untrusted
+   peer.  Other configurations are possible.  For example, P routers for
+   the PSN 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
+   message 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
+
+
+
+Bitar, et al.                Informational                     [Page 23]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+   be sufficient.  If deployment situations arise that require large
+   scale connection 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 an
+   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 control 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.
+
+   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
+   Denial-of-Service (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.  Thus, 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.
+
+
+
+
+
+
+
+
+Bitar, et al.                Informational                     [Page 24]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+   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.
+
+7.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 provider 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 provider
+   network, the data path security requirements for inter-provider
+   MS-PWs also apply to intra-provider MS-PWs in such cases.
+
+8.  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 McDysan (Verizon), Rahul Aggarwal (Juniper), Du Ke (ZTE),
+   Cagatay Buyukkoc (ZTE), and Stewart Bryant (Cisco).
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3916]  Xiao, X., Ed., McPherson, D., Ed., and P. Pate, Ed.,
+              "Requirements for Pseudo-Wire Emulation Edge-to-Edge
+              (PWE3)", RFC 3916, September 2004.
+
+   [RFC3985]  Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation
+              Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
+
+9.2.  Informative References
+
+   [i610]     Recommendation I.610 "B-ISDN operation and maintenance
+              principles and functions", February 1999.
+
+
+
+
+
+Bitar, et al.                Informational                     [Page 25]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+   [RFC5085]  Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
+              Virtual Circuit Connectivity Verification (VCCV): A
+              Control Channel for Pseudowires", RFC 5085, December 2007.
+
+   [RFC4447]  Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
+              G. Heron, "Pseudowire Setup and Maintenance Using the
+              Label Distribution Protocol (LDP)", RFC 4447, April 2006.
+
+   [RFC4111]  Fang, L., Ed., "Security Framework for Provider-
+              Provisioned Virtual Private Networks (PPVPNs)", RFC 4111,
+              July 2005.
+
+   [PWE3-OAM] Nadeau, T., Ed., Morrow, M., Ed., Busschbach, P., Ed.,
+              Alissaoui, M.,Ed., D. Allen, Ed., "Pseudo Wire (PW) OAM
+              Message Mapping", Work in Progress, March 2005.
+
+   [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41, RFC
+              2914, September 2000.
+
+   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+              Networks (VPNs)", RFC 4364, February 2006.
+
+   [RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
+              Key Management", BCP 107, RFC 4107, June 2005.
+
+Authors' Addresses
+
+   Nabil Bitar
+   Verizon
+   117 West Street
+   Waltham, MA 02145
+   EMail: nabil.n.bitar@verizon.com
+
+
+   Matthew Bocci
+   Alcatel-Lucent Telecom Ltd,
+   Voyager Place
+   Shoppenhangers Road
+   Maidenhead
+   Berks, UK
+   EMail: matthew.bocci@alcatel-lucent.co.uk
+
+
+   Luca Martini
+   Cisco Systems, Inc.
+   9155 East Nichols Avenue, Suite 400
+   Englewood, CO, 80112
+   EMail: lmartini@cisco.com
+
+
+
+Bitar, et al.                Informational                     [Page 26]
+
+RFC 5254          Requirements for Multi-Segment PWE3       October 2008
+
+
+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
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   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
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   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-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Bitar, et al.                Informational                     [Page 27]
+