One document matched: draft-davie-tsvwg-rsvp-l3vpn-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-davie-tsvwg-rsvp-l3vpn-01.txt"
ipr="full3978">
<front>
<title abbrev="RSVP for L3VPNs">Support for RSVP in Layer 3 VPNs</title>
<author fullname="Bruce Davie" initials="B." surname="Davie">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1414 Mass. Ave.</street>
<city>Boxborough</city>
<region>MA</region>
<code>01719</code>
<country>USA</country>
</postal>
<email>bsd@cisco.com</email>
</address>
</author>
<author fullname="Francois le Faucheur" initials="F."
surname="le Faucheur">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Village d'Entreprise Green Side - Batiment T3</street>
<street>400, Avenue de Roumanille</street>
<code>06410</code>
<region>Biot Sophia-Antipolis</region>
<country>France</country>
</postal>
<email>flefauch@cisco.com</email>
</address>
</author>
<author fullname="Ashok Narayanan" initials="A." surname="Narayanan">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1414 Mass. Ave.</street>
<city>Boxborough</city>
<region>MA</region>
<code>01719</code>
<country>USA</country>
</postal>
<email>ashokn@cisco.com</email>
</address>
</author>
<date day="19" month="November" year="2007" />
<abstract>
<t>RFC 4364 defines an approach to building provider-provisioned Layer 3
VPNs. It may be desirable to use RSVP to perform admission control on
the links between CE and PE routers. This document specifies procedures
by which RSVP messages travelling from CE to CE across an L3VPN may be
appropriately handled by PE routers so that admission control can be
performed on PE-CE links. Optionally, admission control across the
provider's backbone may also be supported.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t><xref target="RFC4364" /> defines a Layer 3 VPN service known as
BGP/MPLS VPNs. <xref target="RFC2205" /> defines the Resource
Reservation Protocol (RSVP) which may be used to perform admission
control as part of the Integrated Services (int-serv) architecture <xref
target="RFC1633" /><xref target="RFC2210" />.</t>
<t>Customers of a layer 3 VPN service may run RSVP for the purposes of
admission control in their own networks. Since the links between
Provider Edge (PE) and Customer Edge (CE) routers in a layer 3 VPN may
often be resource constrained, it may be desirable to be able to perform
admission control over those links. In order to perform admission
control using RSVP in such an environment, it is necessary that RSVP
control messages, such as Path messages and Resv messages, are
appropriately handled by the PE routers. This presents a number of
challenges in the context of BGP/MPLS VPNs:<list style="symbols">
<t>RSVP Path message processing depends on routers recognizing the
router alert option in the IP header. However, packets traversing
the backbone of a BGP/MPLS VPN are MPLS encapsulated and thus the
router alert option is not normally visible to the egress PE.</t>
<t>BGP/MPLS VPNs support non-unique addressing of customer networks.
Thus a PE at the ingress or egress of the provider backbone may be
called upon to process Path messages from different customer VPNs
with non-unique destination addresses.</t>
<t>A PE at the ingress of the provider's backbone may receive Resv
messages corresponding to different customer VPNs from other PEs,
and needs to be able to associate those Resv messages with the
appropriate customer VPNs.</t>
</list>This document describes a set of procedures to overcome these
challenges and thus to enable admission control using RSVP over the
PE-CE links. We note that similar techniques may be applicable to other
protocols used for admission control such as NSIS <xref
target="RFC4080" />.</t>
<t>Additionally, it may be desirable to perform admission control over
the provider's backbone on behalf of one or more L3VPN customers. Core
(P) routers in a BGP/MPLS VPN do not have forwarding entries for
customer routes, and thus cannot natively process RSVP messages for
customer flows. Also the core is a shared resource that carries traffic
for many customers, so issues of resource allocation among customers and
trust (or lack thereof) must also be addressed. This draft also
specifies procedures for supporting such a scenario.</t>
<t>This draft deals with establishing reservations for unicast flows
only. Because the support of multicast traffic in BGP/MPLS VPNs is still
evolving, and raises additional challenges for admission control, we
leave the support of multicast flows for further study at this
point.</t>
<section title="Terminology">
<t>This document draws freely on the terminology defined in <xref
target="RFC2205" /> and <xref target="RFC4364" />. For convenience, we
provide a few brief definitions here:<list style="symbols">
<t>CE (Customer Edge) Router: Router at the edge of a customer
site that attaches to the network of the VPN provider.</t>
<t>PE (Provider Edge) Router: Router at the edge of the service
provider's network that attaches to one or more customer
sites.</t>
<t>VPN Label: An MPLS label associated with a route to a customer
prefix in a VPN (also called a VPN route label).</t>
<t>VRF: VPN Routing and Forwarding Table. A PE typically has
multiple VRFs, enabling it to be connected to CEs that are in
different VPNs.</t>
</list></t>
</section>
</section>
<section title="Problem Statement">
<t>The problem space of this document is the support of admission
control between customer sites when the customer subscribes to a
BGP/MPLS VPN. We subdivide the problem into (a) the problem of admission
control on the PE-CE links (in both directions), and (b) the problem of
admission control across the provider's backbone.</t>
<t>For the PE-CE link subproblem, the most basic challenge is that RSVP
control messages contain IP addresses that are drawn from the customer's
address space, and PEs must be able to deal with traffic from many
customers who may have non-unique (or overlapping) address spaces. Thus,
it is essential that a PE be able in all cases to identify the correct
VPN context in which to process an RSVP control message. Much of this
draft deals with this issue.</t>
<t>For the case of making reservations across the provider backbone, we
observe that BGP/MPLS VPNs do not create any per-customer forwarding
state in the P (provider core) routers. Thus, in order to make
reservations on behalf of customer-specified flows, it is clearly
necessary to make some sort of aggregated reservation from PE-PE and
then map individual, customer-specific reservations onto an aggregate
reservation. That is similar to the problem tackled in <xref
target="RFC3175" /> and <xref target="RFC4804" />, with the additional
complications of handling customer-specific addressing associated with
BGP/MPLS VPNs.</t>
<t>Finally, we note that RSVP Path messages are normally addressed to
the destination of a session, and contain the router alert IP option.
Routers along the path to the destination that are configured to process
RSVP messages must detect the presence of the router alert option to
allow them to intercept Path messages. However, the egress PEs of a
network supporting BGP/MPLS VPNs receive packets destined for customer
sites as MPLS-encapsulated packets, and normally forward based only on
examination of the MPLS label. Hence, a Path message would typically be
forwarded without examination of the IP options and would therefore not
receive appropriate processing at the PE. This problem of recognizing
and processing Path messages is also discussed below.</t>
<section anchor="model" title="Model of Operation">
<t>Figure 1 illustrates the basic model of operation with which this
document is concerned.</t>
<figure>
<preamble />
<artwork><![CDATA[
--------------------------
/ Provider \
|----| | Backbone | |----|
Sender->| CE1| |-----| |-----| |CE2 |->Receiver
| |--| | |---| |---| | |---| |
|----| | | | P | | P | | | |----|
| PE1 |---| |-----| |-----| PE2 |
| | | | | | | |
| | |---| |---| | |
|-----| |-----|
| |
\ /
--------------------------
]]></artwork>
<postamble>Figure 1. Model of Operation for RSVP-based admission
control over MPLS/BGP VPN</postamble>
</figure>
<t />
<t>To establish a unidirectional reservation for a point-to-point flow
from Sender to Receiver that takes account of resource availability on
the CE-PE and PE-CE links only, the following steps must take
place:<list style="numbers">
<t>Sender sends a Path message to an IP address of the
Receiver.</t>
<t>Path message is processed by CE1 using normal RSVP procedures
and forwarded towards the Receiver along the link CE1-PE1.</t>
<t>PE1 processes Path message and forwards towards the Receiver
across the provider backbone.</t>
<t>PE2 processes Path message and forwards towards the Receiver
along link PE2-CE2.</t>
<t>CE2 processes Path message using normal RSVP procedures and
forwards towards Receiver.</t>
<t>Receiver sends Resv message to CE2.</t>
<t>CE2 sends Resv message to PE2.</t>
<t>PE2 processes Resv message (including performing admission
control on link PE2-CE2) and sends Resv to PE1.</t>
<t>PE1 processes Resv message and sends Resv to CE1.</t>
<t>CE1 processes Resv using normal RSVP procedures, performs
admission control on the link CE1-PE1 and sends Resv message to
Sender if successful.</t>
</list> In each of the steps involving Resv messages (6 through 10)
the node sending the Resv uses the previously established Path state
to determine the "RSVP Previous Hop (PHOP)" and sends a Resv message
to that address. We note that establishing that Path state correctly
at PEs is one of the challenges posed by the BGP/MPLS environment.</t>
</section>
</section>
<section anchor="cac-pe-ce" title="Admission Control on PE-CE Links">
<t>In the following sections we trace through the steps outlined in
<xref target="model" /> and expand on the details for those steps where
standard RSVP procedures need to be extended or modified to support the
BGP/MPLS VPN environment. For all the remaining steps described in the
preceding section, standard RSVP processing rules apply.</t>
<section anchor="path-proc-i"
title="Path Message Processing at Ingress PE">
<t>When a Path message arrives at the ingress PE (step 3 of <xref
target="model" />) the PE needs to establish suitable Path state and
forward the Path message on to the egress PE. In the following
paragraphs we described the steps taken by the ingress PE.</t>
<t>The Path message is addressed to the eventual destination (the
receiver at the remote customer site) and carries the IP Router Alert
option, in accordance with <xref target="RFC2205" />. The ingress PE
must recognize the router alert, intercept these messages and process
them as RSVP signalling messages.</t>
<t>As noted above, there is an issue in recognizing Path messages as
they arrive at the egress PE (PE 2 in Figure 1). Since standard Path
messages carry the router alert IP option, one possible approach would
be to use the MPLS router alert label <xref target="RFC3032" /> when
sending a Path message from ingress PE to egress PE. However this may
suffer from problems of backwards compatibility with existing deployed
hardware that may not process the Router Alert label. The preferred
approach proposed here is to address the Path messages sent by the
ingress PE directly to the egress PE; that is, rather than using the
ultimate receiver's destination address as the destination address of
the Path message, we use the loopback address of the egress PE as the
destination address of the Path message. This approach has the
advantage that it does not require any new data plane capabilities for
the egress PE beyond those of a standard BGP/MPLS VPN PE. Details of
the processing of this message at the egress PE are described below.
The approach of addressing a Path message directly to an RSVP next hop
that is not the next IP hop is already used in other environments such
as those of <xref target="RFC4206" /> and <xref
target="RFC4804" />.</t>
<t>The details of operation at the ingress PE are as follows. When the
ingress PE (PE1 in Figure 1) receives a Path message from CE1 that is
addressed to the receiver, the VRF that is associated with the
incoming interface is identified, just as for normal data path
operations. The Path state for the session is stored, and is
associated with that VRF, so that potentially overlapping addresses
among different VPNs do not appear to belong to the same session. The
destination address of the receiver is looked up in the appropriate
VRF, and the BGP Next-Hop for that destination is identified. That
next-hop is the egress PE (PE2 in Figure 1). The VPN label for that
destination is obtained and placed in a new RSVP object (VPN_LABEL,
defined below.) A new Path message is constructed with a destination
address equal to the address of the egress PE identified above. This
new Path message will contain all the objects from the original Path
message, plus the VPN_LABEL object. Note that the SESSION object
contains the ultimate (customer) destination address of the flow,
while the IP header for the message contains the address of the egress
PE. The RSVP_HOP object in the Path message contains an IP address of
the ingress PE. The Path message also contains a new identifier that
will be echoed by the egress PE inside the Resv message, thereby
allowing the ingress PE to identify the correct VRF in which to
process the Resv. The VRF_ID object that serves this function is
defined below, and is used to carry a locally significant VRF
identifier. The VRF identifier needs to be meaningful only to the PE
that creates this object.</t>
</section>
<section anchor="path-proc-e"
title="Path Message Processing at Egress PE">
<t>When a Path message arrives at the egress PE, it is addressed to
the PE itself, and is handed to RSVP for processing. The router needs
to <list style="letters">
<t>Determine the egress VRF for this flow, and how to forward a
Path message on towards the correct CE and ultimate
destination;</t>
<t>Store the information received in the Path message (including
the VRF_ID Object);</t>
<t>Construct a suitable Path message with the correct destination
address and forward it.</t>
</list></t>
<t>For step a, we can imagine the router containing an RSVP module and
a forwarding module (this division is for exposition only; there is no
intention to specify the internal implementation here). The RSVP
module extracts the MPLS label contained in the VPN_LABEL object, and
the destination IP address contained in the SESSION object, and passes
them to the normal forwarding module for MPLS-encapsulated packets.
The forwarding module returns to RSVP the outgoing interface
information, including the egress VRF, that would have been used had a
packet with that MPLS label and IP address been received. (Note that
in many cases the MPLS label alone is all that is needed to determine
the forwarding information for the packet, but in some cases it is
necessary to pop the label and examine the IP address; hence both are
passed to the forwarding module.)</t>
<t>Step b proceeds as follows. Note that <xref target="RFC2205" />
identifies the fields in the SESSION object to define a session,
specifically the destination address, protocol and destination port.
In this draft, we can consider the identity of the egress VRF that was
determined in step a also to be part of the session definition. The
identity of this egress VRF is therefore stored with the Path state to
facilitate processing of Resv messages for this session.</t>
<t>Now the RSVP module can construct a Path message which differs from
the Path it received in the following ways:<list style="letters">
<t>Its destination address is the IP address extracted from the
SESSION Object;</t>
<t>It does not contain the VPN_LABEL Object or the VRF_ID
Object.</t>
<t>The RSVP_HOP Object contains the IP address of the outgoing
interface of the egress PE and an LIH, as per normal RSVP
processing.</t>
</list>The router then sends the Path message on towards its
destination over the interface identified above.</t>
</section>
<section title="Resv Processing at Egress PE">
<t>When a receiver at the customer site originates a Resv message for
the session, normal RSVP procedures apply until the Resv, making its
way back towards the sender, arrives at the "egress" PE (it is
"egress" with respect to the direction of data flow, i.e. PE2 in
figure 1). On arriving at PE2, the SESSION and FILTER_SPEC objects in
the Resv, and the VRF in which the Resv was received, are used to find
the matching Path state stored previously. At this stage, admission
control can be performed on the PE-CE link.</t>
<t>Assuming admission control is successful, the PE constructs a Resv
message to send to the RSVP HOP stored in the Path state, i.e., the
ingress PE (PE1 in Figure 1). It includes the VRF_ID object that was
obtained from the Path message as described above. The Resv message is
addressed to the ingress PE and sent.</t>
<t>If admission control is not successful, a ResvError message is sent
towards the receiver as per normal RSVP processing.</t>
</section>
<section anchor="resv-proc-i" title="Resv Processing at Ingress PE">
<t>Upon receiving a Resv message at the ingress PE (with respect to
data flow, i.e. PE1 in Figure 1), the PE extracts the VRF identifier
from VRF_ID object and determines which VRF the session is associated
with. It is now possible to locate the appropriate Path state for the
reservation, and generate a Resv message to send to the appropriate
CE. Since we assume in this section that admission control over the
Provider’s backbone is not needed, the ingress PE does not
perform any admission control for this reservation.</t>
</section>
<section title="Other RSVP Messages">
<t>Processing of PathError, PathTear, ResvError, ResvTear and ResvConf
messages is generally straightforward and follows the rules of <xref
target="RFC2205" />. However, for PathTear, ResvError, and ResvConf
messages travelling from an ingress PE to an egress PE, these
additional rules must be observed:<list style="symbols">
<t>The VRF_ID and VPN_LABEL objects must be included in the
message;</t>
<t>The message must be directly addressed to the appropriate PE,
without using the IP Router Alert option;</t>
<t>The VPN_LABEL must be used to determine how to process and
forward the message, in the same way that it is used to process
and forward Path messages, as described in <xref
target="path-proc-e" />.</t>
</list></t>
<t>For ResvTear and PathError messages sent from an egress PE to an
ingress PE, the following rules must be observed:<list style="symbols">
<t>The appropriate VRF_ID object must be included in the
message;</t>
<t>The message must be directly addressed to the appropriate
ingress PE;</t>
<t>The VRF_ID must be used to to determine how to process and
forward the message, in the same way that it is used to process
and forward Resv messages, as described in <xref
target="resv-proc-i" />.</t>
</list></t>
</section>
</section>
<section anchor="backbone"
title="Admission Control in Provider's Backbone">
<t>The preceding section outlines how per-customer reservations can be
made over the PE-CE links. This may be sufficient in many situations
where the backbone is well engineered with ample capacity and there is
no need to perform any sort of admission control in the backbone.
However, in some cases where excess capacity cannot be relied upon
(e.g., during failures or unanticipated periods of overload) it may be
desirable to be able to perform admission control in the backbone on
behalf of customer traffic.</t>
<t>Because of the fact that routes to customer addresses are not present
in the P routers, along with the concerns of scalability that would
arise if per-customer reservations were allowed in the P routers, it is
clearly necessary to map the per-customer reservations described in the
preceding section onto some sort of aggregate reservations. Furthermore,
customer data packets need to be tunneled across the provider backbone
just as in normal BGP/MPLS VPN operation.</t>
<t>Given these considerations, a feasible way to achieve the objective
of admission control in the backbone is to use the ideas described in
<xref target="RFC4804" />. MPLS-TE tunnels can be established between
PEs as a means to perform aggregate admission control in the
backbone.</t>
<t>An MPLS-TE tunnel from an ingress PE to an egress PE can be thought
of as a virtual link of a certain capacity. The main change to the
procedures described above is that when a Resv is received at the
ingress PE, an admission control decision can be performed by checking
whether sufficient capacity of that virtual link remains available to
admit the new customer reservation. We note also that <xref
target="RFC4804" /> uses the IF_ID RSVP_HOP object to identify the
tunnel across the backbone, rather than the simple RSVP_HOP object
described in <xref target="path-proc-i" />. The procedures of <xref
target="RFC4804" /> should be followed here as well. </t>
<t>To achieve effective admission control in the backbone, there needs
to be some way to separate the data plane traffic that has a reservation
from that which does not. We assume that packets that are subject to
admission control on the core will be given a particular MPLS EXP value,
and that no other packets will be allowed to enter the core with this
value unless they have passed admission control. Some fraction of link
resources will be allocated to queues on core links for packets bearing
that EXP value, and the MPLS-TE tunnels will use that resource pool to
make their constraint-based routing and admission control decisions.
This is all consistent with the principles of aggregate RSVP
reservations described in <xref target="RFC3175" />.</t>
</section>
<section title="Inter-AS operation">
<t><xref target="RFC4364" /> defines three modes of inter-AS operation
for MPLS/BGP VPNs, referred to as options A, B and C. In the following
sections we describe how the scheme described above can operate in each
inter-AS environment.</t>
<section title="Inter-AS Option A">
<t>Option A is quite straightforward. Each ASBR operates like a PE,
and the ASBR-ASBR links can be viewed as PE-CE links in terms of
admission control. If the procedures defined in <xref
target="cac-pe-ce" /> are enabled on both ASBRs, then CAC may be
performed on the inter-ASBR links. In addition, the operator of each
AS can independently decide whether or not to perform CAC across his
backbone.</t>
</section>
<section title="Inter-AS Option B">
<t>To support inter-AS Option B, we require some additional processing
of RSVP messages on the ASBRs. Recall that in option B, the VPN label
is swapped by each ASBR as a packet goes from one AS to another. Thus,
the VPN_LABEL that is placed in a Path message at an ingress PE will
be the VPN Label that was advertised by the egress ASBR for the
session.</t>
<t>In this scenario, we require ASBRs to store the Path and Resv state
(even though the ASBRs may or may not be required to perform admission
control). An ASBR that receives a Path with the VPN_LABEL object will
look up that label in its forwarding table and find the outgoing label
and place that label in the VPN_LABEL object before sending the Path
on to the next ASBR. Thus a Path message will make its way from
ingress PE, through some number of ASBRs, to an egress PE, with the
VPN_LABEL object getting modified at each ASBR. </t>
<t>Now consider the process for getting messages back to the correct
VRF in the reverse direction. Because the VRF_ID is locally
significant to the PE that first inserted it (and only to that PE) an
ASBR cannot simply pass that object along unmodified. Instead the ASBR
should create its own locally significant "pseudo-VRF_ID" (pseudo
since the ASBR doesn't have VRFs in Option B). The function of that
"VRF_ID" is simply to ensure that when the ASBR receives a Resv coming
upstream, it can look up the VRF_ID received in the Resv and figure
out what PE (or upstream ASBR) to send the Resv to, and what VRF_ID to
insert in the Resv it sends. This approach ensures that a Resv will be
forwarded back to the correct ingress PE and will arrive there with
the appropriate VRF_ID to be processed appropriately.</t>
<t>Note that this approach allows (but does not require) admission
control on any segment of the end-end path. (For example, one could do
CAC only on CE-PE links, or on ASBR-ASBR links as well, on some of the
P cores but not others, etc.)</t>
</section>
<section title="Inter-AS Option C">
<t>Option C is also quite straightforward, because there exists an LSP
directly from ingress PE to egress PE. In this case, there is no
significant difference in operation from the single AS case described
in <xref target="cac-pe-ce" />. Furthermore, if it is desired to
provide admission control from PE to PE, it can be done by building an
inter-AS TE tunnel and then using the procedures described in <xref
target="backbone" />. </t>
</section>
</section>
<section title="Operation with RSVP disabled">
<t>It is often the case that RSVP will not be enabled on the PE-CE
links. In such an environment, a customer may reasonably expect that
RSVP messages sent into the L3 VPN network should be forwarded just like
any other IP datagrams. This transparency is useful when the customer
wishes to use RSVP within his own sites or perhaps to perform admission
control on the CE-PE links (in CE->PE direction only), without
involvement of the PEs. For this reason, a PE SHOULD NOT discard or
modify RSVP messages sent towards it from a CE when RSVP is not enabled
on the PE-CE links. Similarly a PE SHOULD NOT discard or modify RSVP
messages which are destined for one of its attached CEs, even when RSVP
is not enabled on those links. Note that the presence of the router
alert option in some RSVP messages may cause them to be forwarded
outside of the normal forwarding path, but that the guidance of this
paragraph still applies in that case. Note also that this guidance
applies regardless of whether RSVP-TE is used in some, all, or none of
the L3VPN network.</t>
</section>
<section title="Support for CE-CE RSVP-TE">
<t><xref target="I-D.kumaki-l3vpn-e2e-rsvp-te-reqts" /> describes a set
of requirements for the establishment for CE-CE MPLS LSPs across
networks offering an L3VPN service. The requirements specified in that
draft are similar to those addressed by this document, in that both
address the issue of handling RSVP requests from customers in a VPN
context. It is possible that the solution described here could be
adapted to meet the requirements of <xref
target="I-D.kumaki-l3vpn-e2e-rsvp-te-reqts" />. A later version of this
draft will examine this possibility in detail.</t>
</section>
<section anchor="objects" title="Object Definitions">
<t />
<section title="VPN_Label Object">
<t>The usage of the VPN_LABEL Object is described in <xref
target="path-proc-i" /> and <xref target="path-proc-e" />. The
VPN_LABEL object should appear in all RSVP messages that contain a
SESSION object and are sent from ingress PE to egress PE. The object
MUST NOT be included in any RSVP messages that are sent outside of the
provider's backbone (except in the inter-AS option B and C cases, as
described above, when it may appear on inter-AS links). The format of
the object is as follows:</t>
<figure>
<preamble />
<artwork><![CDATA[
VPN_LABEL object: Class = TBA, C-Type = 1
+-------------+-------------+-------------+-------------+
| Reserved(12 bits) | Label (20 bits) |
+-------------+-------------+-------------+-------------+
]]></artwork>
<postamble />
</figure>
<t>The Reserved bits must be set to zero on transmission and ignored
on receipt.</t>
</section>
<section title="VRF_ID Object">
<t>The usage of the VRF_ID Object is described in <xref
target="cac-pe-ce" />. The VRF_ID object is a locally significant
opaque value. The object is inserted into RSVP messages that carry a
SESSION object, and that travel between the Ingress and Egress PEs. It
MUST NOT be included in any RSVP messages that are sent outside of the
provider's backbone (except in the inter-AS option B and C cases, as
described above, when it may appear on inter-AS links). The format of
the object is as follows:</t>
<figure>
<preamble />
<artwork><![CDATA[
VRF_ID object: Class = TBA, C-Type = 1
+-------------+-------------+-------------+-------------+
| VRF_ID (32 bits) |
+-------------+-------------+-------------+-------------+]]></artwork>
<postamble />
</figure>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requires IANA assignment of two new RSVP Class Numbers
to accommodate the new objects described in <xref target="objects" />.
These should be assigned from the range 0x11bbbbbb, so that they will be
ignored but forwarded by routers that do not understand them.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t><xref target="RFC4364" /> addresses the security considerations of
BGP/MPLS VPNs in general. General RSVP security considerations are
addressed in <xref target="RFC2205" />. To ensure the integrity of RSVP,
the RSVP Authentication mechanisms defined in <xref target="RFC2747" />
and <xref target="RFC3097" />may be used. These protect RSVP message
integrity hop-by-hop and provide node authentication as well as replay
protection, thereby protecting against corruption and spoofing of RSVP
messages. <xref
target="I-D.behringer-tsvwg-rsvp-security-groupkeying" /> discusses
applicability of various keying approaches for RSVP Authentication. We
note that the RSVP signaling in MPLS VPN is likely to spread over
multiple administrative domains (e.g. the service provider operating the
VPN service, and the customers of the service). Therefore the
considerations in <xref
target="I-D.behringer-tsvwg-rsvp-security-groupkeying" /> about
inter-domain issues are likely to apply.</t>
<t>Beyond those general issues, two specific issues are introduced by
this document: resource usage on PEs, and resource usage in the provider
backbone. We discuss these in turn.</t>
<t>A customer who makes resource reservations on the CE-PE links for his
sites is only competing for link resources with himself, as in standard
RSVP, at least in the common case where each CE-PE link is dedicated to
a single customer. Thus, from the perspective of the CE-PE links, this
draft does not introduce any new security issues. However, because a PE
typically serves multiple customers, there is also the possibility that
a customer might attempt to use excessive computational resources on a
PE (CPU cycles, memory etc.) by sending large numbers of RSVP messages
to a PE. In the extreme this could represent a form of denial-of-service
attack. In order to prevent such an attack, a PE should have mechanisms
to limit the fraction of its processing resources that can be consumed
by any one CE or by the set of CEs of a given customer. For example, a
PE might implement a form of rate limiting on RSVP messages that it
receives from each CE.</t>
<t>The second concern arises only when the service provider chooses to
offer resource reservation across the backbone, as described in <xref
target="backbone" />. In this case, the concern may be that a single
customer might attempt to reserve a large fraction of backbone capacity,
perhaps with a co-ordinated effort from several different CEs, thus
denying service to other customers using the same backbone. <xref
target="RFC4804" /> provides some guidance on the security issues when
RSVP reservations are aggregated onto MPLS tunnels, which are applicable
to the situation described here. We note that a provider may use local
policy to limit the amount of resources that can be reserved by a given
customer from a particular PE, and that a policy server could be used to
control the resource usage of a given customer across multiple PEs if
desired.</t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>Thanks to Ashwini Dahiya, Prashant Srinivas, Manu Pathak, Yakov
Rekhter and Eric Rosen for their many contributions to solving the
problems described in this draft. </t>
</section>
<appendix anchor="altern" title="Alternatives Considered">
<t>At this stage a number of alternatives to the approach described
above have been considered. We document some of the approaches
considered here to assist future discussion. None of these has been
shown to improve upon the approach described above, and the first two
seem to have significant drawbacks relative to the approach described
above. </t>
<appendix title="GMPLS UNI approach">
<t><xref target="RFC4208" /> defines the GMPLS UNI. In Section 7 the
operation of the GMPLS UNI in a VPN context is briefly described. This
is somewhat similar to the problem tackled in the current document.
The main difference is that the GMPLS UNI is primarily aimed at the
problem of allowing a CE device to request the establishment of an LSP
across the network on the other side of the UNI. Hence the procedures
in <xref target="RFC4208" /> would lead to the establishment of an LSP
across the VPN provider's network for every RSVP request received,
which is not desired in this case.</t>
<t>To the extent possible, the approach described in this document is
consistent with <xref target="RFC4208" />, while filling in more of
the details and avoiding the problem noted above.</t>
</appendix>
<appendix title="VRF label approach">
<t>Another approach to solving the problems described here involves
the use of label switching to ensure that Path, Resv, and other RSVP
messages are directed to the appropriate VRF. One challenge with such
an approach is that <xref target="RFC4364" /> does not require labels
to be allocated for VRFs, only for customer prefixes, and that there
is no simple, existing method for advertising the fact that a label is
bound to a VRF. If, for example, an ingress PE sent a Path message
labelled with a VPN label that was advertised by the egress PE for the
prefix that matches the destination address in the Path, there is a
risk that the egress PE would simply label-switch the Path directly on
to the CE without performing RSVP processing.</t>
<t>A second challenge with this approach is that an IP address needs
to be associated with a VRF and used as the PHOP address for the Path
message sent from ingress PE to egress PE. That address must be
reachable from the egress PE, and exist in the VRF at the ingress PE.
Such an address is not always available in today's deployments, so
this represents at least a change to existing deployment
practices.</t>
</appendix>
<appendix title="VRF label plus VRF address approach">
<t>It is possible to create an approach based on that described in the
previous section which addresses the main challenges of that approach.
The basic approach has two parts: (a) define a new BGP Extended
Community to tag a route (and its associated MPLS label) as pointing
to a VRF; (b) allocate a "dummy" address to each VRF, specifically to
be used for routing RSVP messages. The dummy address (which could be
anything, e.g. a loopback of the associated PE) would be used as a
PHOP for Path messages and would serve as the destination for Resv
messages but would not be imported into VRFs of any other PE. </t>
<t />
</appendix>
</appendix>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.2205'?>
<?rfc include='reference.RFC.4364'?>
<?rfc include='reference.RFC.4804'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.1633'?>
<?rfc include='reference.RFC.2210'?>
<?rfc include='reference.RFC.3175'?>
<?rfc include='reference.RFC.4860'?>
<?rfc include='reference.RFC.3032'?>
<?rfc include='reference.RFC.4080'?>
<?rfc include='reference.RFC.2747'?>
<?rfc include='reference.RFC.3097'?>
<?rfc include='reference.RFC.4206'?>
<?rfc include='reference.RFC.4208'?>
<?rfc include='reference.I-D.kumaki-l3vpn-e2e-rsvp-te-reqts'?>
<?rfc include='reference.I-D.behringer-tsvwg-rsvp-security-groupkeying'?>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 07:38:50 |