Internet DRAFT - draft-raggarwa-rsvpte-pw
draft-raggarwa-rsvpte-pw
Network Working Group R. Aggarwal
Internet Draft K. Kompella
Expiration Date: April 2006 A. Ayyanger
Juniper Networks
D. Papadimitriou
Alcatel
P. Busschbach
Lucent
N. Sprecher
Siemens
L. Y. Jie
China Unicom
October 2005
Setup and Maintenance of Pseudowires using RSVP-TE
draft-raggarwa-rsvpte-pw-03.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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Raggarwa, et al. [Page 1]
Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005
Abstract
This document describes procedures for using Resource Reservation
Protocol-Traffic Engineering (RSVP-TE) for signaling Pseudowires
(PWs). One motivation is the signaling of PW QoS. The other is the
setup of a multi-hop PW, for example, to span multiple domains.
RSVP-TE provides mechanisms for QoS signaling and these can be
leveraged for signaling PW QoS. It also provides the ability to
signal bi-directional MPLS Label Switched Paths (LSP) with explicit
routes. This can be used for signaling multi-hop PWs that require
explicit routing. RSVP-TE also provides the ability to establish non-
adjacent or targeted signaling sessions.
Raggarwa, et al. [Page 2]
Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005
Table of Contents
1 Specification of requirements ......................... 4
2 Terminology ........................................... 4
3 Introduction .......................................... 4
4 Motivation ............................................ 5
4.1 PW QoS ................................................ 5
4.2 Multi-Hop PWs ......................................... 6
4.3 PW Redundancy ......................................... 7
5 Motivation for using RSVP-TE .......................... 7
5.1 QoS Signaling ......................................... 8
5.2 Explicit Routing ...................................... 8
5.3 Sharing QoS Resources between LSPs .................... 8
5.4 Bidirectional Label Allocation ........................ 9
5.5 LSP Hierarchy ......................................... 9
6 Design Overview ....................................... 9
6.1 Mapping RSVP-TE LSPs to PWs ........................... 9
6.2 Non-Adjacent Signaling ................................ 9
6.3 Single-Hop PW Label Signaling ......................... 10
6.4 Asynchronous Signaling and Single Sided Signaling ..... 10
7 Procedures ............................................ 10
7.1 RSVP-TE PW Identification ............................. 10
7.2 Single-Hop PW Setup ................................... 11
7.2.1 PW Signaling using Unidirectional LSPs ................ 11
7.2.2 PW Signaling using Bidirectional LSPs ................. 12
7.3 Single-Hop PW QoS Signaling ........................... 12
7.4 Multi-Hop PW Signaling ................................ 13
7.5 Redundant PWs ......................................... 14
8 OAM Mechanisms ........................................ 14
9 Security Considerations ............................... 15
10 IANA Considerations ................................... 15
11 Acknowledgments ....................................... 15
12 References ............................................ 15
12.1 Normative References .................................. 15
12.2 Informative References ................................ 16
13 Author Information .................................... 16
14 Intellectual Property Statement ....................... 17
15 Full Copyright Statement .............................. 18
Raggarwa, et al. [Page 3]
Internet Draft draft-raggarwa-rsvpte-pw-03.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 [RFC2119].
2. Terminology
This document follows the terminology in [RFC3985] and [PWMH-REQ].
The following terminology is specified here.
Single-hop PW: A PW that comprises only two PW demultiplexor alloca-
tion nodes.
Multi-hop PW: A PW that comprises more than two PW demultiplexor
allocation nodes.
In addition the reader is expected to be familiar with the terminol-
ogy and mechanisms described in [RFC3209] and [RFC3473].
3. Introduction
A PW is a mechanism that carries the essential elements of an emu-
lated service from one PE to another over a PSN [RFC3985]. A point to
point PW is bi-directional. A "PW header", consisting of a (PW)
demultiplexor field is prepended to the encapsulated PDU. The result-
ing packet is then transmitted to the remote endpoint of the PW over
one or more "PSN tunnels"; this may require an additional header to
be prepended to the packet. When the packet arrives at the remote
endpoint of the PW, the PW demultiplexor is what enables the receiver
to identify the particular PW on which the packet has arrived.
In the case that it is not desirable to establish a single PSN tunnel
between the two endpoints of a PW or the PW needs to be explicitly
routed across multiple hops for QoS provisioning or administrative
reasons, a multi-hop PW is needed [PWMH-REQ]. In this case each PW
hop uses a separate PSN tunnel. The PW demultiplexor may have to be
changed at each hop. An example scenario where a multi-hop PW is
needed is one that spans multiple domains, where edge-to-edge PSNs
may not be possible for scaling or administrative reasons. Each
domain may have a different PSN technology.
[LDP-PW] describes procedures for using the Label Distribution Proto-
col [LDP] for the setup and maintenance of single-hop PWs. The PW
demultiplexor field is a MPLS label, and PW demultiplexor signaling
performs label exchange between two PEs.
Raggarwa, et al. [Page 4]
Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005
If one wants to signal multi-hop, explicitly routed PWs and/or PWs
with QoS characteristics, new mechanisms are required [PWMH-REQ].
The protocol architecture of RSVP-TE is an appropriate fit for these
applications (as well as demultiplexor exchange). This is because
RSVP-TE [RFC3209] has the mechanisms for signaling QoS and for
explicit routing. RSVP-TE extensions described in [RFC3473] also pro-
vide mechanisms to setup bi-directional LSPs. It also has mechanisms
that can be used for PW identification, setup and maintenance.
Multi-hop PWs traverse multiple PSN tunnels and the PSN tunnels may
be setup using Generalized MPLS (GMPLS) signaling [RFC3473]. Hence
another useful applicability scope of the proposed approach is PWs
over MPLS PSNs supporting GMPLS RSVP-TE [RFC 3473] as well as other
switching technologies within the scope of GMPLS.
This document describes procedures for using RSVP-TE for PW signaling
motivated by the goals mentioned in the previous paragraph. This doc-
ument assumes familiarity with [RFC3209] and [RFC3473].
4. Motivation
This section describes the motivations behind this document. Some of
these motivations are also discussed in [PWMH-REQ].
4.1. PW QoS
A PW is a mechanism that carries the essential elements of an emu-
lated service from one PE to another over a PSN [RFC3985]. The emu-
lated service is offered by a SP to a customer over an attachment
circuit (AC). Hence a PW can also be considered as a mechanism that
is used to inter-connect two ACs over a PSN. A Service Level Agree-
ment (SLA) is often associated with such an emulated service. Packet
loss and delay bounds in a given time interval are examples of a SLA
that a SP may provide to a customer. Such a SLS translates into QoS,
for example bandwidth, that is associated with the PW. Providing this
QoS on the PW requires the following:
a) Assigning QoS parameters to each AC in conformance with the
SLA. These QoS parameters get associated with the PW that is used to
carry traffic from the AC.
b) Policing on the AC on both the PEs based on the QoS parameters
c) Call admission control (CAC) of the PW into the PSN tunnel
which is used to transmit the PW packets. This assumes that the PSN
tunnel can be signaled with QoS. To achieve this RSVP-TE can be used
as the PSN tunnel signaling protocol.
The procedures described above require that the two ends of a PW be
Raggarwa, et al. [Page 5]
Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005
associated with the same QoS parameters. In current PW deployments
this is achieved using configuration. However it is desirable to sig-
nal this QoS information from one end of the PW to another. This is
beneficial for PW operation and management. This is also desirable
for multi-hop PWs described in the next section. It should also be
possible to change the QoS characteristics of a PW without any packet
loss on the PW.
4.2. Multi-Hop PWs
A PW by default inter-connects the ACs between two PEs that exchange
the PW demultiplexor. These two PEs are the PW demultiplexor alloca-
tion nodes and are connected by a single PSN domain. This is a sin-
gle-hop PW. A multi-hop PW inter-connects the ACs between two PEs
across multiple PSN domains [MHPW-REQ]. Hence a multi-hop PW refers
to a PW that comprises more than two PW demultiplexor allocation
nodes. One way to conceptualize this is as multiple PWs that are
stitched together and are still part of the same end to end PW.
A multi-hop PW is needed when it is not desirable to establish a sin-
gle PSN tunnel between the two endpoints of a PW or the PW needs to
be explicitly routed across multiple hops for QoS provisioning or
administrative reasons. [PWMH-REQ]. The PW demultiplexor allocation
nodes along a multi-hop PW need to be explicitly specified. This
requires a PW explicit route. Some of the hops in the explicit route
may be strict while others may be loose.
A practical application of a multi-hop PWs is the setup of a PW
across multiple domains. For instance across multiple IGP domains or
ASs or domains with different PSN technologies.
Consider an inter-AS PW that is set up by PE1 in AS1 to PE2 in AS2.
It may be desirable to control the exit point of this PW in AS1 and
select the entry point of the PW in AS2. Traffic accounting per PW is
one motivation for this. Another motivation is security. Yet another
motivation is to avoid setting up a full mesh of end-to-end PWs
between ASs. The inter-AS PW may be explicitly routed through ASBR1
in AS1, which is PE1's next-hop to reach PE2. ASBR1 in turn may
explicitly route the PW through ASBR2 which is its next-hop to reach
PE2. ASBR2 will complete the PW signaling. In this case there is one
signaling protcol adjacency to signal the PW between PE1 and ASBR1;
one between ASBR1 and ASBR2; and one between ASBR2 and PE2. PE1,
ASBR1, ASBR2 and PE2 are PW demultiplexor allocation points.
Raggarwa, et al. [Page 6]
Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005
4.3. PW Redundancy
It may be desirable to backup one PW with another. A CE may be dual
homed to two different PEs. Or a CE may be dual homed to a PE using
two different ACs. One AC is the primary while the other is the
backup. Both these ACs are attached to the same remote AC. The remote
PE can setup a PW for each of the two local ACs. One of these PWs is
the primary PW while the other is the backup PW. The backup PW is
setup apriori and is in standby mode incase the primary PW fails. The
primary and backup PWs may also be multi-hop PWs and may be signaled
with QoS. The multi-hop primary and backup PWs may be routed over
different PW demultiplexor allocation points. For example, it may be
desired that they enter an AS via different ASBRs to avoid a single
point of failure. If they pass through the same PW demultiplexor
points QoS double booking must be avoided between these two PWs, when
they are transported over the same tunnel, as only one of them is
active at a given time.
It should also be possible to use fast protection mechanisms for the
PW and for the tunnel used to transport the PW. These two mechanisms
can co-exist.
5. Motivation for using RSVP-TE
This section describes why RSVP-TE is an appropriate fit for address-
ing the motivations described in section 3.
RSVP-TE is used to setup explicitly routed Label Switched Paths
(LSPs). Multiple LSPs may belong to the same tunnel. A LSP is iden-
tified using a SESSION object and a SENDER_TEMPLATE object. The SES-
SION object carries a tunnel identifier (TUNNEL_ID) to identify a
tunnel. It also carries the tunnel destination. The SENDER_TEMPLATE
carries the source of the tunnel and a LSP_ID to identify a specific
LSP. An ingress LSR is defined as the LSR that originates the LSP. An
egress LSR is defined as the endpoint of the LSP. LSP setup consists
of signaling in the forward and the reverse direction. The ingress
LSR originates a Path message to the egress LSR and the egress LSR
responds with a Resv message. The LSP is successfully established
when the ingress LSR receives the Resv message.
[RFC3209] defines the setup of unidirectional LSPs. [RFC3473] extends
this to bidirectional LSPs. Hence a Path message sent by the ingress
LSR can be used to signal a bidirectional LSP.
RSVP-TE signaling messages can be exchanged between adjacent or non-
adjacent nodes [LSP-HIER]. RSVP-TE siginaling messages between non-
adjacent nodes are essentially targeted signaling messages.
Raggarwa, et al. [Page 7]
Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005
The specific building blocks of RSVP-TE that make it an appropriate
fit for solving the problems addressed by this document are discussed
below. In the following discussion a LSP may bea unidirectional LSP
or a bidirectional LSP.
5.1. QoS Signaling
RSVP-TE is designed to setup LSPs that are signaled with QoS Parame-
ters. These parameters may include diffserv parameters. The Path mes-
sage carries the QoS specification that is requested by the ingress
LSR in the SENDER_TSPEC object. The SENDER_TSPEC object carries the
traffic specification generated by RSVP session sender i.e the
ingress LSR. The SENDER_TSPEC object is forwarded unchanged and
delivered to both transit and egress LSRs. The FLOWSPEC object car-
ries reservation request information generated by receivers i.e. the
QoS desired by egress LSRs. The information content of the FLOWSPEC
object flows upstream towards the ingress LSR. Each transit LSR uses
the FLOWSPEC object for CAC and to setup the LSP QoS in hardware in
the direction from the ingress LSR to the egress LSR and also in the
reverse direction.
This mechanism can be used for signaling PW QoS. Differentiated
(Diffserv) Services is supported using procedures defined in
[RFC3270] and Diffserv aware MPLS TE (DS-TE) QoS signaling is sup-
ported as defined in [RFC4124].
5.2. Explicit Routing
As discussed in section 3 one of the requirements of signaling multi-
hop PWs is the specification of an explicit route. RSVP-TE allows a
LSP to be setup using an EXPLICIT_ROUTE_OBJECT (ERO). An ERO contains
a sequence of hops that the LSP must be routed through. The semantics
allow an intermediate hop to insert hops in the ERO.
5.3. Sharing QoS Resources between LSPs
RSVP-TE allows multiple LSPs to belong to the same tunnel. These LSPs
can be signaled such that they share QoS resources with each other
between common hops. This can be used for PW redundancy. A backup PW
can be setup to share QoS resources with the primary PW between com-
mon hops, when the primary and backup PWs are transported over the
same tunnel. It can also be used for modifying the QoS of a PW using
RSVP-TE make-before-break [RFC3209].
Raggarwa, et al. [Page 8]
Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005
5.4. Bidirectional Label Allocation
RSVP-TE [RFC3209] sets up unidirectional LSPs and provides the mecha-
nism to signal the downstream label in the Resv message. [RFC3473]
extends this to signal bidirectional LSPs allowing the upstream label
to be carried in the Path message. A PW is bidirectional and RSVP-TE
bidirectional label allocation mechanisms MAY be used for PW label
exchange with a single signaling session.
5.5. LSP Hierarchy
[RFC3209] supports the notion of LSP hierarchy. A LSP can be adver-
tised as a Forwarding Adjacency (FA) to rest of the domain, allowing
other nodes in the domain to use the FA LSP as a link for computing
traffic engineered paths for other LSPs [LSP-HIER]. One or more LSPs
(inner LSPs) can be carried over the FA LSP (outer LSP). When RSVP-TE
is used for PW signaling and PSN tunnels are also setup using RSVP-
TE, the PSN tunnels may be advertised as FA LSPs. If this is the
case the multi-hop PW origination point can use the FA LSPs to traf-
fic engineer the path of the multi-hop PW, which is the inner LSP.
6. Design Overview
This section gives an overview of how RSVP-TE can be used for
addressing the motivations described in section 3.
6.1. Mapping RSVP-TE LSPs to PWs
This document maps a PW to either two unidirectiona LSPs, one in each
direction between the ingress and egress LSRs or a bidirectional LSP.
A PW is identified by the SESSION object, SENDER_TEMPLATE object and
a new PW TLV that is carried in a new SENDER_TSPEC C-Type. The PW TLV
is discussed in section 6.1. Mapping a PW to a LSP allows the use of
QoS signaling, explicit and record routing, resource sharing as well
as as any other RSVP capability that can be mapped to an LSP
6.2. Non-Adjacent Signaling
Non-adjacent signaling between PW demultiplexor allocation points is
used for signaling PWs with RSVP-TE. This allows RSVP-TE signaling
messages to be exchanged between hops that are not directly adjacent
[LSP-HIER]. Targeted RSVP-TE signaling messages are signaled using
procedures specified in [LSP-HIER]. This implies that RSVP-TE mes-
sages used to setup the MS-PW are completely transparent to each PSN
Raggarwa, et al. [Page 9]
Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005
i.e. they are not intercepted and processed by any of the intermedi-
ate nodes (as the IP header of the MS-PW RSVP-TE message MUST NOT
have the Router Alert option set).
6.3. Single-Hop PW Label Signaling
This document proposes that RSVP-TE can also be used for signaling
single-hop PW demultiplexors. This MAY be done using bidirectional
label allocation mechanisms. It is conceivable that a different pro-
tocol can be used for signaling single-hop PW demultiplexors when
RSVP-TE is used for multi-hop PW signaling or PW QoS signaling. LDP
[LDP-PW] can be used for this purpose. This may be useful if a net-
work has currently deployed LDP for single-hop PW setup with or with-
out QoS and wishes to setup multi-hop PWs. In that case a PW associ-
ation is needed between LDP and RSVP-TE. This is for further study.
6.4. Asynchronous Signaling and Single Sided Signaling
There are two models of signaling RSVP-TE multi-hop PWs. In the first
model both the ends of the PW signal the PW using unidirectional
LSPs. Thus both ends exchange asynchronous signaling messages. Both
unidirectional LSPs are signaled using the same PW TLV. Each end MUST
use this PW TLV to associate the unidirectional LSPs with each other
and complete the PW setup.
In the second model RSVP-TE PW sessions are originated by one end of
the PW using a bidirectional LSP. The other end of the PW completes
the signaling by responding to this request. This follows the single
sided signaling concept that has been proposed earlier in [LDP-PW].
In this model both the PW ends do not initiate asynchronous signaling
messages. It is only one end that initiates the PW setup. Note that
the use of bidrectional LSPs for signaling RSVP-TE MH PWs does not
imply the use of bidirectional RSVP-TE tunnel LSPs. Unidirectional
RSVP-TE tunnel LSPs can be used.
7. Procedures
7.1. RSVP-TE PW Identification
A LSP is mapped to a PW. A PW is identified by the SESSION object,
the SENDER_TEMPLATE object and a new PSEUDOWIRE TLV (PW TLV) included
as part of a new SENDER_TSPEC/FLOWSPEC object. Details of the
SENDER_TSPEC/FLOWSPEC object encoding carried in the Path and Resv
message, respectively, will be specified in the next revision. The PW
TLV identifies the individual PW. It also allows the receiver of the
Raggarwa, et al. [Page 10]
Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005
RSVP-TE Path message to realize that the signaled session is being
used to setup a PW. This identifier can either be a 32 bit number or
it can have generalized semantics. The encoding of this identifier
follows that specified in [LDP-PW]. A different TLV type is used for
both these cases.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
| ... |
+---------------------------------------------------------------+
The PW type, presence of the control word and any other PW specific
parameters are signaled in the SENDER_TSPEC. Details will be speci-
fied along with the SENDER_TSPEC encoding in the next revision.
7.2. Single-Hop PW Setup
This document proposes the use of RSVP-TE for exchanging single-hop
PW labels when RSVP-TE is used for addressing the motivations
described in Section 3. This is accomplished by using either two uni-
directional LSPs and associating them with the PW using PW-TLV or
bidirectional label allocation mechanisms. The PW MUST be signaled as
a LSP by the ingress of the PW using a non-adjacent i.e. targeted
Path message. The remote PE MUST associate PW semantics with the LSP
based on the PW parameters carried in the SENDER_TSPEC object includ-
ing the PW TLV. The outer label can be the transport LSP label when
using MPLS tunnels. It can also be any other PSN tunnel encapsula-
tion: eg. IP or GRE.
Refresh reduction [RFC2961] SHOULD be used to reduce the refresh and
processing overhead of RSVP-TE control messages.
7.2.1. PW Signaling using Unidirectional LSPs
Consider that both ends of the MH PW, PE1 and PE2, use asynchronous
signaling using unidirectional LSPs. When PE2 receives a Path message
for the PW LSP, it MUST respond with a Resv message that carries a PW
label allocated by the PE2. If PE2 is unable to allocate a PW label,
it MUST return a PathError message as specified in [RFC3209]. If PE2
has not yet generated a PW LSP Path message to PE1, it MUST generate
Raggarwa, et al. [Page 11]
Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005
this message. This message MUST carry the same PW ID that was present
in the received Path message. Note that this assumes that both ends
of the PW are configured with the same PW ID. PE2 MUST add a MPLS
route for the PW label, that it allocated and returned in the Resv
message in response to the Path message from PE1, with the AC as the
next-hop. When PE1 receives the Path message from PE2, it MUST
respond with a Resv message. When PE2 receives this Resv message
with a PW label in the upstream direction it MUST add a route that is
used to map traffic from the AC into the PW. The inner label of the
route's next-hop is the PW label (i.e. the upstream label) received
from the PE that signaled the PW.
7.2.2. PW Signaling using Bidirectional LSPs
Consider that the MH PW is setup using single sided signaling and
bidirectional LSPs with PE1 intiating the bidirectional LSP Path mes-
sage to PE2. PE2 MUST add a route that is used to map traffic from
the AC into the PW. The inner label of the route's next-hop is the
PW label (i.e. the upstream label) received from PE1 that signaled
the PW. When a Path message containing an upstream PW label is
received by PE2, it first verifies that the upstream label is accept-
able. If the label is not acceptable, the receiver MUST issue a
PathErr message with a "Routing problem/Unacceptable PW label value"
indication. PE2 then generates a Resv message and sends it to PE1
along with a PW label (i.e. the downstream label). PE2 MUST add a
MPLS route fro the PW downstream label, with the AC as next-hop. PE1
completes the PW setup by adding the local AC route and the MPLS PW
label route. Contention resolution for bi-directional LSPs follows
rules specified in Section 3.2 of [RFC3473]. When a bidirectional LSP
is torn down, both upstream and downstream labels are invalidated and
it is no longer valid to send data using the associated labels.
7.3. Single-Hop PW QoS Signaling
A RSVP-TE LSP is established for the PW between the two PEs using
non-adjacent signaling. The PW LSP is signaled with the QoS parame-
ters desired by the local PE for the PW. These parameters are carried
in the SENDER_TSPEC object in the Path Message and in the FLOWSPEC
object in the Resv message.
The SENDER_TSPEC object MUST be delivered unchanged to the egress PE.
This object also includes the PW TLV used to identify the PW.
The egress PE MUST verify that the incoming SENDER_TSPEC QoS parame-
ters can be supported for the requested LSP. If the requested
Raggarwa, et al. [Page 12]
Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005
value(s) can not be supported, the egress PE MUST generate a PathErr
message with a "Traffic Control Error/Service unsupported" indication
(see [RFC2205]).
The remote PE responds with a Resv message that contains in the
FLOWSPEC object the QoS parameters desired by the remote PE. This
value is either the same as the QoS requested in the SENDER_TSPEC or
lower. Both the local and the remote PE use the FLOWSPEC for adminis-
tering PW QoS. If the objects do not match the PW TLV or the QoS
requested parameters are larger, a ResvErr message with a "Traffic
Control Error/Bad Flowspec value" error SHOULD be generated.
QoS signaling mechanisms in RSVP-TE are fairly mature. They have been
defined for various QoS service models. Also RSVP-TE [RFC3209] and
various extensions to it [RFC3473] describe mechanisms for signaling
QoS for different media such as ATM, Frame Relay, optical interfaces
etc. Based on the AC being inter-connected, the PW LSP is signaled
with an appropriate SENDER_TSPEC/FLOWSPEC object.
RSVP-TE make-before-break procedures can be used to modify PW QoS or
the PW explicit route without impacting PW traffic.
7.4. Multi-Hop PW Signaling
A multi-hop PW that requires explicit routing is signaled using a
RSVP-TE LSP with a PW TLV in the SENDER_TSPEC object and an explicit
route encoded in the EXPLICIT_ROUTE object. The ingress LSR sends a
Path message with the destination address being the multi-hop PW end
point. The explicit route specifies the hops that the PW must be
routed through. Intermediate nodes may insert hops in the explicit
route as the ingress LSR may specify the explicit route partially. PW
labels that are used to send data in the direction from the egress
LSR to the ingress LSR are allocated by each PW demultiplexor alloca-
tion hop and propagated in the Path message, if the LSP is a bidirec-
tional LSP. The SENDER_TSPEC object is propagated unchanged to the
multi-hop PW endpoint which uses the PW TLV to identify the PW. The
egress of the multi-hop PW responds with a Resv message. This message
contains the FLOWSPEC object, which is used to administer the QoS at
each intermediate node as the Resv message is propagated to the
ingress LSR. PW labels that are used to send data in the direction
from the ingress LSR to the egress LSR are allocated by each PW
demultiplexor allocation hop and propagated in the Resv message. If
asynchronus signaling is used, the egress LSR also generates a Path
message for traffic in the direction from the egress LSR to the
ingress LSR and the ingress LSR responds to this Path message with a
Resv message.
Raggarwa, et al. [Page 13]
Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005
In addition to the processing of the SENDER_TSPEC and FLOWSPEC object
described in Section 6.3 at the ingress and egress LSR, here, inter-
mediate PW demultiplexors MUST verify that the node itself and the
interfaces on which the LSP will be established can support the
requested QoS parameters. If the requested value(s) can not be sup-
ported, the receiver node MUST generate a PathErr message with a
"Traffic Control Error/Service unsupported" indication (see
[RFC2205]).
7.5. Redundant PWs
A local PE can signal a redundant PW using the same SESSION object as
the primary PW and by varying the LSP-ID in the SENDER_TEMPLATE
object. This allows intermediate hops to share QoS between the two.
In the case of failure of the primary PW the local PE can try to
switch traffic to the backup PW.
Note that the procedures described in this document allow a CE to be
dual homed to the same PE. Procedures for dual homing a CE to differ-
ent PEs will be described in the next revision.
8. OAM Mechanisms
Requirements on MH PW OAM are detailed in [MHPW-REQ]. This section
details realization of these requirements through the use of Bi-
directional Forwarding Detection (BFD) and Virtual Circuit Connection
Verification (VCCV).
Per [BFD-MPLS], BFD in conjunction with LSP-Ping can be used for
scalable MPLS LSP OAM, when the LSP is associated with a RSVP
IPv4/IPv6 Session [RSVP-TE].
BFD for MPLS LSPs can be used for MH PWs signaled using RSVP-TE. The
recommended method is to use BFD for MPLS using in-band [VCCV] encap-
sulation. In this case, the use of BFD is independent from the PSN
Tunnel technology. BFD PDUs must be forwarded transparently by S-PEs
to allow monitoring of the MH-PW end-to-end. This results in estab-
lishing a BFD session from a U-PE to another U-PE for the MH PW. This
may have scalability limitations depending on the number of MH PWs.
Raggarwa, et al. [Page 14]
Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005
9. Security Considerations
Security considerations from [RFC3209] and [RFC3473] apply to this
document.
10. IANA Considerations
TBD
11. Acknowledgments
Thanks to Chaitanya Kodeboyina and Sasha Vainshtein for discussing
the ideas presented here. Thanks to Nabil Bitar for his comments.
12. References
12.1. Normative References
[RFC3209] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP
tunnels", RFC 3209, December 2001.
[RFC3473] L. Berger, Ed.. Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource Reservation Protocol-Traffic
Engineering (RSVP-TE) Extensions, RFC 3473 January 2003.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF
Integrated Services", RFC 2210, September 1997.
[LSP-HIER] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
F. and S. Molendini, "RSVP Refresh Overhead
Reduction Extensions", RFC 2961, April 2001.
[RFC] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3985] "PWE3 Architecture" Bryant, et al.,
draft-ietf-pwe3-arch-07.txt, March 2003.
[PWMH-REQ] "Requirements for inter domain Pseudo-Wires", L. Martini,
N. Bitar, M. Bocci [Editors], draft-ietf-pwe3-ms-pw-require-
ments-00.txt,
Raggarwa, et al. [Page 15]
Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005
[RFC3270] F. L. Faucheur et. al., "Multi-Protocol Label Switching
(MPLS) Support of Differentiated Services", RFC 3270
[RFC4124] F. L. Faucheur [Editor], "Protocol Extensions for Support
of Diffserv-aware MPLS Traffic Engineering", RFC 4124
12.2. Informative References
[BFD-MPLS] R. Aggarwal et. al., "BFD for MPLS LSPs", draft-ietf-bfd-
mpls-02.txt
[LSP-Ping] K. Kompella et. al., "Detecting MPLS Data Plane Failures",
draft-ietf-mpls-lsp-ping-03.txt
[VCCV] T. Nadeau, R. Aggarwal, "Pseudo Wire (PW) Virtual Circuit
Connection Verification ((VCCV)",
draft-ietf-pwe3-vccv-03.txt
[LDP] Andersson, L., et al, "LDP Specification", RFC 3036
[LDP-PW] L. Martini et. al.,"Pseudowire Setup and Maintenance
using LDP",
draft-ietf-pwe3-control-protocol-08.txt
[MPLS-ST] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter,
D. Tappan, G. Fedorkow, D. Farinacci, T. Li, A. Conta.
RFC3032
13. Author Information
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net
Kireeti Kompella
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: kireeti@juniper.net
Arthi Ayyangar
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Raggarwa, et al. [Page 16]
Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005
Email: arthi@juniper.net
Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel.be
Peter Busschbach
Lucent Technologies
67 Whippany Road
Whippany, NJ 07981
email: busschbach@lucent.com
Nurit Sprecher
Siemens Communications
Seabridge
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241 Israel
Email: nurit.sprecher@seabridgenetworks.com
Liu Yun Jie
China Unicom
No.133A,XiDan North Street,
XiCheng District,
BeiJing,100032,P.R.China
Eail: liuyj@chinaunicom.com.cn
14. 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 assur-
ances 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.
Raggarwa, et al. [Page 17]
Internet Draft draft-raggarwa-rsvpte-pw-03.txt October 2005
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.
15. 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 INFOR-
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Raggarwa, et al. [Page 18]
