draft-ietf-tsvwg-rsvp-l3vpn-03.txt   draft-ietf-tsvwg-rsvp-l3vpn-04.txt 
Network Working Group B. Davie Network Working Group B. Davie
Internet-Draft F. le Faucheur Internet-Draft F. le Faucheur
Intended status: Standards Track A. Narayanan Intended status: Standards Track A. Narayanan
Expires: April 29, 2010 Cisco Systems, Inc. Expires: May 24, 2010 Cisco Systems, Inc.
October 26, 2009 November 20, 2009
Support for RSVP in Layer 3 VPNs Support for RSVP in Layer 3 VPNs
draft-ietf-tsvwg-rsvp-l3vpn-03.txt draft-ietf-tsvwg-rsvp-l3vpn-04.txt
Abstract
RFC 4364 and RFC 4659 define an approach to building provider-
provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to
use RSVP to perform admission control on the links between Customer
Edge (CE) routers and Provider Edge (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.
Requirements Language
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 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 2, line 5
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010. This Internet-Draft will expire on May 24, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
RFC 4364 and RFC 4659 define an approach to building provider- described in the BSD License.
provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to
use RSVP to perform admission control on the links between Customer
Edge (CE) routers and Provider Edge (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.
Requirements Language
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 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Model of Operation . . . . . . . . . . . . . . . . . . . . 6 2.1. Model of Operation . . . . . . . . . . . . . . . . . . . . 7
3. Admission Control on PE-CE Links . . . . . . . . . . . . . . . 7 3. Admission Control on PE-CE Links . . . . . . . . . . . . . . . 8
3.1. New Objects of Type VPN-IPv4 . . . . . . . . . . . . . . . 8 3.1. New Objects of Type VPN-IPv4 . . . . . . . . . . . . . . . 8
3.2. Path Message Processing at Ingress PE . . . . . . . . . . 9 3.2. Path Message Processing at Ingress PE . . . . . . . . . . 10
3.3. Path Message Processing at Egress PE . . . . . . . . . . . 10 3.3. Path Message Processing at Egress PE . . . . . . . . . . . 11
3.4. Resv Processing at Egress PE . . . . . . . . . . . . . . . 11 3.4. Resv Processing at Egress PE . . . . . . . . . . . . . . . 12
3.5. Resv Processing at Ingress PE . . . . . . . . . . . . . . 11 3.5. Resv Processing at Ingress PE . . . . . . . . . . . . . . 12
3.6. Other RSVP Messages . . . . . . . . . . . . . . . . . . . 12 3.6. Other RSVP Messages . . . . . . . . . . . . . . . . . . . 12
4. Admission Control in Provider's Backbone . . . . . . . . . . . 12 4. Admission Control in Provider's Backbone . . . . . . . . . . . 13
5. Inter-AS operation . . . . . . . . . . . . . . . . . . . . . . 13 5. Inter-AS operation . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Inter-AS Option A . . . . . . . . . . . . . . . . . . . . 13 5.1. Inter-AS Option A . . . . . . . . . . . . . . . . . . . . 14
5.2. Inter-AS Option B . . . . . . . . . . . . . . . . . . . . 14 5.2. Inter-AS Option B . . . . . . . . . . . . . . . . . . . . 14
5.2.1. Admission control on ASBR . . . . . . . . . . . . . . 14 5.2.1. Admission control on ASBR . . . . . . . . . . . . . . 15
5.2.2. No admission control on ASBR . . . . . . . . . . . . . 14 5.2.2. No admission control on ASBR . . . . . . . . . . . . . 15
5.3. Inter-AS Option C . . . . . . . . . . . . . . . . . . . . 15 5.3. Inter-AS Option C . . . . . . . . . . . . . . . . . . . . 16
6. Operation with RSVP disabled . . . . . . . . . . . . . . . . . 16 6. Operation with RSVP disabled . . . . . . . . . . . . . . . . . 16
7. Other RSVP procedures . . . . . . . . . . . . . . . . . . . . 16 7. Other RSVP procedures . . . . . . . . . . . . . . . . . . . . 17
7.1. Refresh overhead reduction . . . . . . . . . . . . . . . . 16 7.1. Refresh overhead reduction . . . . . . . . . . . . . . . . 17
7.2. Cryptographic Authentication . . . . . . . . . . . . . . . 16 7.2. Cryptographic Authentication . . . . . . . . . . . . . . . 17
7.3. RSVP Aggregation . . . . . . . . . . . . . . . . . . . . . 17 7.3. RSVP Aggregation . . . . . . . . . . . . . . . . . . . . . 18
7.4. Support for CE-CE RSVP-TE . . . . . . . . . . . . . . . . 17 7.4. Support for CE-CE RSVP-TE . . . . . . . . . . . . . . . . 18
8. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 18 8. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 19
8.1. VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . . . . . . 18 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . . . . . . 19
8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects . . . . . . 19 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects . . . . . . 20
8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects . . . . . . . . 20 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects . . . . . . . . 21
8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects . . . . . . . . . . 21 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects . . . . . . . . . . 22
8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . 23 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . 24
8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6
SENDER_TEMPLATE objects . . . . . . . . . . . . . . . . . 25 SENDER_TEMPLATE objects . . . . . . . . . . . . . . . . . 26
8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC
objects . . . . . . . . . . . . . . . . . . . . . . . . . 26 objects . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Alternatives Considered . . . . . . . . . . . . . . 33 Appendix A. Alternatives Considered . . . . . . . . . . . . . . 34
Appendix A.1. GMPLS UNI approach . . . . . . . . . . . . . . . . . 33 Appendix A.1. GMPLS UNI approach . . . . . . . . . . . . . . . . . 34
Appendix A.2. VRF label approach . . . . . . . . . . . . . . . . . 33 Appendix A.2. VRF label approach . . . . . . . . . . . . . . . . . 34
Appendix A.3. VRF label plus VRF address approach . . . . . . . . 34 Appendix A.3. VRF label plus VRF address approach . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.1. Normative References . . . . . . . . . . . . . . . . . . . 34 12.1. Normative References . . . . . . . . . . . . . . . . . . . 35
12.2. Informative References . . . . . . . . . . . . . . . . . . 34 12.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
[RFC4364] and [RFC4659] define a Layer 3 VPN service known as BGP/ [RFC4364] and [RFC4659] define a Layer 3 VPN service known as BGP/
MPLS VPNs for IPv4 and for IPv6 respectively. [RFC2205] defines the MPLS VPNs for IPv4 and for IPv6 respectively. [RFC2205] defines the
Resource Reservation Protocol (RSVP) which may be used to perform Resource Reservation Protocol (RSVP) which may be used to perform
admission control as part of the Integrated Services (Int-Serv) admission control as part of the Integrated Services (Int-Serv)
architecture [RFC1633][RFC2210]. architecture [RFC1633][RFC2210].
Customers of a layer 3 VPN service may run RSVP for the purposes of Customers of a layer 3 VPN service may run RSVP for the purposes of
skipping to change at page 4, line 25 skipping to change at page 4, line 25
networks. Since the links between Provider Edge (PE) and Customer networks. Since the links between Provider Edge (PE) and Customer
Edge (CE) routers in a layer 3 VPN may often be resource constrained, 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 it may be desirable to be able to perform admission control over
those links. In order to perform admission control using RSVP in those links. In order to perform admission control using RSVP in
such an environment, it is necessary that RSVP control messages, such such an environment, it is necessary that RSVP control messages, such
as Path messages and Resv messages, are appropriately handled by the as Path messages and Resv messages, are appropriately handled by the
PE routers. This presents a number of challenges in the context of PE routers. This presents a number of challenges in the context of
BGP/MPLS VPNs: BGP/MPLS VPNs:
o RSVP Path message processing depends on routers recognizing the o RSVP Path message processing depends on routers recognizing the
router alert option in the IP header. However, packets traversing router alert option ([RFC2113], [RFC2711]) in the IP header.
the backbone of a BGP/MPLS VPN are MPLS encapsulated and thus the However, packets traversing the backbone of a BGP/MPLS VPN are
router alert option is not normally visible to the egress PE. MPLS encapsulated and thus the router alert option is not normally
visible to the egress PE.
o BGP/MPLS VPNs support non-unique addressing of customer networks. o BGP/MPLS VPNs support non-unique addressing of customer networks.
Thus a PE at the ingress or egress of the provider backbone may be Thus a PE at the ingress or egress of the provider backbone may be
called upon to process Path messages from different customer VPNs called upon to process Path messages from different customer VPNs
with non-unique destination addresses. with non-unique destination addresses.
o A PE at the ingress of the provider's backbone may receive Resv o A PE at the ingress of the provider's backbone may receive Resv
messages corresponding to different customer VPNs from other PEs, messages corresponding to different customer VPNs from other PEs,
and needs to be able to associate those Resv messages with the and needs to be able to associate those Resv messages with the
appropriate customer VPNs. appropriate customer VPNs.
skipping to change at page 5, line 4 skipping to change at page 5, line 5
the NSIS Signaling Layer Protocol (NSLP) for QoS Signaling the NSIS Signaling Layer Protocol (NSLP) for QoS Signaling
([I-D.ietf-nsis-qos-nslp]) and General Internet Signaling Transport ([I-D.ietf-nsis-qos-nslp]) and General Internet Signaling Transport
(GIST) protocol ([I-D.ietf-nsis-ntlp]). (GIST) protocol ([I-D.ietf-nsis-ntlp]).
Additionally, it may be desirable to perform admission control over Additionally, it may be desirable to perform admission control over
the provider's backbone on behalf of one or more L3VPN customers. 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 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 routes, and thus cannot natively process RSVP messages for
customer flows. Also the core is a shared resource that carries customer flows. Also the core is a shared resource that carries
traffic for many customers, so issues of resource allocation among traffic for many customers, so issues of resource allocation among
customers and trust (or lack thereof) must also be addressed. This customers and trust (or lack thereof) also ought to be addressed.
draft also specifies procedures for supporting such a scenario. This document specifies procedures for supporting such a scenario.
This draft deals with establishing reservations for unicast flows This document deals with establishing reservations for unicast flows
only. Because the support of multicast traffic in BGP/MPLS VPNs is only. Because the support of multicast traffic in BGP/MPLS VPNs is
still evolving, and raises additional challenges for admission still evolving, and raises additional challenges for admission
control, we leave the support of multicast flows for further study at control, we leave the support of multicast flows for further study at
this point. this point.
1.1. Terminology 1.1. Terminology
This document draws freely on the terminology defined in [RFC2205] This document draws freely on the terminology defined in [RFC2205]
and [RFC4364]. For convenience, we provide a few brief definitions and [RFC4364]. For convenience, we provide a few brief definitions
here: here:
skipping to change at page 5, line 42 skipping to change at page 5, line 43
2. Problem Statement 2. Problem Statement
The problem space of this document is the support of admission The problem space of this document is the support of admission
control between customer sites when the customer subscribes to a BGP/ control between customer sites when the customer subscribes to a BGP/
MPLS VPN. We subdivide the problem into (a) the problem of admission 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 control on the PE-CE links (in both directions), and (b) the problem
of admission control across the provider's backbone. of admission control across the provider's backbone.
For the PE-CE link subproblem, the most basic challenge is that RSVP For the PE-CE link subproblem, the most basic challenge is that RSVP
control messages contain IP addresses that are drawn from the control messages contain IP addresses that are drawn from the
customer's address space, and PEs must be able to deal with traffic customer's address space, and PEs need to deal with traffic from many
from many customers who may have non-unique (or overlapping) address customers who may have non-unique (or overlapping) address spaces.
spaces. Thus, it is essential that a PE be able in all cases to Thus, it is essential that a PE be able in all cases to identify the
identify the correct VPN context in which to process an RSVP control correct VPN context in which to process an RSVP control message.
message. Much of this draft deals with this issue. Much of this document deals with this issue.
For the case of making reservations across the provider backbone, we For the case of making reservations across the provider backbone, we
observe that BGP/MPLS VPNs do not create any per-customer forwarding observe that BGP/MPLS VPNs do not create any per-customer forwarding
state in the P (provider core) routers. Thus, in order to make state in the P (provider core) routers. Thus, in order to make
reservations on behalf of customer-specified flows, it is clearly reservations on behalf of customer-specified flows, it is clearly
necessary to make some sort of aggregated reservation from PE-PE and necessary to make some sort of aggregated reservation from PE-PE and
then map individual, customer-specific reservations onto an aggregate then map individual, customer-specific reservations onto an aggregate
reservation. That is similar to the problem tackled in [RFC3175] and reservation. That is similar to the problem tackled in [RFC3175] and
[RFC4804], with the additional complications of handling customer- [RFC4804], with the additional complications of handling customer-
specific addressing associated with BGP/MPLS VPNs. specific addressing associated with BGP/MPLS VPNs.
Finally, we note that RSVP Path messages are normally addressed to Finally, we note that RSVP Path messages are normally addressed to
the destination of a session, and contain the router alert IP option. the destination of a session, and contain the router alert option.
Routers along the path to the destination that are configured to Routers along the path to the destination that are configured to
process RSVP messages must detect the presence of the router alert process RSVP messages need to detect the presence of the router alert
option to allow them to intercept Path messages. However, the egress option to allow them to intercept Path messages. However, the egress
PEs of a network supporting BGP/MPLS VPNs receive packets destined PEs of a network supporting BGP/MPLS VPNs receive packets destined
for customer sites as MPLS-encapsulated packets, and may forward for customer sites as MPLS-encapsulated packets, and possibly
those based only on examination of the MPLS label. Hence, a Path forwards those based only on examination of the MPLS label. Hence, a
message would be forwarded without examination of the IP options and Path message would be forwarded without examination of the IP options
would therefore not receive appropriate processing at the PE. This and would therefore not receive appropriate processing at the PE.
problem of recognizing and processing Path messages is also discussed This problem of recognizing and processing Path messages is also
below. discussed below.
Consider the case where an MPLS VPN customer uses RSVP signaling
across his sites for resource reservation and admission control.
Let's further assume that, initially, RSVP is not processed through
the MPLS VPN cloud (i.e RSVP messages from the sender to the receiver
travel transparently from CE to CE). In that case, RSVP allows
establishment of resource reservations and admission control on a
subset of the flow path (from sender to ingress CE; and from the RSVP
router downstream of the egress CE to the receiver). If admission
control is then activated on any of the CE-PE link, provider's
backbone or PE-CE link (as allowed by the present document), the
customer will benefit from an extended coverage of admission control
and resource reservation: the resource reservation will now span over
a bigger subset of (and possibly the whole) flow path, which in turn
will increase the quality of service granted to the corresponding
flow. Specific flows whose reservation is successful through
admission control on the newly enabled segments will indeed benefit
from this quality of service enhancement. However, it must be noted
that, in case there is not enough resources on one (or more) of the
newly enabled segments (e.g. Say admission control is enabled on a
given PE-->CE link and there is not enough capacity on that link to
admit all reservations for all the flows traversing that link) then
some flows will not be able to maintain, or establish, their
reservation. While this may appear undesirable for these flows, we
observe that this only occurs if there is indeed a lack of capacity
on a segment, and that in the absence of admission control all flows
would be established but would all suffer from the resulting
congestion on the bottleneck segment. We also observe that, in case
of such lack of capacity, admission control allows enforcement of
controlled and flexible policies (so that, for example, more
important flows can be granted higher priority at reserving
resources). We note also that flows are given a chance to establish
smaller reservations so that the aggregate load can adapt dynamically
to the bottleneck capacity.
2.1. Model of Operation 2.1. Model of Operation
Figure 1 illustrates the basic model of operation with which this Figure 1 illustrates the basic model of operation with which this
document is concerned. document is concerned.
-------------------------- --------------------------
/ Provider \ / Provider \
|----| | Backbone | |----| |----| | Backbone | |----|
Sender->| CE1| |-----| |-----| |CE2 |->Receiver Sender->| CE1| |-----| |-----| |CE2 |->Receiver
skipping to change at page 6, line 48 skipping to change at page 7, line 35
|-----| |-----| |-----| |-----|
| | | |
\ / \ /
-------------------------- --------------------------
Figure 1. Model of Operation for RSVP-based admission control over Figure 1. Model of Operation for RSVP-based admission control over
MPLS/BGP VPN MPLS/BGP VPN
To establish a unidirectional reservation for a point-to-point flow To establish a unidirectional reservation for a point-to-point flow
from Sender to Receiver that takes account of resource availability from Sender to Receiver that takes account of resource availability
on the CE-PE and PE-CE links only, the following steps must take on the CE-PE and PE-CE links only, the following steps need to take
place: place:
1. Sender sends a Path message to an IP address of the Receiver. 1. Sender sends a Path message to an IP address of the Receiver.
2. Path message is processed by CE1 using normal RSVP procedures 2. Path message is processed by CE1 using normal RSVP procedures
and forwarded towards the Receiver along the link CE1-PE1. and forwarded towards the Receiver along the link CE1-PE1.
3. PE1 processes Path message and forwards towards the Receiver 3. PE1 processes Path message and forwards towards the Receiver
across the provider backbone. across the provider backbone.
skipping to change at page 8, line 7 skipping to change at page 8, line 42
MPLS VPN environment. For all the remaining steps described in the MPLS VPN environment. For all the remaining steps described in the
preceding section, standard RSVP processing rules apply. preceding section, standard RSVP processing rules apply.
All the procedures described below support both IPv4 and IPv6 All the procedures described below support both IPv4 and IPv6
addressing. In all cases where IPv4 is referenced, IPv6 can be addressing. In all cases where IPv4 is referenced, IPv6 can be
substituted with identical procedures and results. Object substituted with identical procedures and results. Object
definitions for both IPv4 and IPv6 are provided in Section 8. definitions for both IPv4 and IPv6 are provided in Section 8.
3.1. New Objects of Type VPN-IPv4 3.1. New Objects of Type VPN-IPv4
For RSVP signalling within a VPN, certain RSVP objects need to be For RSVP signaling within a VPN, certain RSVP objects need to be
extended. Since customer IP addresses need not be unique, the extended. Since customer IP addresses need not be unique, the
current types of SESSION, SENDER_TEMPLATE and FILTERSPEC objects are current types of SESSION, SENDER_TEMPLATE and FILTERSPEC objects are
no longer sufficient to globally identify RSVP states in P/PE no longer sufficient to globally identify RSVP states in P/PE
routers, since those are currently based on IP addresses. We propose routers, since those are currently based on IP addresses. We propose
new types of SESSION, SENDER_TEMPLATE and FILTERSPEC objects, which new types of SESSION, SENDER_TEMPLATE and FILTERSPEC objects, which
contain globally unique VPN-IPv4 format addresses. The ingress and contain globally unique VPN-IPv4 format addresses. The ingress and
egress PE nodes translate between the regular IPv4 addresses for egress PE nodes translate between the regular IPv4 addresses for
messages to and from the CE, and VPN-IPv4 addresses for messages to messages to and from the CE, and VPN-IPv4 addresses for messages to
and from PE routers. The rules for this translation are described in and from PE routers. The rules for this translation are described in
later sections. later sections.
skipping to change at page 8, line 32 skipping to change at page 9, line 19
separated by Option-B Autonomous System Border Routers -ASBRs) are separated by Option-B Autonomous System Border Routers -ASBRs) are
not required to have direct IP reachability to each other. To solve not required to have direct IP reachability to each other. To solve
this issue, we propose the use of label switching to forward RSVP this issue, we propose the use of label switching to forward RSVP
messages between nodes within a MPLS VPN. This is achieved by messages between nodes within a MPLS VPN. This is achieved by
defining a new VPN-IPv4 RSVP_HOP object. Use of the VPN-IPv4 defining a new VPN-IPv4 RSVP_HOP object. Use of the VPN-IPv4
RSVP_HOP object enables RSVP control plane reachability between any RSVP_HOP object enables RSVP control plane reachability between any
two adjacent RSVP hops in a MPLS VPN (e.g. a PE in AS 1 and a PE in two adjacent RSVP hops in a MPLS VPN (e.g. a PE in AS 1 and a PE in
AS2), regardless of whether they have IP reachability to each other. AS2), regardless of whether they have IP reachability to each other.
The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message
sender and a logical interface handle as before, but in addition sender and a Logical Interface Handle (LIH) as before, but in
carries a VPN-IPv4 address which also represents the sender of the addition carries a VPN-IPv4 address which also represents the sender
message. The message sender MUST also advertise this VPN-IPv4 HOP of the message. The message sender MUST also advertise this VPN-IPv4
address into BGP, associated with a locally allocated label, and this address into BGP, associated with a locally allocated label, and this
advertisement MUST be propagated by BGP throughout the VPN and to advertisement MUST be propagated by BGP throughout the VPN and to
adjacent ASes if required to provide reachability to this PE. Frames adjacent ASes if required to provide reachability to this PE. Frames
received by the PE marked with this label MUST be given to the local received by the PE marked with this label MUST be given to the local
control plane for processing. When a neighboring RSVP hop wishes to control plane for processing. When a neighboring RSVP hop wishes to
reply to a message carrying a VPN-IPv4 RSVP_HOP, it looks for a BGP reply to a message carrying a VPN-IPv4 RSVP_HOP, it looks for a BGP
advertisement of the VPN-IPv4 address contained in that RSVP_HOP. If advertisement of the VPN-IPv4 address contained in that RSVP_HOP. If
this address is found and carries an associated label, the this address is found and carries an associated label, the
neighboring RSVP node MUST encapsulate the RSVP message with this neighboring RSVP node MUST encapsulate the RSVP message with this
label and send it via MPLS encapsulation to the BGP next-hop label and send it via MPLS encapsulation to the BGP next-hop
skipping to change at page 9, line 17 skipping to change at page 10, line 6
where the address is specially created for RSVP signaling (and where the address is specially created for RSVP signaling (and
possibly other control protocols), the BGP advertisement MUST NOT be possibly other control protocols), the BGP advertisement MUST NOT be
redistributed to, or reachable by, any CEs outside the MPLS VPN. One redistributed to, or reachable by, any CEs outside the MPLS VPN. One
way to achieve this is by creating a special "control protocols VPN" way to achieve this is by creating a special "control protocols VPN"
with VRF state on every PE/ASBR, carrying route targets not imported with VRF state on every PE/ASBR, carrying route targets not imported
into customer VRFs. In the case where a customer VRF address is used into customer VRFs. In the case where a customer VRF address is used
as the VPN-IPv4 address, a VPN-IPv4 address in one customer VRF MUST as the VPN-IPv4 address, a VPN-IPv4 address in one customer VRF MUST
NOT be used to signal RSVP messages for a flow in a different VRF. NOT be used to signal RSVP messages for a flow in a different VRF.
If a PE/ASBR is sending a Path message to another PE/ASBR within the If a PE/ASBR is sending a Path message to another PE/ASBR within the
VPN, and it has any appropriate VPN-IPv4 address for signalling that VPN, and it has any appropriate VPN-IPv4 address for signaling that
satisfies the requirements outlined above, it MUST use a VPN-IPv4 HOP satisfies the requirements outlined above, it MUST use a VPN-IPv4
object with this address for all RSVP messages within the VPN. If a RSVP_HOP object with this address for all RSVP messages within the
PE/ASBR does not have any appropriate VPN-IPv4 address to use for VPN. If a PE/ASBR does not have any appropriate VPN-IPv4 address to
signalling, it MAY send the Path message with a regular IPv4 RSVP_HOP use for signaling, it MAY send the Path message with a regular IPv4
object. In this case, the reply will be IP encapsulated. This RSVP_HOP object. In this case, the reply will be IP encapsulated.
option is not preferred because there is no guarantee that the This option is not preferred because there is no guarantee that the
neighboring RSVP hop has IP reachability to the sending node. If a neighboring RSVP hop has IP reachability to the sending node. If a
PE/ASBR receives or originates a Path message with a VPN-IPv4 PE/ASBR receives or originates a Path message with a VPN-IPv4
RSVP_HOP object, any RSVP_HOP object in corresponding upstream RSVP_HOP object, any RSVP_HOP object in corresponding upstream
messages for this flow (e.g. Resv, ResvTear) or downstream messages messages for this flow (e.g. Resv, ResvTear) or downstream messages
(e.g. ResvError, PathTear) sent by this node within the VPN MUST be (e.g. ResvError, PathTear) sent by this node within the VPN MUST be
a VPN-IPv4 RSVP_HOP. a VPN-IPv4 RSVP_HOP.
3.2. Path Message Processing at Ingress PE 3.2. Path Message Processing at Ingress PE
When a Path message arrives at the ingress PE (step 3 of Section 2.1) When a Path message arrives at the ingress PE (step 3 of Section 2.1)
the PE needs to establish suitable Path state and forward the Path the PE needs to establish suitable Path state and forward the Path
message on to the egress PE. In the following paragraphs we message on to the egress PE. In the following paragraphs we
described the steps taken by the ingress PE. described the steps taken by the ingress PE.
The Path message is addressed to the eventual destination (the The Path message is addressed to the eventual destination (the
receiver at the remote customer site) and carries the IP Router Alert receiver at the remote customer site) and carries the IP router alert
option, in accordance with [RFC2205]. The ingress PE must recognize option, in accordance with [RFC2205]. The ingress PE MUST recognize
the router alert, intercept these messages and process them as RSVP the router alert option, intercept these messages and process them as
signalling messages. RSVP signaling messages.
As noted above, there is an issue in recognizing Path messages as As noted above, there is an issue in recognizing Path messages as
they arrive at the egress PE (PE 2 in Figure 1). The approach they arrive at the egress PE (PE 2 in Figure 1). The approach
defined here is to address the Path messages sent by the ingress PE defined here is to address the Path messages sent by the ingress PE
directly to the egress PE, and send it without IP Router Alert; that directly to the egress PE, and send it without IP router alert
is, rather than using the ultimate receiver's destination address as option; that is, rather than using the ultimate receiver's
the destination address of the Path message, we use the loopback destination address as the destination address of the Path message,
address of the egress PE as the destination address of the Path we use the loopback address of the egress PE as the destination
message. This approach has the advantage that it does not require address of the Path message. This approach has the advantage that it
any new data plane capabilities for the egress PE beyond those of a does not require any new data plane capabilities for the egress PE
standard BGP/MPLS VPN PE. Details of the processing of this message beyond those of a standard BGP/MPLS VPN PE. Details of the
at the egress PE are described below in Section 3.3. The approach of processing of this message at the egress PE are described below in
addressing a Path message directly to an RSVP next hop (that may or Section 3.3. The approach of addressing a Path message directly to
may not be the next IP hop) is already used in other environments an RSVP next hop (that may or may not be the next IP hop) is already
such as those of [RFC4206] and [RFC4804]. used in other environments such as those of [RFC4206] and [RFC4804].
The details of operation at the ingress PE are as follows. When the 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 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 addressed to the receiver, the VRF that is associated with the
incoming interface is identified, just as for normal data path incoming interface is identified, just as for normal data path
operations. The Path state for the session is stored, and is operations. The Path state for the session is stored, and is
associated with that VRF, so that potentially overlapping addresses associated with that VRF, so that potentially overlapping addresses
among different VPNs do not appear to belong to the same session. among different VPNs do not appear to belong to the same session.
The destination address of the receiver is looked up in the The destination address of the receiver is looked up in the
appropriate VRF, and the BGP Next-Hop for that destination is appropriate VRF, and the BGP Next-Hop for that destination is
skipping to change at page 10, line 32 skipping to change at page 11, line 20
Distinguisher (RD) that is part of the VPN-IPv4 route prefix for this Distinguisher (RD) that is part of the VPN-IPv4 route prefix for this
destination, and the IPv4 address from the SESSION. In addition, a destination, and the IPv4 address from the SESSION. In addition, a
new VPN-IPv4 SENDER_TEMPLATE object is constructed, with the original new VPN-IPv4 SENDER_TEMPLATE object is constructed, with the original
IPv4 address from the incoming SENDER_TEMPLATE plus the RD that is IPv4 address from the incoming SENDER_TEMPLATE plus the RD that is
used by this PE to advertise that prefix for this customer into the used by this PE to advertise that prefix for this customer into the
VPN. A new Path message is constructed with a destination address VPN. A new Path message is constructed with a destination address
equal to the address of the egress PE identified above. This new equal to the address of the egress PE identified above. This new
Path message will contain all the objects from the original Path Path message will contain all the objects from the original Path
message, replacing the original SESSION and SENDER_TEMPLATE objects message, replacing the original SESSION and SENDER_TEMPLATE objects
with the new VPN-IPv4 type objects. The Path message is sent without with the new VPN-IPv4 type objects. The Path message is sent without
IP Router Alert and contains a RSVP_HOP object constructed as router alert option and contains a RSVP_HOP object constructed as
specified in Section 3.1. specified in Section 3.1.
3.3. Path Message Processing at Egress PE 3.3. Path Message Processing at Egress PE
When a Path message arrives at the egress PE, it is addressed to the 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 extracts PE itself, and is handed to RSVP for processing. The router extracts
the RD and IPv4 address from the VPN-IPv4 SESSION object, and the RD and IPv4 address from the VPN-IPv4 SESSION object, and
determines the local VRF context by finding a matching VPN-IPv4 determines the local VRF context by finding a matching VPN-IPv4
prefix with the specified RD that has been advertised by this router prefix with the specified RD that has been advertised by this router
into BGP. The entire incoming RSVP message, including the VRF into BGP. The entire incoming RSVP message, including the VRF
skipping to change at page 11, line 9 skipping to change at page 11, line 43
Now the RSVP module can construct a Path message which differs from Now the RSVP module can construct a Path message which differs from
the Path it received in the following ways: the Path it received in the following ways:
a. Its destination address is the IP address extracted from the a. Its destination address is the IP address extracted from the
SESSION Object; SESSION Object;
b. The SESSION and SENDER_TEMPLATE objects are converted back to b. The SESSION and SENDER_TEMPLATE objects are converted back to
IPv4-type by discarding the attached RD IPv4-type by discarding the attached RD
c. The RSVP_HOP Object contains the IP address of the outgoing c. The RSVP_HOP Object contains the IP address of the outgoing
interface of the egress PE and an LIH, as per normal RSVP interface of the egress PE and a Logical Interface Handle (LIH),
processing. as per normal RSVP processing.
The router then sends the Path message on towards its destination The router then sends the Path message on towards its destination
over the interface identified above. This Path message carries the over the interface identified above. This Path message carries the
IP Router-Alert option as required by [RFC2205]. router alert option as required by [RFC2205].
3.4. Resv Processing at Egress PE 3.4. Resv Processing at Egress PE
When a receiver at the customer site originates a Resv message for When a receiver at the customer site originates a Resv message for
the session, normal RSVP procedures apply until the Resv, making its the session, normal RSVP procedures apply until the Resv, making its
way back towards the sender, arrives at the "egress" PE (it is 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 "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 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 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, find the matching Path state stored previously. At this stage,
skipping to change at page 12, line 14 skipping to change at page 12, line 52
the ingress CE will contain IPv4 SESSION and FILTER_SPEC objects, the ingress CE will contain IPv4 SESSION and FILTER_SPEC objects,
derived from the appropriate Path state. Since we assume in this derived from the appropriate Path state. Since we assume in this
section that admission control over the Provider's backbone is not section that admission control over the Provider's backbone is not
needed, the ingress PE does not perform any admission control for needed, the ingress PE does not perform any admission control for
this reservation. this reservation.
3.6. Other RSVP Messages 3.6. Other RSVP Messages
Processing of PathError, PathTear, ResvError, ResvTear and ResvConf Processing of PathError, PathTear, ResvError, ResvTear and ResvConf
messages is generally straightforward and follows the rules of messages is generally straightforward and follows the rules of
[RFC2205]. These additional rules must be observed for messages [RFC2205]. These additional rules MUST be observed for messages
transmitted within the VPN (i.e. between the PEs): transmitted within the VPN (i.e. Between the PEs):
o The SESSION, SENDER_TEMPLATE and FILTER_SPEC objects must be o The SESSION, SENDER_TEMPLATE and FILTER_SPEC objects MUST be
converted from IPv4 to VPN-IPv4 form and back in the same manner converted from IPv4 to VPN-IPv4 form and back in the same manner
as described above for Path and Resv messages. as described above for Path and Resv messages.
o The appropriate type of RSVP_HOP object (VPN-IPv4 or IPv4) must be o The appropriate type of RSVP_HOP object (VPN-IPv4 or IPv4) MUST be
used as described above used as described above.
o Depending on the type of RSVP HOP received from the neighbor, the o Depending on the type of RSVP_HOP object received from the
message must be MPLS-encapsulated or IP-encapsulated as described neighbor, the message MUST be MPLS-encapsulated or IP-encapsulated
above as described above.
o The matching state & VRF must be determined by decoding the RD and o The matching state & VRF MUST be determined by decoding the RD and
IPv4 addresses in the SESSION and FILTER_SPEC objects. IPv4 addresses in the SESSION and FILTER_SPEC objects.
o The message must be directly addressed to the appropriate PE, o The message MUST be directly addressed to the appropriate PE,
without using the IP Router Alert option. without using the router alert option.
4. Admission Control in Provider's Backbone 4. Admission Control in Provider's Backbone
The preceding section outlines how per-customer reservations can be The preceding section outlines how per-customer reservations can be
made over the PE-CE links. This may be sufficient in many situations made over the PE-CE links. This may be sufficient in many situations
where the backbone is well engineered with ample capacity and there where the backbone is well engineered with ample capacity and there
is no need to perform any sort of admission control in the backbone. is no need to perform any sort of admission control in the backbone.
However, in some cases where excess capacity cannot be relied upon However, in some cases where excess capacity cannot be relied upon
(e.g., during failures or unanticipated periods of overload) it may (e.g., during failures or unanticipated periods of overload) it may
be desirable to be able to perform admission control in the backbone be desirable to be able to perform admission control in the backbone
skipping to change at page 14, line 28 skipping to change at page 15, line 17
RD and a matching prefix. RD and a matching prefix.
The provider(s) who interconnect ASes using option B may or may not The provider(s) who interconnect ASes using option B may or may not
desire to perform admission control on the inter-AS links. This desire to perform admission control on the inter-AS links. This
choice affects the detailed operation of ASBRs. We describe the two choice affects the detailed operation of ASBRs. We describe the two
modes of operation - with and without admission control at the ASBRs modes of operation - with and without admission control at the ASBRs
- in the following sections. - in the following sections.
5.2.1. Admission control on ASBR 5.2.1. Admission control on ASBR
In this scenario, the ASBR performs full RSVP signalling and In this scenario, the ASBR performs full RSVP signaling and admission
admission control. The RSVP database is indexed on the ASBR using control. The RSVP database is indexed on the ASBR using the VPN-IPv4
the VPN-IPv4 SESSION, SENDER_TEMPLATE and FILTER_SPEC objects (which SESSION, SENDER_TEMPLATE and FILTER_SPEC objects (which uniquely
uniquely identify RSVP sessions and flows as per the requirements of identify RSVP sessions and flows as per the requirements of
[RFC2205]). These objects are forwarded unmodified in both [RFC2205]). These objects are forwarded unmodified in both
directions by the ASBR. All other procedures of RSVP are performed directions by the ASBR. All other procedures of RSVP are performed
as if the ASBR was a RSVP hop. In particular, the RSVP_HOP objects as if the ASBR was a RSVP hop. In particular, the RSVP_HOP objects
sent in Path and Resv messages contain IP addresses of the ASBR, sent in Path and Resv messages contain IP addresses of the ASBR,
which MUST be reachable by the neighbor to whom the message is being which MUST be reachable by the neighbor to whom the message is being
sent. Note that since the VPN-IPv4 SESSION, SENDER_TEMPLATE and sent. Note that since the VPN-IPv4 SESSION, SENDER_TEMPLATE and
FILTER_SPEC objects satisfy the uniqueness properties required for a FILTER_SPEC objects satisfy the uniqueness properties required for a
RSVP database implementation as per [RFC2209], no customer VRF RSVP database implementation as per [RFC2209], no customer VRF
awareness is required on the ASBR. awareness is required on the ASBR.
5.2.2. No admission control on ASBR 5.2.2. No admission control on ASBR
If the ASBR is not doing admission control, it is desirable that per- If the ASBR is not doing admission control, it is desirable that per-
flow state not be maintained on the ASBR. This requires adjacent flow state not be maintained on the ASBR. This requires adjacent
RSVP hops (i.e. the ingress and egress PEs of the respective ASes) to RSVP hops (i.e. The ingress and egress PEs of the respective ASes)
send RSVP messages directly between them. This is only possible if to send RSVP messages directly between them. This is only possible
they are MPLS-encapsulated. The use of the VPN-IPv4 HOP object if they are MPLS-encapsulated. The use of the VPN-IPv4 RSVP_HOP
described in Section 3.1 is REQUIRED in this case. object described in Section 3.1 is REQUIRED in this case.
When an ASBR that is not installing local RSVP state receives a Path When an ASBR that is not installing local RSVP state receives a Path
message, it looks up the next-hop of the matching BGP route as message, it looks up the next-hop of the matching BGP route as
described in Section 3.2, and sends the Path message to the next-hop, described in Section 3.2, and sends the Path message to the next-hop,
without modifying any RSVP objects (including the RSVP_HOP). This without modifying any RSVP objects (including the RSVP_HOP). This
process is repeated at subsequent ASBRs until the Path message process is repeated at subsequent ASBRs until the Path message
arrives at a router that is installing local RSVP state (either the arrives at a router that is installing local RSVP state (either the
ultimate egress PE, or an ASBR configured to perform admission ultimate egress PE, or an ASBR configured to perform admission
control). This router receives the Path and processes it as control). This router receives the Path and processes it as
described in Section 3.3 if it is a PE, or Section 5.2.1 if it is an described in Section 3.3 if it is a PE, or Section 5.2.1 if it is an
skipping to change at page 15, line 24 skipping to change at page 16, line 13
VPN-IPv4 address in the PHOP, encapsulates the Resv with that label VPN-IPv4 address in the PHOP, encapsulates the Resv with that label
and sends it upstream. This message will be received for control and sends it upstream. This message will be received for control
processing directly on the upstream RSVP hop (that last updated the processing directly on the upstream RSVP hop (that last updated the
RSVP_HOP field in the Path message), without any involvement of RSVP_HOP field in the Path message), without any involvement of
intermediate ASBRs. intermediate ASBRs.
The ASBR is not expected to process any other RSVP messages apart The ASBR is not expected to process any other RSVP messages apart
from the Path message as described above. The ASBR also does not from the Path message as described above. The ASBR also does not
need to store any RSVP state. Note that any ASBR along the path that need to store any RSVP state. Note that any ASBR along the path that
wishes to do admission control or insert itself into the RSVP wishes to do admission control or insert itself into the RSVP
signalling flow, may do so by writing its own RSVP_HOP object with signaling flow, may do so by writing its own RSVP_HOP object with
IPv4 and VPN-IPv4 address pointing to itself. IPv4 and VPN-IPv4 address pointing to itself.
If an Option-B ASBR receives a RSVP Path message with an IPv4 If an Option-B ASBR receives a RSVP Path message with an IPv4
RSVP_HOP, does not wish to perform admission control but is willing RSVP_HOP, does not wish to perform admission control but is willing
to install local state for this flow, the ASBR MUST process and to install local state for this flow, the ASBR MUST process and
forward RSVP signalling messages for this flow as described in forward RSVP signaling messages for this flow as described in
Section 5.2.1 (with the exception that it does not perform admission Section 5.2.1 (with the exception that it does not perform admission
control). If an Option-B ASBR receives a RSVP Path message with an control). If an Option-B ASBR receives a RSVP Path message with an
IPv4 RSVP_HOP, but does not wish to install local state or perform IPv4 RSVP_HOP, but does not wish to install local state or perform
admission control for this flow, the ASBR MUST NOT forward the Path admission control for this flow, the ASBR MUST NOT forward the Path
message. In addition, the ASBR SHOULD send a PathError message of message. In addition, the ASBR SHOULD send a PathError message of
Error Code "RSVP over MPLS Problem"_, _Error Value "RSVP_HOP not Error Code "RSVP over MPLS Problem" and Error Value "RSVP_HOP not
reachable across VPN" (see Section 9) signifying to the upstream RSVP reachable across VPN" (see Section 9) signifying to the upstream RSVP
hop that the supplied RSVP_HOP object is insufficient to provide hop that the supplied RSVP_HOP object is insufficient to provide
reachability across this VPN. This failure condition is not expected reachability across this VPN. This failure condition is not expected
to be recoverable. to be recoverable.
5.3. Inter-AS Option C 5.3. Inter-AS Option C
Operation of RSVP in Inter-AS Option C is also quite straightforward, Operation of RSVP in Inter-AS Option C is also quite straightforward,
because there exists an LSP directly from ingress PE to egress PE. because there exists an LSP directly from ingress PE to egress PE.
In this case, there is no significant difference in operation from In this case, there is no significant difference in operation from
skipping to change at page 16, line 31 skipping to change at page 17, line 20
Note also that this guidance applies regardless of whether RSVP-TE is Note also that this guidance applies regardless of whether RSVP-TE is
used in some, all, or none of the L3VPN network. used in some, all, or none of the L3VPN network.
7. Other RSVP procedures 7. Other RSVP procedures
This section describes modifications to other RSVP procedures This section describes modifications to other RSVP procedures
introduced by MPLS VPNs introduced by MPLS VPNs
7.1. Refresh overhead reduction 7.1. Refresh overhead reduction
The following points should be noted regarding RSVP refresh overhead The following points ought to be noted regarding RSVP refresh
reduction ([RFC2961]) across a MPLS VPN: overhead reduction ([RFC2961]) across a MPLS VPN:
o The hop between the ingress and egress PE of a VPN should be o The hop between the ingress and egress PE of a VPN is to be
considered as traversing one or more non-RSVP hops. As such, the considered as traversing one or more non-RSVP hops. As such, the
procedures described in Section 5.3 of [RFC2961] relating to non- procedures described in Section 5.3 of [RFC2961] relating to non-
RSVP hops SHOULD be followed. RSVP hops SHOULD be followed.
o The source IP address of a SRefresh message MUST match the IPv4 o The source IP address of a SRefresh message MUST match the IPv4
address signalled in the RSVP_HOP object contained in the address signalled in the RSVP_HOP object contained in the
corresponding Path or Resv message. The IPv4 address in any corresponding Path or Resv message. The IPv4 address in any
received VPN-IPv4 RSVP_HOP object MUST be used as the source received VPN-IPv4 RSVP_HOP object MUST be used as the source
address of that message for this purpose. address of that message for this purpose.
7.2. Cryptographic Authentication 7.2. Cryptographic Authentication
The following points should be noted regarding RSVP cryptographic The following points ought to be noted regarding RSVP cryptographic
authentication ([RFC2747]) across a MPLS VPN: authentication ([RFC2747]) across a MPLS VPN:
o The IPv4 address in any received VPN-IPv4 RSVP_HOP object MUST be o The IPv4 address in any received VPN-IPv4 RSVP_HOP object MUST be
used as the source address of that message for purposes of used as the source address of that message for purposes of
identifying the security association. identifying the security association.
o Forwarding of Challenge and Response messages MUST follow the same o Forwarding of Challenge and Response messages MUST follow the same
rules as described above for hop-by-hop messages. Specifically, rules as described above for hop-by-hop messages. Specifically,
if the originator of a Challenge/Response message has received a if the originator of a Challenge/Response message has received a
VPN-IPv4 RSVP_HOP object from the corresponding neighbor, it MUST VPN-IPv4 RSVP_HOP object from the corresponding neighbor, it MUST
use the label associated with that VPN-IPv4 address in BGP to use the label associated with that VPN-IPv4 address in BGP to
forward the Challenge/Response message. forward the Challenge/Response message.
7.3. RSVP Aggregation 7.3. RSVP Aggregation
[RFC3175] and [RFC4860] describe mechanisms to aggregate multiple [RFC3175] and [RFC4860] describe mechanisms to aggregate multiple
individual RSVP reservations into a single larger reservation on the individual RSVP reservations into a single larger reservation on the
basis of a common DSCP/PHB for traffic classification. The following basis of a common DSCP/PHB for traffic classification. The following
points should be noted in this regard: points ought to be noted in this regard:
o The procedures described in this section apply only in the case o The procedures described in this section apply only in the case
where the Aggregator and Deaggregator nodes are C/CE devices, and where the Aggregator and Deaggregator nodes are C/CE devices, and
the entire MPLS VPN lies within the Aggregation Region. The case the entire MPLS VPN lies within the Aggregation Region. The case
where the PE is also an Aggregator/Deaggregator is more complex where the PE is also an Aggregator/Deaggregator is more complex
and not considered in this document. and not considered in this document.
o Aggregate RSVP sessions will be treated in the same way as regular o Support of Aggregate RSVP sessions is OPTIONAL. When supported:
IPv4 RSVP sessions. To this end, all the procedures described in
Section 3 and Section 4 apply to aggregate RSVP sessions. New
SESSION, SENDER_TEMPLATE and FILTERSPEC objects are defined in
Section 8.
o End-To-End (E2E) RSVP sessions are passed unmodified through the * Aggregate RSVP sessions MUST be treated in the same way as
MPLS VPN. These RSVP messages may be identified by their IP regular IPv4 RSVP sessions. To this end, all the procedures
protocol (RSVP-E2E-IGNORE, 134). When the ingress PE receives any described in Section 3 and Section 4 MUST be followed for
RSVP message with this IP protocol, it MUST process this frame as aggregate RSVP sessions. The corresponding new SESSION,
if it is regular customer traffic and ignore any IP Router-Alert SENDER_TEMPLATE and FILTERSPEC objects are defined in
flags. The appropriate VPN and transport labels are applied to Section 8.
the frame and it is forwarded towards the remote CE. Note that
this message will not be received or processed by any other P or
PE node.
o Any SESSION-OF-INTEREST objects (defined in [RFC4860]) are to be * End-To-End (E2E) RSVP sessions are passed unmodified through
conveyed unmodified across the MPLS VPN. the MPLS VPN. These RSVP messages SHOULD be identified by
their IP protocol (RSVP-E2E-IGNORE, 134). When the ingress PE
receives any RSVP message with this IP protocol, it MUST
process this frame as if it is regular customer traffic and
ignore any router alert option. The appropriate VPN and
transport labels are applied to the frame and it is forwarded
towards the remote CE. Note that this message will not be
received or processed by any other P or PE node.
* Any SESSION-OF-INTEREST object (defined in [RFC4860]) MUST be
conveyed unmodified across the MPLS VPN.
7.4. Support for CE-CE RSVP-TE 7.4. Support for CE-CE RSVP-TE
[I-D.ietf-l3vpn-e2e-rsvp-te-reqts] describes a set of requirements [I-D.ietf-l3vpn-e2e-rsvp-te-reqts] describes a set of requirements
for the establishment for CE-CE MPLS LSPs across networks offering an for the establishment for CE-CE MPLS LSPs across networks offering an
L3VPN service. The requirements specified in that draft are similar L3VPN service. The requirements specified in that document are
to those addressed by this document, in that both address the issue similar to those addressed by this document, in that both address the
of handling RSVP requests from customers in a VPN context. It is issue of handling RSVP requests from customers in a VPN context. It
possible that the solution described here could be adapted to meet is possible that the solution described here could be adapted to meet
the requirements of [I-D.ietf-l3vpn-e2e-rsvp-te-reqts]. To the the requirements of [I-D.ietf-l3vpn-e2e-rsvp-te-reqts]. To the
extent that this draft uses signalling extensions described in extent that this document uses signaling extensions described in
[RFC3473] which have already been used for GMPLS/TE, we expect that [RFC3473] which have already been used for GMPLS/TE, we expect that
CE-CE RSVP/TE will be incremental work built on these extensions. CE-CE RSVP/TE will be incremental work built on these extensions.
These extensions will be considered in a separate document. These extensions will be considered in a separate document.
8. Object Definitions 8. Object Definitions
8.1. VPN-IPv4 and VPN-IPv6 SESSION objects 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects
The usage of the VPN-IPv4 (or VPN-IPv6) SESSION Object is described The usage of the VPN-IPv4 (or VPN-IPv6) SESSION Object is described
in Section 3.2 to Section 3.6. The VPN-IPv4 (or VPN-IPv6) SESSION in Section 3.2 to Section 3.6. The VPN-IPv4 (or VPN-IPv6) SESSION
skipping to change at page 20, line 41 skipping to change at page 21, line 41
The VPN-IPv4 SrcAddress (respectively VPN-IPv6 SrcAddress) field The VPN-IPv4 SrcAddress (respectively VPN-IPv6 SrcAddress) field
contains an address of the VPN-IPv4 (respectively VPN-IPv6) address contains an address of the VPN-IPv4 (respectively VPN-IPv6) address
family encoded as specified in [RFC4364] (respectively [RFC4659]). family encoded as specified in [RFC4364] (respectively [RFC4659]).
The content of this field is discussed in Section 3.2 and The content of this field is discussed in Section 3.2 and
Section 3.3. Section 3.3.
The SrcPort is identical to the SrcPort field in the IPv4 and IPv6 The SrcPort is identical to the SrcPort field in the IPv4 and IPv6
SENDER_TEMPLATE objects ([RFC2205]). SENDER_TEMPLATE objects ([RFC2205]).
The Reserved field must be set to zero on transmit and ignored on The Reserved field MUST be set to zero on transmit and ignored on
receipt. receipt.
8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects
The usage of the VPN-IPv4 (or VPN-IPv6) FILTER_SPEC Object is The usage of the VPN-IPv4 (or VPN-IPv6) FILTER_SPEC Object is
described in Section 3.4 and Section 3.5. The VPN-IPv4 (or VPN-IPv6) described in Section 3.4 and Section 3.5. The VPN-IPv4 (or VPN-IPv6)
FILTER_SPEC object appears in RSVP messages that ordinarily contain a FILTER_SPEC object appears in RSVP messages that ordinarily contain a
FILTER_SPEC object and are sent between ingress PE and egress PE in FILTER_SPEC object and are sent between ingress PE and egress PE in
either direction (such as Resv, ResvError, and ResvTear). The object either direction (such as Resv, ResvError, and ResvTear). The object
MUST NOT be included in any RSVP messages that are sent outside of MUST NOT be included in any RSVP messages that are sent outside of
skipping to change at page 21, line 23 skipping to change at page 22, line 23
o VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = TBA o VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = TBA
Definition same as VPN-IPv6 SENDER_TEMPLATE object. Definition same as VPN-IPv6 SENDER_TEMPLATE object.
The content of the VPN-IPv4 SrcAddress (or VPN-IPv6 SrcAddress) field The content of the VPN-IPv4 SrcAddress (or VPN-IPv6 SrcAddress) field
is discussed in Section 3.4 and Section 3.5. is discussed in Section 3.4 and Section 3.5.
The SrcPort is identical to the SrcPort field in the IPv4 and IPv6 The SrcPort is identical to the SrcPort field in the IPv4 and IPv6
SENDER_TEMPLATE objects ([RFC2205]). SENDER_TEMPLATE objects ([RFC2205]).
The Reserved field must be set to zero on transmit and ignored on The Reserved field MUST be set to zero on transmit and ignored on
receipt. receipt.
8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects
Usage of the VPN-IPv4 (or VPN-IPv6) RSVP_HOP Object is described in Usage of the VPN-IPv4 (or VPN-IPv6) RSVP_HOP Object is described in
Section 3.1 and Section 5.2.2. The VPN-IPv4 (VPN-IPv6) RSVP_HOP Section 3.1 and Section 5.2.2. The VPN-IPv4 (VPN-IPv6) RSVP_HOP
object is used to establish signalling reachability between RSVP object is used to establish signaling reachability between RSVP
neighbors separated by one or more Option-B ASBRs. This object may neighbors separated by one or more Option-B ASBRs. This object may
appear in RSVP messages that carry a RSVP_HOP object, and that travel appear in RSVP messages that carry a RSVP_HOP object, and that travel
between the Ingress and Egress PEs. It MUST NOT be included in any between the Ingress and Egress PEs. It MUST NOT be included in any
RSVP messages that are sent outside of the provider's backbone RSVP messages that are sent outside of the provider's backbone
(except in the inter-AS option B and C cases, as described above, (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 when it may appear on inter-AS links). The format of the object is
as follows: as follows:
o VPN-IPv4 RSVP_HOP object: Class = 3, C-Type = TBA o VPN-IPv4 RSVP_HOP object: Class = 3, C-Type = TBA
skipping to change at page 23, line 34 skipping to change at page 24, line 34
o AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = TBA o AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = TBA
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| VPN-IPv4 DestAddress (12 bytes) | | VPN-IPv4 DestAddress (12 bytes) |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| /////// | Flags | /////// | DSCP | | Reserved | Flags | Reserved | DSCP |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
o AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = TBA o AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = TBA
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ VPN-IPv6 DestAddress (24 bytes) + + VPN-IPv6 DestAddress (24 bytes) +
/ / / /
skipping to change at page 24, line 27 skipping to change at page 25, line 27
| Reserved | Flags | Reserved | DSCP | | Reserved | Flags | Reserved | DSCP |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field
contains an address of the VPN-IPv4 (respectively VPN-IPv6) address contains an address of the VPN-IPv4 (respectively VPN-IPv6) address
family encoded as specified in [RFC4364] (respectively [RFC4659]). family encoded as specified in [RFC4364] (respectively [RFC4659]).
The content of this field is discussed in Section 3.2 and The content of this field is discussed in Section 3.2 and
Section 3.3. Section 3.3.
The flags and DSCP are identical to the same fields of the AGGREGATE- The flags and DSCP are identical to the same fields of the AGGREGATE-
IPv4 and AGGREGATE-IPv6 SESSION objects ([RFC3175],). IPv4 and AGGREGATE-IPv6 SESSION objects ([RFC3175]).
The Reserved field MUST be set to zero on transmit and ignored on
receipt.
o GENERIC-AGGREGATE-VPN-IPv4 SESSION object: o GENERIC-AGGREGATE-VPN-IPv4 SESSION object:
Class = 1, C-Type = TBA Class = 1, C-Type = TBA
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| VPN-IPv4 DestAddress (12 bytes) | | VPN-IPv4 DestAddress (12 bytes) |
+ + + +
| | | |
skipping to change at page 25, line 35 skipping to change at page 26, line 35
The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field
contains an address of the VPN-IPv4 (respectively VPN-IPv6) address contains an address of the VPN-IPv4 (respectively VPN-IPv6) address
family encoded as specified in [RFC4364] (respectively [RFC4659]). family encoded as specified in [RFC4364] (respectively [RFC4659]).
The content of this field is discussed in Section 3.2 and The content of this field is discussed in Section 3.2 and
Section 3.3. Section 3.3.
The flags, PHB-ID, vDstPort and Extended vDstPort are identical to The flags, PHB-ID, vDstPort and Extended vDstPort are identical to
the same fields of the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE- the same fields of the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE-
IPv6 SESSION objects ([RFC4860]). IPv6 SESSION objects ([RFC4860]).
The Reserved field MUST be set to zero on transmit and ignored on
receipt.
8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 SENDER_TEMPLATE objects 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 SENDER_TEMPLATE objects
The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object
is described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively is described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively
AGGREGATE-VPN-IPv6) SENDER_TEMPLATE object appears in RSVP messages AGGREGATE-VPN-IPv6) SENDER_TEMPLATE object appears in RSVP messages
that ordinarily contain a AGGREGATE-IPv4 (respectively AGGREGATE- that ordinarily contain a AGGREGATE-IPv4 (respectively AGGREGATE-
IPv6) SENDER_TEMPLATE object as defined in [RFC3175] and [RFC4860], IPv6) SENDER_TEMPLATE object as defined in [RFC3175] and [RFC4860],
and are sent between ingress PE and egress PE in either direction. and are sent between ingress PE and egress PE in either direction.
These objects MUST NOT be included in any RSVP messages that are sent These objects MUST NOT be included in any RSVP messages that are sent
outside of the provider's backbone (except in the inter-AS option B outside of the provider's backbone (except in the inter-AS option B
skipping to change at page 29, line 41 skipping to change at page 30, line 41
Class Types or C-Types: Class Types or C-Types:
.. ... ... .. ... ...
aa VPN-IPv4 [RFCXXXX] aa VPN-IPv4 [RFCXXXX]
bb VPN-IPv6 [RFCXXXX] bb VPN-IPv6 [RFCXXXX]
[Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC
number of this specification. Suggested values: aa-bb=5-6] number of this specification. Suggested values: aa-bb=5-6]
In addition, a new PathError code/value is required to identify a In addition, a new PathError code/value is required to identify a
signalling reachability failure and the need for a VPN-IPv4 or VPN- signaling reachability failure and the need for a VPN-IPv4 or VPN-
IPv6 RSVP_HOP object as described in Section 5.2.2. Therefore, this IPv6 RSVP_HOP object as described in Section 5.2.2. Therefore, this
document requests IANA to modify the RSVP parameters registry, 'Error document requests IANA to modify the RSVP parameters registry, 'Error
Codes and Globally-Defined Error Value Sub-Codes' subregistry, and: Codes and Globally-Defined Error Value Sub-Codes' subregistry, and:
o assign a new Error Code and sub-code, as suggested below: o assign a new Error Code and sub-code, as suggested below:
aa RSVP over MPLS Problem [RFCXXXX] aa RSVP over MPLS Problem [RFCXXXX]
This Error Code has the following globally-defined Error This Error Code has the following globally-defined Error
Value sub-codes: Value sub-codes:
skipping to change at page 30, line 31 skipping to change at page 31, line 31
Those protect RSVP message integrity hop-by-hop and provide node Those protect RSVP message integrity hop-by-hop and provide node
authentication as well as replay protection, thereby protecting authentication as well as replay protection, thereby protecting
against corruption and spoofing of RSVP messages. against corruption and spoofing of RSVP messages.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of
various keying approaches for RSVP Authentication. First, we note various keying approaches for RSVP Authentication. First, we note
that the discussion about applicability of group keying to an intra- that the discussion about applicability of group keying to an intra-
provider environment where RSVP hops are not IP hops is relevant to provider environment where RSVP hops are not IP hops is relevant to
securing of RSVP among PEs of a given Service Provider deploying the securing of RSVP among PEs of a given Service Provider deploying the
solution specified in the present document. We note that the RSVP solution specified in the present document. We note that the RSVP
signaling in MPLS VPN is likely to spread over multiple signaling in MPLS VPN is likely to spread over multiple
administrative domains (e.g. the service provider operating the VPN administrative domains (e.g. The service provider operating the VPN
service, and the customers of the service). Therefore the service, and the customers of the service). Therefore the
considerations in [I-D.ietf-tsvwg-rsvp-security-groupkeying] about considerations in [I-D.ietf-tsvwg-rsvp-security-groupkeying] about
inter-domain issues are likely to apply. inter-domain issues are likely to apply.
Since RSVP messages travel through the L3VPN cloud directly addressed Since RSVP messages travel through the L3VPN cloud directly addressed
to PE or ASBR routers (without IP Router-Alert), P routers remain to PE or ASBR routers (without IP router alert option), P routers
isolated from RSVP messages signalling customer reservations. remain isolated from RSVP messages signaling customer reservations.
Providers MAY choose to block PEs from sending IP Router-Alert Providers MAY choose to block PEs from sending datagrams with the
datagrams to P routers as a security practice, without impacting the router alert option to P routers as a security practice, without
functionality described herein. impacting the functionality described herein.
Beyond those general issues, four specific issues are introduced by Beyond those general issues, four specific issues are introduced by
this document: resource usage on PEs, resource usage in the provider this document: resource usage on PEs, resource usage in the provider
backbone, PE route advertisement outside the AS, and signalling backbone, PE route advertisement outside the AS, and signaling
exposure to ASBRs and PEs. We discuss these in turn. exposure to ASBRs and PEs. We discuss these in turn.
A customer who makes resource reservations on the CE-PE links for his A customer who makes resource reservations on the CE-PE links for his
sites is only competing for link resources with himself, as in 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 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 dedicated to a single customer. Thus, from the perspective of the
CE-PE links, this draft does not introduce any new security issues. CE-PE links, the present document does not introduce any new security
However, because a PE typically serves multiple customers, there is issues. However, because a PE typically serves multiple customers,
also the possibility that a customer might attempt to use excessive there is also the possibility that a customer might attempt to use
computational resources on a PE (CPU cycles, memory etc.) by sending excessive computational resources on a PE (CPU cycles, memory etc.)
large numbers of RSVP messages to a PE. In the extreme this could by sending large numbers of RSVP messages to a PE. In the extreme
represent a form of denial-of-service attack. In order to prevent this could represent a form of denial-of-service attack. In order to
such an attack, a PE SHOULD support mechanisms to limit the fraction prevent such an attack, a PE SHOULD support mechanisms to limit the
of its processing resources that can be consumed by any one CE or by fraction of its processing resources that can be consumed by any one
the set of CEs of a given customer. For example, a PE might 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 implement a form of rate limiting on RSVP messages that it receives
from each CE. We observe that these security risks and measures from each CE. We observe that these security risks and measures
related to PE resource usage are very similar for any control plane related to PE resource usage are very similar for any control plane
protocol operating between CE and PE (e.g. RSVP, routing, multicast) protocol operating between CE and PE (e.g. RSVP, routing,
multicast).
The second concern arises only when the service provider chooses to The second concern arises only when the service provider chooses to
offer resource reservation across the backbone, as described in offer resource reservation across the backbone, as described in
Section 4. In this case, the concern may be that a single customer Section 4. In this case, the concern may be that a single customer
might attempt to reserve a large fraction of backbone capacity, might attempt to reserve a large fraction of backbone capacity,
perhaps with a co-ordinated effort from several different CEs, thus perhaps with a co-ordinated effort from several different CEs, thus
denying service to other customers using the same backbone. denying service to other customers using the same backbone.
[RFC4804] provides some guidance on the security issues when RSVP [RFC4804] provides some guidance on the security issues when RSVP
reservations are aggregated onto MPLS tunnels, which are applicable reservations are aggregated onto MPLS tunnels, which are applicable
to the situation described here. We note that a provider MAY use 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 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 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 be used to control the resource usage of a given customer across
multiple PEs if desired. It is RECOMMENDED that an implementation of multiple PEs if desired. It is RECOMMENDED that an implementation of
this specification support local policy on the PE to control the this specification support local policy on the PE to control the
amount of resources that can be reserved by a given customer/CE. amount of resources that can be reserved by a given customer/CE.
Use of the VPN-IPv4 HOP object requires exporting a PE VPN-IPv4 route Use of the VPN-IPv4 RSVP_HOP object requires exporting a PE VPN-IPv4
to another AS, and potentially could allow unchecked access to remote route to another AS, and potentially could allow unchecked access to
PEs if those routes were indiscriminately redistributed. However, as remote PEs if those routes were indiscriminately redistributed.
described in Section 3.1, no route which is not within a customer's However, as described in Section 3.1, no route which is not within a
VPN should ever be advertised to (or reachable from) that customer. customer's VPN should ever be advertised to (or reachable from) that
If a PE uses a local address already within a customer VRF (like customer. If a PE uses a local address already within a customer VRF
PE-CE link address), it MUST NOT send this address in any RSVP (like PE-CE link address), it MUST NOT send this address in any RSVP
messages in a different customer VRF. A "control plane" VPN MAY be messages in a different customer VRF. A "control plane" VPN MAY be
created across PEs and ASBRs and addresses in this VPN can be used to created across PEs and ASBRs and addresses in this VPN can be used to
signal RSVP sessions for any customers, but these routes MUST NOT be signal RSVP sessions for any customers, but these routes MUST NOT be
advertised to, or made reachable from, any customer. An advertised to, or made reachable from, any customer. An
implementation of the present document MAY support such operation implementation of the present document MAY support such operation
using a "control plane" VPN. Alternatively, ASBRs MAY implement the using a "control plane" VPN. Alternatively, ASBRs MAY implement the
signalling procedures described in Section 5.2.1, even if admission signaling procedures described in Section 5.2.1, even if admission
control is not required on the inter-AS link, as these procedures do control is not required on the inter-AS link, as these procedures do
not require any direct P/PE route advertisement out of the AS. not require any direct P/PE route advertisement out of the AS.
Finally, certain operations described herein (Section 3) require an Finally, certain operations described herein (Section 3) require an
ASBR or PE to receive and locally process a signalling packet ASBR or PE to receive and locally process a signaling packet
addressed to the BGP next-hop address advertised by that router. addressed to the BGP next-hop address advertised by that router.
This requirement does not strictly apply to MPLS/BGP VPNs [RFC4364]. This requirement does not strictly apply to MPLS/BGP VPNs [RFC4364].
This could be viewed as opening ASBRs and PEs to being directly This could be viewed as opening ASBRs and PEs to being directly
addressable by customer devices where they were not open before, and addressable by customer devices where they were not open before, and
could be considered a security issue. If a provider wishes to could be considered a security issue. If a provider wishes to
mitigate this situation, the implementation MAY support the "control mitigate this situation, the implementation MAY support the "control
protocol VPN" approach described above. That is, whenever a protocol VPN" approach described above. That is, whenever a
signalling message is to be sent to a PE or ASBR, the address of the signaling message is to be sent to a PE or ASBR, the address of the
router in question would be looked up in the "control protocol VPN", router in question would be looked up in the "control protocol VPN",
and the message would then be sent on the LSP that is found as a and the message would then be sent on the LSP that is found as a
result of that lookup. This would ensure that the router address is result of that lookup. This would ensure that the router address is
not reachable by customer devices. not reachable by customer devices.
[RFC4364] mentions use of IPsec both on a CE-CE basis and PE-PE [RFC4364] mentions use of IPsec both on a CE-CE basis and PE-PE
basis: "Cryptographic privacy is not provided by this architecture, basis: "Cryptographic privacy is not provided by this architecture,
nor by Frame Relay or ATM VPNs. These architectures are all nor by Frame Relay or ATM VPNs. These architectures are all
compatible with the use of cryptography on a CE-CE basis, if that is compatible with the use of cryptography on a CE-CE basis, if that is
desired. The use of cryptography on a PE-PE basis is for further desired. The use of cryptography on a PE-PE basis is for further
skipping to change at page 32, line 49 skipping to change at page 33, line 50
individual RSVP reservations are admitted/aggregated over the tunnel individual RSVP reservations are admitted/aggregated over the tunnel
reservation. This model applies to the case where IPsec is used on a reservation. This model applies to the case where IPsec is used on a
CE-CE basis. In that situation, the procedures defined in the CE-CE basis. In that situation, the procedures defined in the
present document would simply apply "as is" to the reservation present document would simply apply "as is" to the reservation
established for the IPsec tunnel(s). established for the IPsec tunnel(s).
11. Acknowledgments 11. Acknowledgments
Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric
Rosen, Dan Tappan and Lou Berger for their many contributions to Rosen, Dan Tappan and Lou Berger for their many contributions to
solving the problems described in this draft. Thanks to Ferit solving the problems described in this document. Thanks to Ferit
Yegenoglu for his useful comments. We also thank Stefan Santesson Yegenoglu for his useful comments. We also thank Stefan Santesson
and Vijay Gurbani for their review comments. Vijay Gurbani and Alexey Melnikov for their review comments. We
thank Richard Woundy for his very thorough review and comments
including those that resulted in additional text discussing scenarios
of admission control reject in the MPLVS VPN cloud.
Appendix A. Alternatives Considered Appendix A. Alternatives Considered
At this stage a number of alternatives to the approach described At this stage a number of alternatives to the approach described
above have been considered. We document some of the approaches above have been considered. We document some of the approaches
considered here to assist future discussion. None of these has been considered here to assist future discussion. None of these has been
shown to improve upon the approach described above, and the first two shown to improve upon the approach described above, and the first two
seem to have significant drawbacks relative to the approach described seem to have significant drawbacks relative to the approach described
above. above.
skipping to change at page 33, line 46 skipping to change at page 35, line 4
allocated for VRFs, only for customer prefixes, and that there is no allocated for VRFs, only for customer prefixes, and that there is no
simple, existing method for advertising the fact that a label is 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 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 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 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 a risk that the egress PE would simply label-switch the Path directly
on to the CE without performing RSVP processing. on to the CE without performing RSVP processing.
A second challenge with this approach is that an IP address needs to 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 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 message sent from ingress PE to egress PE. That address needs to be
reachable from the egress PE, and exist in the VRF at the ingress PE. reachable from the egress PE, and to exist in the VRF at the ingress
Such an address is not always available in today's deployments, so PE. Such an address is not always available in today's deployments,
this represents at least a change to existing deployment practices. so this represents at least a change to existing deployment
practices.
Appendix A.3. VRF label plus VRF address approach Appendix A.3. VRF label plus VRF address approach
It is possible to create an approach based on that described in the It is possible to create an approach based on that described in the
previous section which addresses the main challenges of that previous section which addresses the main challenges of that
approach. The basic approach has two parts: (a) define a new BGP approach. The basic approach has two parts: (a) define a new BGP
Extended Community to tag a route (and its associated MPLS label) as Extended Community to tag a route (and its associated MPLS label) as
pointing to a VRF; (b) allocate a "dummy" address to each VRF, pointing to a VRF; (b) allocate a "dummy" address to each VRF,
specifically to be used for routing RSVP messages. The dummy address specifically to be used for routing RSVP messages. The dummy address
(which could be anything, e.g. a loopback of the associated PE) would (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 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 destination for Resv messages but would not be imported into VRFs of
any other PE. any other PE.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", "Aggregation of RSVP for IPv4 and IPv6 Reservations",
RFC 3175, September 2001. RFC 3175, September 2001.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for "BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, September 2006. IPv6 VPN", RFC 4659, September 2006.
[RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation
Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels",
RFC 4804, February 2007. RFC 4804, February 2007.
12.2. Informative References 12.2. Informative References
[I-D.ietf-l3vpn-e2e-rsvp-te-reqts] [I-D.ietf-l3vpn-e2e-rsvp-te-reqts]
Kumaki, K., Kamite, Y., and R. Zhang, "Requirements for Kumaki, K., Kamite, Y., and R. Zhang, "Requirements for
supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP- supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-
VPN", draft-ietf-l3vpn-e2e-rsvp-te-reqts-04 (work in VPN", draft-ietf-l3vpn-e2e-rsvp-te-reqts-04 (work in
progress), August 2009. progress), August 2009.
[I-D.ietf-nsis-ntlp] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and M. Stiemerling, "GIST: General Schulzrinne, H. and M. Stiemerling, "GIST: General
Internet Signalling Transport", draft-ietf-nsis-ntlp-20 Internet Signalling Transport", draft-ietf-nsis-ntlp-20
(work in progress), June 2009. (work in progress), June 2009.
[I-D.ietf-nsis-qos-nslp] [I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-17
(work in progress), February 2008. (work in progress), October 2009.
[I-D.ietf-tsvwg-rsvp-security-groupkeying] [I-D.ietf-tsvwg-rsvp-security-groupkeying]
Behringer, M. and F. Faucheur, "Applicability of Keying Behringer, M. and F. Faucheur, "Applicability of Keying
Methods for RSVP Security", Methods for RSVP Security",
draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in
progress), June 2009. progress), June 2009.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", Services in the Internet Architecture: an Overview",
RFC 1633, June 1994. RFC 1633, June 1994.
 End of changes. 70 change blocks. 
202 lines changed or deleted 261 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/