draft-ietf-tsvwg-rsvp-l3vpn-00.txt   draft-ietf-tsvwg-rsvp-l3vpn-01.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: January 4, 2009 Cisco Systems, Inc. Expires: May 3, 2009 Cisco Systems, Inc.
July 3, 2008 October 30, 2008
Support for RSVP in Layer 3 VPNs Support for RSVP in Layer 3 VPNs
draft-ietf-tsvwg-rsvp-l3vpn-00 draft-ietf-tsvwg-rsvp-l3vpn-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 January 4, 2009. This Internet-Draft will expire on May 3, 2009.
Abstract Abstract
RFC 4364 and RFC 4659 define an approach to building provider- RFC 4364 and RFC 4659 define an approach to building provider-
provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to
use RSVP to perform admission control on the links between CE and PE use RSVP to perform admission control on the links between CE and PE
routers. This document specifies procedures by which RSVP messages routers. This document specifies procedures by which RSVP messages
travelling from CE to CE across an L3VPN may be appropriately handled 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 by PE routers so that admission control can be performed on PE-CE
links. Optionally, admission control across the provider's backbone links. Optionally, admission control across the provider's backbone
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Change history Change history
[_Note to RFC Editor: This section to be removed before publication_] [_Note to RFC Editor: This section to be removed before publication_]
Changes in this version (draft-ietf-tsvwg-rsvp-l3vpn-00) relative to Changes in this version (draft-ietf-tsvwg-rsvp-l3vpn-01) relative to
the last (draft-davie-tsvwg-rsvp-l3vpn-02): the last (draft-ietf-tsvwg-rsvp-l3vpn-00):
o Outlined signalling security issues and added discussion of o Recommended the use of VPN-IPv4 HOP object in all cases
methods to control redistribution of routes among providers and
from providers to customers
o Clarification regarding support for RSVP-TE across L3VPN o Clarified usage and security considerations regarding VPN-IPv4
address used for signalling (removed discussion on potential usage
of an extended-community to control redistribution)
o Minor corrections o Minor clarifications and typographical corrections
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 . . . . . . . . . . . . . . . . . . . . 6
3. Admission Control on PE-CE Links . . . . . . . . . . . . . . . 7 3. Admission Control on PE-CE Links . . . . . . . . . . . . . . . 7
3.1. Path Message Processing at Ingress PE . . . . . . . . . . 8 3.1. New Objects of Type VPN-IPv4 . . . . . . . . . . . . . . . 8
3.2. Path Message Processing at Egress PE . . . . . . . . . . . 9 3.2. Path Message Processing at Ingress PE . . . . . . . . . . 9
3.3. Resv Processing at Egress PE . . . . . . . . . . . . . . . 9 3.3. Path Message Processing at Egress PE . . . . . . . . . . . 10
3.4. Resv Processing at Ingress PE . . . . . . . . . . . . . . 10 3.4. Resv Processing at Egress PE . . . . . . . . . . . . . . . 11
3.5. Other RSVP Messages . . . . . . . . . . . . . . . . . . . 10 3.5. Resv Processing at Ingress PE . . . . . . . . . . . . . . 11
4. Admission Control in Provider's Backbone . . . . . . . . . . . 11 3.6. Other RSVP Messages . . . . . . . . . . . . . . . . . . . 12
5. Inter-AS operation . . . . . . . . . . . . . . . . . . . . . . 12 4. Admission Control in Provider's Backbone . . . . . . . . . . . 12
5.1. Inter-AS Option A . . . . . . . . . . . . . . . . . . . . 12 5. Inter-AS operation . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Inter-AS Option B . . . . . . . . . . . . . . . . . . . . 12 5.1. Inter-AS Option A . . . . . . . . . . . . . . . . . . . . 13
5.2.1. Admission control on ASBR . . . . . . . . . . . . . . 12 5.2. Inter-AS Option B . . . . . . . . . . . . . . . . . . . . 14
5.2.2. No admission control on ASBR . . . . . . . . . . . . . 13 5.2.1. Admission control on ASBR . . . . . . . . . . . . . . 14
5.2.2. No admission control on ASBR . . . . . . . . . . . . . 14
5.3. Inter-AS Option C . . . . . . . . . . . . . . . . . . . . 15 5.3. Inter-AS Option C . . . . . . . . . . . . . . . . . . . . 15
6. Operation with RSVP disabled . . . . . . . . . . . . . . . . . 15 6. Operation with RSVP disabled . . . . . . . . . . . . . . . . . 16
7. Other RSVP procedures . . . . . . . . . . . . . . . . . . . . 15 7. Other RSVP procedures . . . . . . . . . . . . . . . . . . . . 16
7.1. Refresh overhead reduction . . . . . . . . . . . . . . . . 15 7.1. Refresh overhead reduction . . . . . . . . . . . . . . . . 16
7.2. Cryptographic Authentication . . . . . . . . . . . . . . . 16 7.2. Cryptographic Authentication . . . . . . . . . . . . . . . 16
7.3. RSVP Aggregation . . . . . . . . . . . . . . . . . . . . . 16 7.3. RSVP Aggregation . . . . . . . . . . . . . . . . . . . . . 17
7.4. Support for CE-CE RSVP-TE . . . . . . . . . . . . . . . . 17 7.4. Support for CE-CE RSVP-TE . . . . . . . . . . . . . . . . 17
8. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 17 8. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 18
8.1. VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . . . . . . 17 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . . . . . . 18
8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects . . . . . . 18 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects . . . . . . 19
8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects . . . . . . . . 19 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects . . . . . . . . 20
8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects . . . . . . . . . . 20 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects . . . . . . . . . . 21
8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . 21 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . 22
8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6
SENDER_TEMPLATE objects . . . . . . . . . . . . . . . . . 23 SENDER_TEMPLATE objects . . . . . . . . . . . . . . . . . 24
8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC
objects . . . . . . . . . . . . . . . . . . . . . . . . . 25 objects . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix A. Alternatives Considered . . . . . . . . . . . . . . 27 Appendix A. Alternatives Considered . . . . . . . . . . . . . . 31
Appendix A.1. GMPLS UNI approach . . . . . . . . . . . . . . . . . 28 Appendix A.1. GMPLS UNI approach . . . . . . . . . . . . . . . . . 31
Appendix A.2. VRF label approach . . . . . . . . . . . . . . . . . 28 Appendix A.2. VRF label approach . . . . . . . . . . . . . . . . . 32
Appendix A.3. VRF label plus VRF address approach . . . . . . . . 28 Appendix A.3. VRF label plus VRF address approach . . . . . . . . 32
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . . . 36
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 8, line 5 skipping to change at page 8, line 5
Section 2.1 and expand on the details for those steps where standard Section 2.1 and expand on the details for those steps where standard
RSVP procedures need to be extended or modified to support the BGP/ RSVP procedures need to be extended or modified to support the BGP/
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. Path Message Processing at Ingress PE 3.1. New Objects of Type VPN-IPv4
For RSVP signalling within a VPN, certain RSVP objects need to be
extended. Since customer IP addresses need not be unique, the
current types of SESSION, SENDER_TEMPLATE and FILTERSPEC objects are
no longer sufficient to globally identify RSVP states in P/PE
routers, since those are currently based on IP addresses. We propose
new types of SESSION, SENDER_TEMPLATE and FILTERSPEC objects, which
contain globally unique VPN-IPv4 format addresses. The ingress and
egress PE nodes translate between the regular IPv4 addresses for
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
later sections.
The RSVP_HOP object in a RSVP message currently specifies an IP
address to be used by the neighboring RSVP hop to reply to the
message sender. However, MPLS VPN PE routers (especially those
separated by Option-B ASBRs) are not required to have direct IP
reachability to each other. To solve this issue, we propose the use
of label switching to forward RSVP messages between nodes within a
MPLS VPN. This is achieved by defining a new VPN-IPv4 RSVP_HOP
object. Use of the VPN-IPv4 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 AS2), regardless of whether they have
IP reachability to each other.
The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message
sender and a logical interface handle as before, but in addition
carries a VPN-IPv4 address which also represents the sender of the
message. The message sender MUST also advertise this VPN-IPv4 HOP
address into BGP, associated with a locally allocated label, and this
advertisement MUST be propagated by BGP throughout the VPN and to
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
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
advertisement of the VPN-IPv4 address contained in that RSVP_HOP. If
this address is found and carries an associated label, the
neighboring RSVP node MUST encapsulate the RSVP message with this
label and send it via MPLS encapsulation to the BGP next-hop
associated with the route. The destination IP address of the message
is taken from the IP address field of the RSVP_HOP object, as
described in [RFC2205]. Additionally, the IPv4 address in the
RSVP_HOP object continues to be used for all other existing purposes,
including neighbor matching between Path/Resv and SRefresh messages
([RFC2961]), authentication ([RFC2747]), etc.
The VPN-IPv4 address used in the VPN-IPv4 RSVP_HOP object MAY
represent an existing address in the VRF that corresponds to the flow
(e.g. a local loopback or PE-CE link address within the VRF for this
customer), or MAY be created specially for this purpose. In the case
where the address is specially created for RSVP signaling (and
possibly other control protocols), the BGP advertisement MUST NOT be
redistributed to, or reachable by, any CEs outside the MPLS VPN. One
way to achieve this is by creating a special "control protocols VPN"
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
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.
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
satisfies the requirements outlined above, it MUST use a VPN-IPv4 HOP
object with this address for all RSVP messages within the VPN. If a
PE/ASBR does not have any appropriate VPN-IPv4 address to use for
signalling, it MAY send the Path message with a regular IPv4 RSVP_HOP
object. In this case, the reply will be IP encapsulated. This
option is not preferred because there is no guarantee that the
neighboring RSVP hop has IP reachability to the sending node. If a
PE/ASBR receives or originates a Path message with a VPN-IPv4
RSVP_HOP object, any RSVP_HOP object in corresponding upstream
messages for this flow (e.g. Resv, ResvTear) or downstream messages
(e.g. ResvError, PathTear) sent by this node within the VPN MUST be
a VPN-IPv4 RSVP_HOP.
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, intercept these messages and process them as RSVP
skipping to change at page 8, line 28 skipping to change at page 10, line 6
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; that
is, rather than using the ultimate receiver's destination address as is, rather than using the ultimate receiver's destination address as
the destination address of the Path message, we use the loopback the destination address of the Path message, we use the loopback
address of the egress PE as the destination address of the Path address of the egress PE as the destination address of the Path
message. This approach has the advantage that it does not require message. This approach has the advantage that it does not require
any new data plane capabilities for the egress PE beyond those of a any new data plane capabilities for the egress PE beyond those of a
standard BGP/MPLS VPN PE. Details of the processing of this message standard BGP/MPLS VPN PE. Details of the processing of this message
at the egress PE are described below in Section 3.2. The approach of at the egress PE are described below in Section 3.3. The approach of
addressing a Path message directly to an RSVP next hop (that may or addressing a Path message directly to an RSVP next hop (that may or
may not be the next IP hop) is already used in other environments may not be the next IP hop) is already used in other environments
such as those of [RFC4206] and [RFC4804]. such as those of [RFC4206] and [RFC4804].
For an RSVP Path message, the existing SESSION and SENDER_TEMPLATE
objects can no longer uniquely identify a flow on VPN PE nodes. We
propose a new format of SESSION and SENDER_TEMPLATE objects which
contain a VPN-IPv4 format address. The ingress and egress PE nodes
translate between the regular IPv4 addresses for messages to and from
the CE, and VPN-IPv4 addresses for messages to and from PE routers.
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
identified. That next-hop is the egress PE (PE2 in Figure 1). A new identified. That next-hop is the egress PE (PE2 in Figure 1). A new
VPN-IPv4 SESSION object is constructed, containing the Route VPN-IPv4 SESSION object is constructed, containing the Route
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 RSVP_HOP object in the Path with the new VPN-IPv4 type objects. The Path message is sent without
message contains an IP address of the ingress PE. The Path message IP Router Alert and contains a RSVP_HOP object constructed as
is sent without IP Router Alert. specified in Section 3.1.
3.2. 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
information, is stored as part of the Path state. information, is stored as part of the Path state.
Now the RSVP module can construct a Path message which differs from Now the RSVP module can construct a Path message which differs from
skipping to change at page 9, line 42 skipping to change at page 11, line 15
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 an LIH, as per normal RSVP
processing. 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]. IP Router-Alert option as required by [RFC2205].
3.3. 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,
admission control can be performed on the PE-CE link. admission control can be performed on the PE-CE link.
Assuming admission control is successful, the PE constructs a Resv Assuming admission control is successful, the PE constructs a Resv
message to send to the RSVP HOP stored in the Path state, i.e., the message to send to the RSVP HOP stored in the Path state, i.e., the
ingress PE (PE1 in Figure 1). The IPv4 SESSION object is replaced ingress PE (PE1 in Figure 1). The IPv4 SESSION object is replaced
with the same VPN-IPv4 SESSION object received in the Path. The IPv4 with the same VPN-IPv4 SESSION object received in the Path. The IPv4
FILTER_SPEC object is replaced with a VPN-IPv4 FILTER_SPEC object, FILTER_SPEC object is replaced with a VPN-IPv4 FILTER_SPEC object,
which copies the VPN-IPv4 address from the SENDER_TEMPLATE received which copies the VPN-IPv4 address from the SENDER_TEMPLATE received
in the matching Path message. The RSVP_HOP in the Resv message in the matching Path message. The RSVP_HOP in the Resv message MUST
contains an IP address of the Egress PE that is reachable by the be constructed as specified in Section 3.1. The Resv message MUST be
ingress PE. The Resv message is sent to the IP address contained addressed to the IP address contained within the RSVP_HOP object in
within the RSVP_HOP object in the Path message. the Path message. If the Path message contained a VPN-IPv4 RSVP_HOP
object, the Resv MUST be MPLS-encapsulated using the label associated
with that VPN-IPv4 address in BGP, as described in Section 3.1. If
the Path message contained an IPv4 RSVP_HOP object, the Resv is
simply IP-encapsulated and addressed directly to the IP address in
the RSVP_HOP object.
If admission control is not successful on the egress PE, a ResvError If admission control is not successful on the egress PE, a ResvError
message is sent towards the receiver as per normal RSVP processing. message is sent towards the receiver as per normal RSVP processing.
3.4. Resv Processing at Ingress PE 3.5. Resv Processing at Ingress PE
Upon receiving a Resv message at the ingress PE (with respect to data Upon receiving a Resv message at the ingress PE (with respect to data
flow, i.e. PE1 in Figure 1), the PE determines the local VRF context flow, i.e. PE1 in Figure 1), the PE determines the local VRF context
and associated Path state for this Resv by decoding the received and associated Path state for this Resv by decoding the received
SESSION and FILTER_SPEC objects. It is now possible to generate a SESSION and FILTER_SPEC objects. It is now possible to generate a
Resv message to send to the appropriate CE. The Resv message sent to Resv message to send to the appropriate CE. The Resv message sent to
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.5. 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
used as described above
o Depending on the type of RSVP HOP received from the neighbor, the
message must be MPLS-encapsulated or IP-encapsulated 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 IP 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
skipping to change at page 11, line 37 skipping to change at page 13, line 19
to perform aggregate admission control in the backbone. to perform aggregate admission control in the backbone.
An MPLS-TE tunnel from an ingress PE to an egress PE can be thought An MPLS-TE tunnel from an ingress PE to an egress PE can be thought
of as a virtual link of a certain capacity. The main change to the of as a virtual link of a certain capacity. The main change to the
procedures described above is that when a Resv is received at the procedures described above is that when a Resv is received at the
ingress PE, an admission control decision can be performed by ingress PE, an admission control decision can be performed by
checking whether sufficient capacity of that virtual link remains checking whether sufficient capacity of that virtual link remains
available to admit the new customer reservation. We note also that available to admit the new customer reservation. We note also that
[RFC4804] uses the IF_ID RSVP_HOP object to identify the tunnel [RFC4804] uses the IF_ID RSVP_HOP object to identify the tunnel
across the backbone, rather than the simple RSVP_HOP object described across the backbone, rather than the simple RSVP_HOP object described
in Section 3.1. The procedures of [RFC4804] should be followed here in Section 3.2. The procedures of [RFC4804] should be followed here
as well. as well.
To achieve effective admission control in the backbone, there needs To achieve effective admission control in the backbone, there needs
to be some way to separate the data plane traffic that has a to be some way to separate the data plane traffic that has a
reservation from that which does not. We assume that packets that reservation from that which does not. We assume that packets that
are subject to admission control on the core will be given a are subject to admission control on the core will be given a
particular MPLS EXP value, and that no other packets will be allowed particular MPLS EXP value, and that no other packets will be allowed
to enter the core with this value unless they have passed admission to enter the core with this value unless they have passed admission
control. Some fraction of link resources will be allocated to queues control. Some fraction of link resources will be allocated to queues
on core links for packets bearing that EXP value, and the MPLS-TE on core links for packets bearing that EXP value, and the MPLS-TE
skipping to change at page 13, line 15 skipping to change at page 14, line 46
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) to
send RSVP messages directly between them. Not however that such send RSVP messages directly between them. This is only possible if
routers in an Option B environment are not required to have direct IP they are MPLS-encapsulated. The use of the VPN-IPv4 HOP object
reachability to each other. To mitigate this issue, we propose the described in Section 3.1 is REQUIRED in this case.
use of label switching to forward RSVP messages from a PE in one AS
to a PE in another AS. A detailed description of how this is
achieved follows.
We first define a new VPN-IPv4 RSVP_HOP object. Use of the VPN-IPv4
RSVP_HOP object enables RSVP control plane reachability between any
two adjacent RSVP hops in a MPLS VPN, regardless of whether they have
IP reachability. RSVP nodes sending Path or Resv messages across a
MPLS VPN MAY use the VPN-IPv4 PHOP object to achieve signalling
across Option-B ASBRs without requiring the ASBRs to install state.
The requirements ("SHOULD", "MUST" etc.) specified in the remainder
of this section only apply when the implementation supports the
OPTIONAL use of the VPN-IPv4 HOP object.
The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message
sender and a logical interface handle as before, but in addition
carries a VPN-IPv4 address which also represents the sender of the
message. The message sender MUST also advertise this VPN-IPv4 HOP
address into BGP with an associated label, and this advertisement
MUST be propagated by BGP throughout the VPN and to adjacent ASes in
order to provide reachability to this PE. Frames received by the PE
marked with this label MUST be given to the local control plane for
processing. This VPN-IPv4 address MAY be created specially for this
task, or MAY be any previously-advertised address representing any
VRF (e.g. local PE-CE link address). In the case where the address
is specially created for control protocols, the BGP advertisement for
this address SHOULD be marked such that it is not redistributed
outside the MPLS VPN. Two possible methods to achieve this goal are:
o Tag the advertisement of such routes with a route target that is
not imported into any customer VRFs. This requires the creation
of a special "control protocols" VPN which is used only for these
addresses.
o Tag the advertisement with a specially defined extended-community
attribute, the meaning of which is that this route is not to be
redistributed to customers. Definition of this attribute is
beyond the scope of this document.
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.1, 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 CAC). This ultimate egress PE, or an ASBR configured to perform CAC). This
router receives the Path and processes it as described in Section 3.2 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 ASBR performing CAC. if it is a PE, or Section 5.2.1 if it is an ASBR performing CAC.
When this router sends the Resv upstream, it queries BGP for a next- When this router sends the Resv upstream, it looks up the routing
hop and label for the VPN-IPv4 address in the PHOP, encapsulates the table for a next-hop+label for the VPN-IPv4 address in the PHOP,
Resv with that label and sends it upstream. This message will be encapsulates the Resv with that label and sends it upstream. This
received for control processing directly on the upstream RSVP hop message will be received for control processing directly on the
(the hop that last updated the RSVP_HOP field in the Path message), upstream RSVP hop (that last updated the RSVP_HOP field in the Path
without any involvement of intermediate ASBRs. Further, the router message), without any involvement of intermediate ASBRs.
sending this Resv message MUST include in its RSVP_HOP object a VPN-
IPv4 address advertised by itself into BGP with a label, so that hop-
by-hop RSVP messages in the downstream direction (e.g. ResvError)
can be sent directly to it. Note that the VPN-IPv4 address is only
used to identify a LSP for neighbor reachability. The IPv4 address
in the RSVP_HOP object is used for all other purposes, including
neighbor matching between Path/Resv and SRefresh messages
([RFC2961]), authentication ([RFC2747]), etc.
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 signalling 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 type If an Option-B ASBR receives a RSVP Path message with an IPv4
PHOP, does not wish to perform admission control but is willing to RSVP_HOP, does not wish to perform admission control but is willing
install local state for this flow, the ASBR MUST process and forward to install local state for this flow, the ASBR MUST process and
RSVP signalling messages for this flow as described in section 5.2.1 forward RSVP signalling messages for this flow as described in
(except admission control). If an Option-B ASBR receives a RSVP Path Section 5.2.1 (with the exception that it does not perform admission
message with an IPv4 type PHOP, but does not wish to install local control). If an Option-B ASBR receives a RSVP Path message with an
state or perform admission control for this flow, the ASBR MUST NOT IPv4 RSVP_HOP, but does not wish to install local state or perform
forward the Path message. In addition, the ASBR SHOULD send a admission control for this flow, the ASBR MUST NOT forward the Path
PathError message of Error Code [_TBD_], Error Value [_TBD_], message. In addition, the ASBR SHOULD send a PathError message of
signifying to the upstream RSVP hop that the supplied PHOP object is Error Code [_TBD_], Error Value [_TBD_], (see Section 9) signifying
insufficient to provide reachability across this VPN. The upstream to the upstream RSVP hop that the supplied RSVP_HOP object is
node, on receipt of this PathError, SHOULD re-send the Path message insufficient to provide reachability across this VPN. This failure
including a RSVP_HOP of VPN-IPv4 type. condition is not expected 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
the single AS case described in Section 3. Furthermore, if it is the single AS case described in Section 3. Furthermore, if it is
desired to provide admission control from PE to PE, it can be done by desired to provide admission control from PE to PE, it can be done by
building an inter-AS TE tunnel and then using the procedures building an inter-AS TE tunnel and then using the procedures
described in Section 4. described in Section 4.
skipping to change at page 17, line 28 skipping to change at page 18, line 17
the requirements of [I-D.kumaki-l3vpn-e2e-rsvp-te-reqts]. To the the requirements of [I-D.kumaki-l3vpn-e2e-rsvp-te-reqts]. To the
extent that this draft uses signalling extensions described in extent that this draft uses signalling 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 SESSION Object is described in Section 3.1 The usage of the VPN-IPv4 SESSION Object is described in Section 3.2
and Section 3.2. The VPN-IPv4 SESSION object should appear in all and Section 3.3. The VPN-IPv4 SESSION object should appear in all
RSVP messages that ordinarily contain a SESSION object and are sent RSVP messages that ordinarily contain a SESSION object and are sent
between ingress PE and egress PE in either direction. The object between ingress PE and egress PE in either direction. 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
the provider's backbone (except in the inter-AS option B and C cases, the provider's backbone (except in the inter-AS option B and C cases,
as described above, when it may appear on inter-AS links). The VPN- as described above, when it may appear on inter-AS links). The VPN-
IPv4 address in this object is built by combining the IPv4 address IPv4 address in this object is built by combining the IPv4 address
from the incoming SESSION with the RD in the BGP advertisement from from the incoming SESSION with the RD in the BGP advertisement from
the egress PE for this prefix and customer. the egress PE for this prefix and customer.
The VPN-IPv6 SESSION object is analogous to the VPN-IPv4 SESSION The VPN-IPv6 SESSION object is analogous to the VPN-IPv4 SESSION
skipping to change at page 18, line 38 skipping to change at page 19, line 25
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Protocol Id | Flags | DstPort | | Protocol Id | Flags | DstPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
The protocol ID, flags, and DstPort are identical to the IPv4 and The protocol ID, flags, and DstPort are identical to the IPv4 and
IPv6 SESSION objects. IPv6 SESSION objects.
8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects
The usage of the VPN-IPv4 SENDER_TEMPLATE Object is described in The usage of the VPN-IPv4 SENDER_TEMPLATE Object is described in
Section 3.1 and Section 3.2. The VPN-IPv4 SENDER_TEMPLATE object Section 3.2 and Section 3.3. The VPN-IPv4 SENDER_TEMPLATE object
should appear in all RSVP messages that ordinarily contain a should appear in all RSVP messages that ordinarily contain a
SENDER_TEMPLATE object and are sent between ingress PE and egress PE SENDER_TEMPLATE object and are sent between ingress PE and egress PE
in either direction (such as Path, PathError, and PathTear). The in either direction (such as Path, PathError, and PathTear). The
object MUST NOT be included in any RSVP messages that are sent object MUST NOT be included in any RSVP messages that are sent
outside of the provider's backbone (except in the inter-AS option B outside of the provider's backbone (except in the inter-AS option B
and C cases, as described above, when it may appear on inter-AS and C cases, as described above, when it may appear on inter-AS
links). The VPN-IPv4 address in this object is built by combining links). The VPN-IPv4 address in this object is built by combining
the IPv4 address from the incoming SENDER_TEMPLATE with the RD in the the IPv4 address from the incoming SENDER_TEMPLATE with the RD in the
BGP advertisement from the ingress PE for this prefix and customer. BGP advertisement from the ingress PE for this prefix and customer.
The format of the object is as follows: The format of the object is as follows:
skipping to change at page 19, line 39 skipping to change at page 20, line 39
| Reserved | SrcPort | | Reserved | SrcPort |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
The SrcPort is identical to the IPv4 and IPv6 SENDER_TEMPLATE The SrcPort is identical to the IPv4 and IPv6 SENDER_TEMPLATE
objects. The Reserved field must be set to zero on transmit and objects. The Reserved field must be set to zero on transmit and
ignored on receipt. ignored on 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 FILTER_SPEC Object is described in The usage of the VPN-IPv4 FILTER_SPEC Object is described in
Section 3.3 and Section 3.4. The VPN-IPv4 FILTER_SPEC object should Section 3.4 and Section 3.5. The VPN-IPv4 FILTER_SPEC object should
appear in all RSVP messages that ordinarily contain a FILTER_SPEC appear in all RSVP messages that ordinarily contain a FILTER_SPEC
object and are sent between ingress PE and egress PE in either object and are sent between ingress PE and egress PE in either
direction (such as Resv, ResvError, and ResvTear). The object MUST direction (such as Resv, ResvError, and ResvTear). The object MUST
NOT be included in any RSVP messages that are sent outside of the NOT be included in any RSVP messages that are sent outside of the
provider's backbone (except in the inter-AS option B and C cases, as provider's backbone (except in the inter-AS option B and C cases, as
described above, when it may appear on inter-AS links). The VPN-IPv4 described above, when it may appear on inter-AS links). The VPN-IPv4
address in this object is built by combining the IPv4 address from address in this object is built by combining the IPv4 address from
the incoming FILTER_SPEC with the RD in the BGP advertisement from the incoming FILTER_SPEC with the RD in the BGP advertisement from
the ingress PE for this prefix and customer. the ingress PE for this prefix and customer.
skipping to change at page 25, line 34 skipping to change at page 26, line 34
Definition same as AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object. Definition same as AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object.
o AGGREGATE-VPN-IPv6 FILTER_SPEC object: o AGGREGATE-VPN-IPv6 FILTER_SPEC object:
Class = 10, C-Type = TBA Class = 10, C-Type = TBA
Definition same as AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object. Definition same as AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object.
9. IANA Considerations 9. IANA Considerations
This document requires IANA assignment of new RSVP C-Types to Section 8 defines new objects. Therefore, this document requests
accommodate the new objects described in Section 8. In addition, a IANA to modify the RSVP parameters registry, 'Class Names, Class
new PathError code/value is required to identify a signalling Numbers, and Class Types' subregistry, and:
reachability failure and the need for a VPN-IPv4 or VPN-IPv6 RSVP_HOP
object as described in Section 5.2.2. o assign six new C-Types under the existing SESSION Class (Class
number 1), as suggested below:
Class
Number Class Name Reference
------ ----------------------- ---------
1 SESSION [RFC2205]
Class Types or C-Types:
.. ... ...
aa VPN-IPv4 [RFCXXXX]
bb VPN-IPv6 [RFCXXXX]
cc AGGREGATE-VPN-IPv4 [RFCXXXX]
dd AGGREGATE-VPN-IPv6 [RFCXXXX]
ee GENERIC-AGGREGATE-VPN-IPv4 [RFCXXXX]
ff GENERIC-AGGREGATE-VPN-IPv6 [RFCXXXX]
[Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC
number of this specification. Suggested values: aa-ff=19-24]
o assign four new C-Types under the existing SENDER_TEMPLATE Class
(Class number 11), as suggested below:
Class
Number Class Name Reference
------ ----------------------- ---------
11 SENDER_TEMPLATE [RFC2205]
Class Types or C-Types:
.. ... ...
aa VPN-IPv4 [RFCXXXX]
bb VPN-IPv6 [RFCXXXX]
cc AGGREGATE-VPN-IPv4 [RFCXXXX]
dd AGGREGATE-VPN-IPv6 [RFCXXXX]
[Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC
number of this specification. Suggested values: aa-dd=14-17]
o assign four new C-Types under the existing FILTER_SPEC Class
(Class number 10), as suggested below:
Class
Number Class Name Reference
------ ----------------------- ---------
10 FILTER_SPEC [RFC2205]
Class Types or C-Types:
.. ... ...
aa VPN-IPv4 [RFCXXXX]
bb VPN-IPv6 [RFCXXXX]
cc AGGREGATE-VPN-IPv4 [RFCXXXX]
dd AGGREGATE-VPN-IPv6 [RFCXXXX]
[Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC
number of this specification. Suggested values: aa-dd=14-17]
o assign two new C-Types under the existing RSVP_HOP Class (Class
number 3), as suggested below:
Class
Number Class Name Reference
------ ----------------------- ---------
3 RSVP_HOP [RFC2205]
Class Types or C-Types:
.. ... ...
aa VPN-IPv4 [RFCXXXX]
bb VPN-IPv6 [RFCXXXX]
[Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC
number of this specification. Suggested values: aa-bb=5-6]
In addition, a new PathError code/value is required to identify a
signalling reachability failure and the need for a VPN-IPv4 or VPN-
IPv6 RSVP_HOP object as described in Section 5.2.2. Therefore, this
document requests IANA to modify the RSVP parameters registry, 'Error
Codes and Globally-Defined Error Value Sub-Codes' subregistry, and:
o assign a new Error Code and sub-code, as suggested below:
aa RSVP over MPLS Problem [RFCXXXX]
This Error Code has the following globally-defined Error
Value sub-codes:
1 = RSVP_HOP not reachable across VPN [RFCXXXX]
[Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC
number of this specification. Suggested values: aa=34]
10. Security Considerations 10. Security Considerations
[RFC4364] addresses the security considerations of BGP/MPLS VPNs in [RFC4364] addresses the security considerations of BGP/MPLS VPNs in
general. General RSVP security considerations are addressed in general. General RSVP security considerations are discussed in
[RFC2205]. To ensure the integrity of RSVP, the RSVP Authentication [RFC2205]. To ensure the integrity of RSVP, the RSVP Authentication
mechanisms defined in [RFC2747] and [RFC3097]may be used. These mechanisms defined in [RFC2747] and [RFC3097] may be used. Those
protect RSVP message integrity hop-by-hop and provide node 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.behringer-tsvwg-rsvp-security-groupkeying] discusses [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of
applicability of various keying approaches for RSVP Authentication. various keying approaches for RSVP Authentication. First, we note
We note that the RSVP signaling in MPLS VPN is likely to spread over that the discussion about applicability of group keying to an intra-
multiple administrative domains (e.g. the service provider operating provider environment where RSVP hops are not IP hops is relevant to
the VPN service, and the customers of the service). Therefore the securing of RSVP among PEs of a given Service Provider deploying the
considerations in [I-D.behringer-tsvwg-rsvp-security-groupkeying] solution specified in the present document. We note that the RSVP
about inter-domain issues are likely to apply. Since RSVP messages signaling in MPLS VPN is likely to spread over multiple
travel through the L3VPN cloud directly addressed to PE or ASBR administrative domains (e.g. the service provider operating the VPN
routers (without IP Router-Alert), P routers remain isolated from service, and the customers of the service). Therefore the
RSVP messages signalling customer reservations. Providers MAY choose considerations in [I-D.ietf-tsvwg-rsvp-security-groupkeying] about
to block PEs from sending IP Router-Alert datagrams to P routers as a inter-domain issues are likely to apply.
security practice, without impacting the functionality described
herein. Since RSVP messages travel through the L3VPN cloud directly addressed
to PE or ASBR routers (without IP Router-Alert), P routers remain
isolated from RSVP messages signalling customer reservations.
Providers MAY choose to block PEs from sending IP Router-Alert
datagrams to P routers as a security practice, without 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 signalling
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
skipping to change at page 27, line 8 skipping to change at page 30, line 34
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. multiple PEs if desired.
A third issue may arise when Inter-AS Option B is used and admission Use of the VPN-IPv4 HOP object requires exporting a PE VPN-IPv4 route
control is not required on the inter-AS link (Section 5.2.2). In to another AS, and potentially could allow unchecked access to remote
this case, the VPN PE includes a VPN-IPv4 address in the PHOP/NHOP PEs if those routes were indiscriminately redistributed. However, as
objects it generates, which is used by the peer to determine a VPN described in Section 3.1, no route which is not within a customer's
label to communicate back with this PE. This results in a direct VPN should ever be advertised to (or reachable from) that customer.
VPN-IPv4 route to a PE being exported to another AS, and potentially If a PE uses a local address already within a customer VRF (like
could allow customers to direct RSVP messages to remote PEs if those PE-CE link address), it MUST NOT send this address in any RSVP
routes were advertised to the customers. However, as described in messages in a different customer VRF. A "control plane" VPN can be
Section 5.2.2, a variety of techniques may be used to prevent such created across PEs and ASBRs and addresses in this VPN can be used to
routes from being advertised to customers. Alternatively, ASBRs may signal RSVP sessions for any customers, but these routes MUST NOT be
implement the signalling procedures described in Section 5.2.1, even advertised to, or made reachable from, any customer. Alternatively,
if admission control is not required on the inter-AS link, as these ASBRs may implement the signalling procedures described in
procedures do not require any direct P/PE route advertisement out of Section 5.2.1, even if admission control is not required on the
the AS. inter-AS link, as these procedures do 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 signalling 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, it would be possible to use one of the mitigate this situation, it would be possible to extend the "control
approaches described in Section 5.2.2 to prevent such routers from protocol VPN" approach described above. That is, whenever a
being reachable by customers. That is, whenever a signalling message signalling message is to be sent to a PE or ASBR, the address of the
is to be sent to a PE or ASBR, the address of the router in question router in question would be looked up in the "control protocol VPN",
would be looked up in the "control protocol" VPN, and the message and the message would then be sent on the LSP that is found as a
would then be sent on the LSP that is found as a result of that result of that lookup. This would ensure that the router address is
lookup. This would allow the provider to restrict advertisement of not reachable by customer devices
PE and ASBR addresses so that these addresses are not reachable by
customer devices.
11. Acknowledgments 11. Acknowledgments
Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric
Rosen for their many contributions to solving the problems described Rosen and Dan Tappan for their many contributions to solving the
in this draft. Thanks to Ferit Yegenoglu and Dan Tappan for their problems described in this draft. Thanks to Ferit Yegenoglu for his
useful comments. useful comments.
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 29, line 40 skipping to change at page 33, line 19
[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.behringer-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-behringer-tsvwg-rsvp-security-groupkeying-01 (work draft-ietf-tsvwg-rsvp-security-groupkeying-01 (work in
in progress), November 2007. progress), July 2008.
[I-D.kumaki-l3vpn-e2e-rsvp-te-reqts] [I-D.kumaki-l3vpn-e2e-rsvp-te-reqts]
Kumaki, K., "Requirements for supporting Customer RSVP and Kumaki, K., "Requirements for supporting Customer RSVP and
RSVP-TE Over a BGP/MPLS IP-VPN", RSVP-TE Over a BGP/MPLS IP-VPN",
draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06 (work in draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06 (work in
progress), February 2008. progress), February 2008.
[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.
skipping to change at page 30, line 23 skipping to change at page 33, line 49
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997. Services", RFC 2210, September 1997.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000. Authentication", RFC 2747, January 2000.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001. Extensions", RFC 2961, April 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, Authentication -- Updated Message Type Value", RFC 3097,
April 2001. April 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", Bosch, "Next Steps in Signaling (NSIS): Framework",
 End of changes. 42 change blocks. 
193 lines changed or deleted 324 lines changed or added

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