Network Working Group Nabil Bitar (Editor)
Internet Draft Verizon
Expiration Date: April 2006
Luca Martini (Editor) Matthew Bocci (Editor)
Cisco Systems Inc. Alcatel
October 2005
Requirements for inter domain Pseudo-Wires
draft-ietf-pwe3-ms-pw-requirements-01.txt
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
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes the necessary requirements to allow a service
provider to extend the reach of pseudo-wires 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
Bitar, et al. [Page 1]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
service providers, or administratively established pseudo-wire
domains.
Bitar, et al. [Page 2]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
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 Pseudo Wire Configurations ............. 10
6 Multi-Segment Pseudo-Wire Requirements ............... 11
6.1 All Configurations ................................... 11
6.1.1 Architecture ......................................... 11
6.1.2 Resiliency ........................................... 12
6.1.3 Quality Of Service ................................... 12
6.2 Generic Requirements for MS-PW Setup Mechanisms ...... 13
6.2.1 Routing .............................................. 14
6.3 Statically configured MS-PWs ......................... 15
6.3.1 Architecture ......................................... 15
6.3.2 MPLS-PWs ............................................. 15
6.3.3 Resiliency ........................................... 15
6.3.4 Quality of service ................................... 15
6.4 Signaled PW-segments ................................. 15
6.4.1 Architecture ......................................... 16
6.4.2 Resiliency ........................................... 16
6.4.3 Quality of Service ................................... 16
6.4.4 Routing .............................................. 17
6.5 Signaled PW / Dynamic Route .......................... 18
6.5.1 Architecture ......................................... 18
6.5.2 Resiliency ........................................... 18
6.5.3 Quality .............................................. 18
6.5.4 Routing .............................................. 18
7 Operations and Maintenance (OAM) ..................... 19
8 Security Considerations .............................. 20
8.1 Data-plane Security Requirements ..................... 20
8.2 Control-plane Security Requirements .................. 21
9 Full Copyright Statement ............................. 22
10 Intellectual Property Statement ...................... 23
11 IANA Considerations .................................. 23
12 Normative References ................................. 23
13 Informative References ............................... 23
14 Author Information ................................... 24
Bitar, et al. [Page 3]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
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 RFC 2119
2. Acknowledgments
The editors gratefully acknowledge the following contributors:
Dimitri Papadimitriou (Alcatel), Peter Busschbach (Lucent), Sasha
Vainshtein (Axerra), Richard Spencer (British Telecom), Simon Delord
(France Telecom), Deborah Brungard (AT&T), David McDyson, Rahul
Aggawal (Juniper), Du Ke (ZTE), Cagatay Buyukkoc (ZTE).
3. Introduction
3.1. Scope
This document specifies requirements for extending pseudo-wires
across more than one packet switched network (PSN) domain and more
than one PSN tunnel. These pseudo-wires are called multi-segment
pseudo-wires (MS-PW). Requirements for single-segment pseudo wires
(SS-PW) that extend edge to edge across only one PSN domain are
specified in [PWE3-REQ].
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 [PWE3-ARCH] to support PW emulated services.
Bitar, et al. [Page 4]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudo Wire ------>| |
| | | |
| | |<-- 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 [PWE3-ARCH]. 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-01.txt October 2005
Native |<-----------Pseudo Wire----------->| Native
Service | | Service
(AC) | |<-PSN1-->| |<--PSN2->| | (AC)
| V V V V V V |
| +----+ +-----+ +----+ |
+----+ | | PE1|=========| PE2 |=========| PE3| | +----+
| |----------|........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. PE1
and PE3 provide PWE3 service to CE1 and CE2. These PEs reside in
different PSN domains, PSN1 and PSN2, respectively. A PSN tunnel
extends from PE1 to PE2 across PSN1, and a second PSN tunnel extends
from PE2 to PE3 across PSN2. PWs are used to connect the Attachment
circuits (ACs) attached to PE1 to the corresponding ACs attached to
PE3. Each PW on the tunnel across PSN1 is stitched to a PW in the
tunnel across PSN2 at PE2 to complete the multi-segment PW (MS-PW)
between PE1 and PE3. PE2 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 pseudo-wire. PW segments of the same MS-PW (e.g., PW1 and
PW3) MAY be of the same PW type or different type, and PSN tunnels
(e.g., PSN1 and PSN2) can be the same or different technology. This
document requires support for MS-PWs with segments of the same type.
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).
Bitar, et al. [Page 6]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
|<--------------Pseudo Wire----------->|
| Provider Provider |
AC | |<----1---->| |<----2--->| | AC
| V V V V V V |
| +----+ +-----+ +----+ +----+ |
+----+ | | |=====| |=====| |=====| | | +----+
| |-------|.....PW1..........PW2.........PW3.....|-------| |
| CE1| | | | | | | | | | | |CE2 |
+----+ | | |=====| |=====| |=====| | | +----+
^ +----+ +-----+ +----+ +----+ ^
| PE1 PE2 PE3 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-provider case shown in Figure 3, there can be an S-PE (PE2), at
the border of one provider domain (Provider1) and another S-PE (PE3)
at the border of the other provider domain (Provider2). A MS-PW that
extends from the edge of one provider (PE1) to the edge of the other
provider (PE4) is composed of three segments: (1) PW1, a segment in
provider1 network, (2) PW2, a segment between the two border routers
(PE2 and PE3) that are S-PEs, and (3) PWE3, a segment in provider2
network.
4. Terminology
RFC 3985 [PWE3-ARCH] provides terminology for PWE3. The following
additional terminology is defined for multi-segment pseudo wires:
- 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-01.txt October 2005
- Single-Segment Pseudo Wire (SS-PW). A PW setup directly between
two T-PE devices. Each direction of a SS-PW traverses one PSN
tunnel that connects the two T-PEs.
- Multi-Segment Pseudo Wire (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
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
for the fact that the two domains may be using different PSN
technologies.
Bitar, et al. [Page 8]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
-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 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 Internetworking: 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
scenario.
-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 pseudo-wire 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. Pseudo-Wires in Access and Metro Networks: Service providers
are looking to extend PWs to access and metro networks. The
prime motive is cost reduction in capital and operation
expenses. For instance, in metro networks, providers are
looking into extending PWs to next generation SONET ADMs
Bitar, et al. [Page 9]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
using MPLS mechanisms. The objective is to achieve
statistical multiplexing of packets closer to the edge of
the network, reducing the recurring costs of SONET circuits
or maximizing the utilization of existing SONET
infrastructure. In access and metro Ethernet networks,
providers are looking to take advantage of MPLS mechanisms
to setup point to point Ethernet virtual circuits with
endpoints in the same or different access/metro networks.
Using the MS-PW solution, 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.
5.1. Multi-Segment Pseudo Wire Configurations
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. Signaled PW / Static Route: The PW is established along a
statically specified route using an end-to-end signaling
protocol with automated stitching at the S-PEs.
-iii. Signaled PW / 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
Bitar, et al. [Page 10]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
that route can be explicitly specified or locally selected at the S-
PEs. The routing of the PSN tunnels themselves is outside the scope
of the requirements specified in this document.
6. Multi-Segment Pseudo-Wire Requirements
The following sections detail the requirements that the above use
cases put on the MS-PW setup mechanisms.
6.1. All Configurations
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 [PWE3-REQ] 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. A MS-PW MUST be able to pass across PSNs of all technologies
specified 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.
-v. MS-PWs are composed of SS-PWs and SS-PWs are bi-directional.
Therefore, both directions of a PW segment MUST terminate on
the same S-PE/T-PE.
-vi. 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.
Bitar, et al. [Page 11]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
6.1.2. Resiliency
Mechanisms to protect an MS-PW when an element 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 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-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 setup method. 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. Automatic Mechanisms to perform a fast switchover from a
primary PW to a backup PW upon failure detection SHOULD be
provided.
-iv. A mechanism to automatically revert to a primary PW from a
backup PW MAY be provided. When provided, it MUST be
configurable.
6.1.3. Quality Of Service
Pseudo-wires 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. BW), 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 manage PSN tunnel resources in the
traffic direction (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
CoS.
Bitar, et al. [Page 12]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
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
managing 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 a PW PDU crosses from one domain to the next.
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 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 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 setup an MS-PW.
-iii. Solutions should support different PW setup mechanisms on
the same T-PE, S-PE and PSN network.
-iv. Solutions MUST support use of SS-PW signaling mechanisms as
specified in [PW-control] as well as MS-PW signaling
mechanisms on T-PEs.
Bitar, et al. [Page 13]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
-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
setup.
-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 (Asks)
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
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.
-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 terminationin a domain.
Bitar, et al. [Page 14]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
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
defined.
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.
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 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
S-PEs.
6.4. Signaled PW-segments
When the MS-PW segments are dynamically signalled the following
requirements apply in addition to the generic requirements previously
defined.
These signaled MS-PW segments can be on the path of a statically
configured MS-PW, signaled/static route MS-PW or signaled/dynamic
Bitar, et al. [Page 15]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
route MS-PW.
The following requirements for dynamically signaled MS-PW segments
apply to a dynamically selected MS-PW path or a statically selected
MS-PW path.
There are four different SS-PW signaling protocols that are defined
to signal PWs:
-i. Static setup of the SS-PW (MPLS or L2TPv3).
-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/static route and signaled/dynamic route 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-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).
6.4.3. Quality of Service
When the T-PE attempts to signal a MS-PW the following capability is
required:
Bitar, et al. [Page 16]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
-i. Signaling must be able to identify the CoS associated with a
MS-PW
-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.
6.4.4. Routing
See the requirements for "Resiliency" above.
Following are further requirements on signaled MS-PW setup
mechanisms:
-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.
-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.
Bitar, et al. [Page 17]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
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
used.
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
method.
6.5.3. Quality
There are no additional QoS requirements.
6.5.4. Routing
Following are requirements associated with dynamic route selection
for a MS-PW:
-i. The MS-PW 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.
-ii. 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.
-iii. Routing protocols must be able to advertise reachability
information to attachment circuit (AC) endpoints. This
reachability information must be consistent with the AC
identifiers carried in signaling.
Bitar, et al. [Page 18]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
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 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.
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 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. MS-PW OAM SHOULD support switch over between 1:1 protected
LSPs end-to-end.
-v. VCCV SHOULD be provided both end-to-end across the MS-PW,
and on a segment (i.e. SS-PW) basis.
-vi. All PE routers along the MS-PW MUST agree on a common PW OAM
mechanism to use to the MS-PW.
-vii. At the S-PE, defects on an PSN tunnel MUST be propagated to
all PWs that utilize that particular PSN tunnel.
Bitar, et al. [Page 19]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
-viii. The directionality of defect notifications MUST be
maintained across the S-PE.
-ix. The S-PE SHOULD be able to behave as a segment endpoint for
PW OAM mechanisms.
-x. The S-PE MUST be able to pass T-PE to T-PE PW OAM messages
transparently.
8. Security Considerations
This document specifies the requirements for MS-PWs that can be setup
across domain boundaries administered by one ore more service
providers. The security requirements for MS-PWs setup across domains
administered by one service provider are the same as those described
under security considerations in [PWE3_control]. These requirements
also apply to interprovider MS-PWs. 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.
8.1. Data-plane Security Requirements
MS-PWs that cross SP domain boundaries may connect one T-PE in one SP
domain to a T-PE in another SP-domain. They may also transit other SP
domains even if the two T-PEs are under the control of one SP. Under
these scenarios, theere is a chance that one or more PDUs 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 MS-PW cross-connects. Solutions MAY
provide mechanisms for ensuring the end-end authenticity of MS-PW
PDUs.
One of the crossed domains 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-PDU can
be violated. This document does not place any requirements on
protecting the privacy of a MS-PW PDU via encryption for instance.
Encryption may be performed 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
an incoming MS-PW traffic to the MS-PW traffic parameters or to an
Bitar, et al. [Page 20]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
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
then 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 an 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
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.
8.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.
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. 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).
Furthermore, the restriction of peering sessions to specific
interfaces SHOULD also be provided. The S-PE and T-PE SHOULD 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.
For a greater degree of security, an authentication mechanism that is
Bitar, et al. [Page 21]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
suitable to the associated protocol MUST be available. 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.
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 provide 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.
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. Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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.
Bitar, et al. [Page 22]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
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
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.
11. IANA Considerations
This document has no IANA Actions.
12. Normative References
[PWE3-ARCH] "PWE3 Architecture" Bryant, et al., RFC3985.
[PWE3-OAM] "Pseudo Wire (PW) OAM Message Mapping" Nadeau et al.,
draft-ietf-pwe3-oam-msg-map-02.txt (work in progress),
February 2005
13. Informative References
[ITUQ] ITU-T Recommendation Q.933, and Q.922 Specification for
Frame Mode Basic call control, ITU Geneva 1995
Bitar, et al. [Page 23]
Internet Draft draft-ietf-pwe3-ms-pw-requirements-01.txt October 2005
14. Author Information
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
e-mail: nabil.bitar@verizon.com
Matthew Bocci
Alcatel Telecom Ltd,
Voyager Place
Shoppenhangers Road
Maidenhead
Berks, UK
e-mail: matthew.bocci@alcatel.co.uk
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
e-mail: lmartini@cisco.com
Bitar, et al. [Page 24]
