summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6016.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6016.txt')
-rw-r--r--doc/rfc/rfc6016.txt2131
1 files changed, 2131 insertions, 0 deletions
diff --git a/doc/rfc/rfc6016.txt b/doc/rfc/rfc6016.txt
new file mode 100644
index 0000000..e6f3f5a
--- /dev/null
+++ b/doc/rfc/rfc6016.txt
@@ -0,0 +1,2131 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) B. Davie
+Request for Comments: 6016 F. Le Faucheur
+Category: Standards Track A. Narayanan
+ISSN: 2070-1721 Cisco Systems, Inc.
+ October 2010
+
+
+ Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs
+
+Abstract
+
+ RFC 4364 and RFC 4659 define an approach to building provider-
+ provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6. It may be
+ desirable to use Resource Reservation Protocol (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 traveling 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.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6016.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davie, et al. Standards Track [Page 1]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davie, et al. Standards Track [Page 2]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Terminology ................................................5
+ 1.2. Requirements Language ......................................5
+ 2. Problem Statement ...............................................5
+ 2.1. Model of Operation .........................................8
+ 3. Admission Control on PE-CE Links ................................9
+ 3.1. New Objects of Type VPN-IPv4 ...............................9
+ 3.2. Path Message Processing at Ingress PE .....................11
+ 3.3. Path Message Processing at Egress PE ......................12
+ 3.4. Resv Processing at Egress PE ..............................13
+ 3.5. Resv Processing at Ingress PE .............................13
+ 3.6. Other RSVP Messages .......................................14
+ 4. Admission Control in Provider's Backbone .......................14
+ 5. Inter-AS Operation .............................................15
+ 5.1. Inter-AS Option A .........................................15
+ 5.2. Inter-AS Option B .........................................15
+ 5.2.1. Admission Control on ASBR ..........................16
+ 5.2.2. No Admission Control on ASBR .......................16
+ 5.3. Inter-AS Option C .........................................17
+ 6. Operation with RSVP Disabled ...................................17
+ 7. Other RSVP Procedures ..........................................18
+ 7.1. Refresh Overhead Reduction ................................18
+ 7.2. Cryptographic Authentication ..............................18
+ 7.3. RSVP Aggregation ..........................................19
+ 7.4. Support for CE-CE RSVP-TE .................................19
+ 8. Object Definitions .............................................20
+ 8.1. VPN-IPv4 and VPN-IPv6 SESSION Objects .....................20
+ 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE Objects .............21
+ 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC Objects .................22
+ 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP Objects ....................22
+ 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION Objects ..........24
+ 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6
+ SENDER_TEMPLATE Objects ...................................26
+ 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6
+ FILTER_SPEC Objects .......................................27
+ 9. IANA Considerations ............................................28
+ 10. Security Considerations .......................................30
+ 11. Acknowledgments ...............................................33
+ Appendix A. Alternatives Considered .............................34
+ A.1. GMPLS UNI Approach ........................................34
+ A.2. Label Switching Approach ..................................34
+ A.3. VRF Label Approach ........................................34
+ A.4. VRF Label Plus VRF Address Approach .......................35
+ References ........................................................35
+ Normative References ...........................................35
+ Informative References .........................................36
+
+
+
+Davie, et al. Standards Track [Page 3]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+1. Introduction
+
+ [RFC4364] and [RFC4659] define a Layer 3 VPN service known as BGP/
+ MPLS VPNs for IPv4 and for IPv6, respectively. [RFC2205] defines the
+ Resource Reservation Protocol (RSVP), which may be used to perform
+ admission control as part of the Integrated Services (Int-Serv)
+ architecture [RFC1633][RFC2210].
+
+ Customers of a Layer 3 VPN service may run RSVP for the purposes of
+ admission control (and associated resource reservation) in their own
+ networks. Since the links between Provider Edge (PE) and Customer
+ Edge (CE) routers in a Layer 3 VPN may often be resource constrained,
+ it may be desirable to be able to perform admission control over
+ those links. In order to perform admission control using RSVP in
+ such an environment, it is necessary that RSVP control messages, such
+ as Path messages and Resv messages, are appropriately handled by the
+ PE routers. This presents a number of challenges in the context of
+ BGP/MPLS VPNs:
+
+ o RSVP Path message processing depends on routers recognizing the
+ Router Alert Option ([RFC2113], [RFC2711]) in the IP header.
+ However, packets traversing the backbone of a BGP/MPLS VPN are
+ MPLS encapsulated, and thus the Router Alert Option may not be
+ visible to the egress PE due to implementation or policy
+ considerations (e.g., if the egress PE processes the message as
+ "pop and go" without examining the IP header).
+
+ 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 called upon to process Path messages from different customer
+ VPNs with non-unique destination addresses within the RSVP
+ message. Current mechanisms for identifying customer context from
+ data packets are incompatible with RSVP message processing rules.
+
+ o A PE at the ingress of the provider's backbone may receive Resv
+ messages corresponding to different customer VPNs from other PEs,
+ and needs to be able to associate those Resv messages with the
+ appropriate customer VPNs.
+
+ Further discussion of these issues is presented in Section 2.
+
+ This document describes a set of procedures to overcome these
+ challenges and thus to enable admission control using RSVP over the
+ PE-CE links. We note that similar techniques may be applicable to
+ other protocols used for admission control such as the combination of
+ the NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service (QoS)
+ Signaling [RFC5974] and General Internet Signaling Transport (GIST)
+ protocol [RFC5971].
+
+
+
+Davie, et al. Standards Track [Page 4]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ Additionally, it may be desirable to perform admission control over
+ the provider's backbone on behalf of one or more L3VPN customers.
+ Core (P) routers in a BGP/MPLS VPN do not have forwarding entries for
+ customer routes, and thus they cannot natively process RSVP messages
+ for customer flows. Also, the core is a shared resource that carries
+ traffic for many customers, so issues of resource allocation among
+ customers and trust (or lack thereof) also ought to be addressed.
+ This document specifies procedures for supporting such a scenario.
+
+ This document deals with establishing reservations for unicast flows
+ only. Because the support of multicast traffic in BGP/MPLS VPNs is
+ still evolving, and raises additional challenges for admission
+ control, we leave the support of multicast flows for further study at
+ this point.
+
+1.1. Terminology
+
+ This document draws freely on the terminology defined in [RFC2205]
+ and [RFC4364]. For convenience, we provide a few brief definitions
+ here:
+
+ o Customer Edge (CE) Router: Router at the edge of a customer site
+ that attaches to the network of the VPN provider.
+
+ o Provider Edge (PE) Router: Router at the edge of the service
+ provider's network that attaches to one or more customer sites.
+
+ o VPN Label: An MPLS label associated with a route to a customer
+ prefix in a VPN (also called a VPN route label).
+
+ o VPN Routing and Forwarding (VRF) Table: A PE typically has
+ multiple VRFs, enabling it to be connected to CEs that are in
+ different VPNs.
+
+1.2. 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].
+
+2. Problem Statement
+
+ The problem space of this document is the support of admission
+ control between customer sites when the customer subscribes to a BGP/
+ MPLS VPN. We subdivide the problem into (a) the problem of admission
+ control on the PE-CE links (in both directions) and (b) the problem
+ of admission control across the provider's backbone.
+
+
+
+
+Davie, et al. Standards Track [Page 5]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ RSVP Path messages are normally addressed to the destination of a
+ session, and contain the Router Alert Option (RAO) within the IP
+ header. Routers along the path to the destination that are
+ configured to process RSVP messages need to detect the presence of
+ the RAO to allow them to intercept Path messages. However, the
+ egress PEs of a network supporting BGP/MPLS VPNs receive packets
+ destined for customer sites as MPLS-encapsulated packets, and they
+ possibly forward those based only on examination of the MPLS label.
+ In order to process RSVP Path messages, the egress VPN PE would have
+ to pop the VPN label and examine the IP header underneath, before
+ forwarding the packet (based on the VPN label disposition rules),
+ which is not a requirement for data packet processing today. Hence,
+ a Path message would be forwarded without examination of the IP
+ options and would therefore not receive appropriate processing at the
+ PE. Another potential issue is doing Connection Admission Control
+ (CAC) at an Autonomous System Border Router (ASBR). Even an
+ implementation that examines the IP header when removing the VPN
+ label (e.g., PE-CE link) would not be able to do CAC at an Option-B
+ ASBR; that requires examining the (interior) IP header while doing a
+ label swap, which is much less desirable behavior.
+
+ In general, there are significant issues with requiring support for
+ IP Router Alert outside of a controlled, "walled-garden" network, as
+ described in [ALERT-USAGE]. The case of a MPLS L3VPN falls under the
+ "Overlay Model" described therein. Fundamental to this model is that
+ providers would seek to eliminate the requirement to process RAO-
+ marked packets from customers, on any routers except the PEs facing
+ those customers. Issues with requiring interior MPLS routers to
+ process RAO-marked packets are also described in [LER-OPTIONS]. The
+ approach for RSVP packet handling described in this document has the
+ advantage of being independent of any data-plane requirements such as
+ IP Router Alert support within the VPN or examining any IP options
+ for MPLS-encapsulated packets. The only requirement for processing
+ IP Router Alert packets is for RSVP packets received from the CE,
+ which do not carry any MPLS encapsulation.
+
+ For the PE-CE link subproblem, the most basic challenge is that RSVP
+ control messages contain IP addresses that are drawn from the
+ customer's address space, and PEs need to deal with traffic from many
+ customers who may have non-unique (or overlapping) address spaces.
+ Thus, it is essential that a PE be able, in all cases, to identify
+ the correct VPN context in which to process an RSVP control message.
+ The current mechanism for identifying the customer context is the VPN
+ label, which is carried in an MPLS header outside of the RSVP
+ message. This is divergent from the general RSVP model of session
+ identification ([RFC2205], [RFC2209]), which relies solely on RSVP
+ objects to identify sessions. Further, it is incompatible with
+ protocols like COPS/RSVP (Common Open Policy Service) ([RFC2748],
+
+
+
+Davie, et al. Standards Track [Page 6]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ [RFC2749]), which replace the IP encapsulation of the RSVP message
+ and send only RSVP objects to a COPS server. We believe it is
+ important to retain the model of completely identifying an RSVP
+ session from the contents of RSVP objects. Much of this document
+ deals with this issue.
+
+ For the case of making reservations across the provider backbone, we
+ observe that BGP/MPLS VPNs do not create any per-customer forwarding
+ state in the P (provider core) routers. Thus, in order to make
+ reservations on behalf of customer-specified flows, it is clearly
+ necessary to make some sort of aggregated reservation from PE-PE and
+ then map individual, customer-specific reservations onto an aggregate
+ reservation. That is similar to the problem tackled in [RFC3175] and
+ [RFC4804], with the additional complications of handling customer-
+ specific addressing associated with BGP/MPLS VPNs.
+
+ 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 the 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, the
+ 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 QoS 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 are 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 the case of such a 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
+
+
+
+
+
+Davie, et al. Standards Track [Page 7]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ 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
+
+ Figure 1 illustrates the basic model of operation with which this
+ document is concerned.
+
+ --------------------------
+ / Provider \
+ |----| | Backbone | |----|
+Sender->| CE1| |-----| |-----| |CE2 |->Receiver
+ | |--| | |---| |---| | |---| |
+ |----| | | | P | | P | | | |----|
+ | PE1 |---| |-----| |-----| PE2 |
+ | | | | | | | |
+ | | |---| |---| | |
+ |-----| |-----|
+ | |
+ \ /
+ --------------------------
+
+ Figure 1. Model of Operation for RSVP-Based Admission
+ Control over MPLS/BGP VPN
+
+ To establish a unidirectional reservation for a point-to-point flow
+ from Sender to Receiver that takes account of resource availability
+ on the CE-PE and PE-CE links only, the following steps need to take
+ place:
+
+ 1. The Sender sends a Path message to an IP address of the
+ Receiver.
+
+ 2. The Path message is processed by CE1 using normal RSVP
+ procedures and forwarded towards the Receiver along the link
+ CE1-PE1.
+
+ 3. PE1 processes the Path message and forwards it towards the
+ Receiver across the provider backbone.
+
+ 4. PE2 processes the Path message and forwards it towards the
+ Receiver along link PE2-CE2.
+
+ 5. CE2 processes the Path message using normal RSVP procedures and
+ forwards it towards the Receiver.
+
+ 6. The Receiver sends a Resv message to CE2.
+
+
+
+Davie, et al. Standards Track [Page 8]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ 7. CE2 sends the Resv message to PE2.
+
+ 8. PE2 processes the Resv message (including performing admission
+ control on link PE2-CE2) and sends the Resv message to PE1.
+
+ 9. PE1 processes the Resv message and sends the Resv message to
+ CE1.
+
+ 10. CE1 processes the Resv message using normal RSVP procedures,
+ performs admission control on the link CE1-PE1, and sends the
+ Resv message to the Sender if successful.
+
+ In each of the steps involving Resv messages (6 through 10) the node
+ sending the Resv message uses the previously established Path state
+ to determine the "RSVP Previous Hop (PHOP)" and sends a Resv message
+ to that address. We note that establishing that Path state correctly
+ at PEs is one of the challenges posed by the BGP/MPLS environment.
+
+3. Admission Control on PE-CE Links
+
+ In the following sections, we trace through the steps outlined in
+ 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/
+ MPLS VPN environment. For all the remaining steps described in the
+ preceding section, standard RSVP processing rules apply.
+
+ All the procedures described below support both IPv4 and IPv6
+ addressing. In all cases where IPv4 is referenced, IPv6 can be
+ substituted with identical procedures and results. Object
+ definitions for both IPv4 and IPv6 are provided in Section 8.
+
+3.1. New Objects of Type VPN-IPv4
+
+ For RSVP signaling 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 they 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.
+
+
+
+
+
+
+
+Davie, et al. Standards Track [Page 9]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ The RSVP_HOP object in an 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 an
+ MPLS VPN. This is achieved by defining a new VPN-IPv4 RSVP_HOP
+ object. Use of the VPN-IPv4 RSVP_HOP object enables any two adjacent
+ RSVP hops in an MPLS VPN (e.g., a PE in Autonomous System (AS) 1 and
+ a PE in AS2) to correctly identify each other and send RSVP messages
+ directly to each other.
+
+ The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message
+ sender and a Logical Interface Handle (LIH) as before, but in
+ addition carries a VPN-IPv4 address that also represents the sender
+ of the message. The message sender MUST also advertise this VPN-IPv4
+ 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 it 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.
+
+
+
+
+
+
+Davie, et al. Standards Track [Page 10]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ 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 signaling that
+ satisfies the requirements outlined above, it MUST use a VPN-IPv4
+ RSVP_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 signaling, 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)
+ the PE needs to establish suitable Path state and forward the Path
+ message on to the egress PE. In the following paragraphs, we
+ described the steps taken by the ingress PE.
+
+ The Path message is addressed to the eventual destination (the
+ receiver at the remote customer site) and carries the IP Router Alert
+ Option, in accordance with [RFC2205]. The ingress PE MUST recognize
+ the Router Alert Option, intercept these messages and process them as
+ RSVP signaling messages.
+
+ As noted above, there is an issue in recognizing Path messages as
+ they arrive at the egress PE (PE2 in Figure 1). The approach defined
+ here is to address the Path messages sent by the ingress PE directly
+ to the egress PE, and send it without the IP Router Alert Option;
+ that is, rather than using the ultimate receiver's destination
+ address as the destination address of the Path message, we use the
+ loopback address of the egress PE as the destination address of the
+ Path message. This approach has the advantage that it does not
+ require any new data-plane capabilities for the egress PE beyond
+ those of a standard BGP/MPLS VPN PE. Details of the processing of
+ this message at the egress PE are described below in Section 3.3.
+ The approach of 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 such as those of [RFC4206] and [RFC4804].
+
+ The details of operation at the ingress PE are as follows. When the
+ ingress PE (PE1 in Figure 1) receives a Path message from CE1 that is
+ addressed to the receiver, the VRF that is associated with the
+ incoming interface is identified, just as for normal data path
+ operations. The Path state for the session is stored, and is
+
+
+
+Davie, et al. Standards Track [Page 11]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ associated with that VRF, so that potentially overlapping addresses
+ among different VPNs do not appear to belong to the same session.
+ The destination address of the receiver is looked up in the
+ appropriate VRF, and the BGP next hop for that destination is
+ identified. That next hop is the egress PE (PE2 in Figure 1). A new
+ VPN-IPv4 SESSION object is constructed, containing the Route
+ Distinguisher (RD) that is part of the VPN-IPv4 route prefix for this
+ destination, and the IPv4 address from the SESSION. In addition, a
+ new VPN-IPv4 SENDER_TEMPLATE object is constructed, with the original
+ 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
+ VPN. A new Path message is constructed with a destination address
+ equal to the address of the egress PE identified above. This new
+ Path message will contain all the objects from the original Path
+ message, replacing the original SESSION and SENDER_TEMPLATE objects
+ with the new VPN-IPv4 type objects. The Path message is sent without
+ the Router Alert Option and contains an RSVP_HOP object constructed
+ as specified in Section 3.1.
+
+3.3. Path Message Processing at Egress PE
+
+ When a Path message arrives at the egress PE, (step 4 of Section 2.1)
+ it is addressed to the PE itself, and is handed to RSVP for
+ processing. The router extracts the RD and IPv4 address from the
+ VPN-IPv4 SESSION object, and determines the local VRF context by
+ finding a matching VPN-IPv4 prefix with the specified RD that has
+ been advertised by this router into BGP. The entire incoming RSVP
+ message, including the VRF information, is stored as part of the Path
+ state.
+
+ Now the RSVP module can construct a Path message that differs from
+ the Path it received in the following ways:
+
+ a. Its destination address is the IP address extracted from the
+ SESSION object;
+
+ b. The SESSION and SENDER_TEMPLATE objects are converted back to
+ IPv4-type by discarding the attached RD;
+
+ c. The RSVP_HOP Object contains the IP address of the outgoing
+ interface of the egress PE and a Logical Interface Handle (LIH),
+ as per normal RSVP processing.
+
+ The router then sends the Path message on towards its destination
+ over the interface identified above. This Path message carries the
+ Router Alert Option as required by [RFC2205].
+
+
+
+
+
+Davie, et al. Standards Track [Page 12]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+3.4. Resv Processing at Egress PE
+
+ When a receiver at the customer site originates a Resv message for
+ the session, normal RSVP procedures apply until the Resv, making its
+ way back towards the sender, arrives at the "egress" PE (step 8 of
+ Section 2.1). Note that this is the "egress" PE with respect to the
+ direction of data flow, i.e., PE2 in Figure 1. On arriving at PE2,
+ the SESSION and FILTER_SPEC objects in the Resv, and the VRF in which
+ the Resv was received, are used to find the matching Path state
+ stored previously. At this stage, admission control can be performed
+ on the PE-CE link.
+
+ Assuming admission control is successful, the PE constructs a Resv
+ message to send to the RSVP previous hop stored in the Path state,
+ i.e., the 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 FILTER_SPEC object is replaced with a VPN-IPv4 FILTER_SPEC
+ object, which copies the VPN-IPv4 address from the SENDER_TEMPLATE
+ received in the matching Path message. The RSVP_HOP in the Resv
+ message MUST be constructed as specified in Section 3.1. The Resv
+ message MUST be addressed to the IP address contained within the
+ RSVP_HOP object in 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
+ message is sent towards the receiver as per normal RSVP processing.
+
+3.5. Resv Processing at Ingress PE
+
+ Upon receiving a Resv message at the ingress PE (step 8 of
+ Section 2.1) with respect to data 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 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 the ingress CE will contain
+ IPv4 SESSION and FILTER_SPEC objects, derived from the appropriate
+ Path state. Since we assume, in this section, that admission control
+ over the provider's backbone is not needed, the ingress PE does not
+ perform any admission control for this reservation.
+
+
+
+
+
+
+
+
+Davie, et al. Standards Track [Page 13]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+3.6. Other RSVP Messages
+
+ Processing of PathError, PathTear, ResvError, ResvTear, and ResvConf
+ messages is generally straightforward and follows the rules of
+ [RFC2205]. These additional rules MUST be observed for messages
+ transmitted within the VPN (i.e., between the PEs):
+
+ o The SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects MUST be
+ converted from IPv4 to VPN-IPv4 form and back in the same manner
+ 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 object received from the
+ neighbor, the message MUST be MPLS encapsulated or IP encapsulated
+ as described above.
+
+ o The matching state and VRF MUST be determined by decoding the RD
+ and IPv4 addresses in the SESSION and FILTER_SPEC objects.
+
+ o The message MUST be directly addressed to the appropriate PE,
+ without using the Router Alert Option.
+
+4. Admission Control in Provider's Backbone
+
+ The preceding section outlines how per-customer reservations can be
+ made over the PE-CE links. This may be sufficient in many situations
+ where the backbone is well engineered with ample capacity and there
+ is no need to perform any sort of admission control in the backbone.
+ However, in some cases where excess capacity cannot be relied upon
+ (e.g., during failures or unanticipated periods of overload), it may
+ be desirable to be able to perform admission control in the backbone
+ on behalf of customer traffic.
+
+ Because of the fact that routes to customer addresses are not present
+ in the P routers, along with the concerns of scalability that would
+ arise if per-customer reservations were allowed in the P routers, it
+ is clearly necessary to map the per-customer reservations described
+ in the preceding section onto some sort of aggregate reservations.
+ Furthermore, customer data packets need to be tunneled across the
+ provider backbone just as in normal BGP/MPLS VPN operation.
+
+ Given these considerations, a feasible way to achieve the objective
+ of admission control in the backbone is to use the ideas described in
+ [RFC4804]. MPLS-TE tunnels can be established between PEs as a means
+ to perform aggregate admission control in the backbone.
+
+
+
+
+Davie, et al. Standards Track [Page 14]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ An MPLS-TE tunnel from an ingress PE to an egress PE can be thought
+ of as a virtual link of a certain capacity. The main change to the
+ procedures described above is that when a Resv is received at the
+ ingress PE, an admission control decision can be performed by
+ checking whether sufficient capacity of that virtual link remains
+ available to admit the new customer reservation. We note also that
+ [RFC4804] uses the IF_ID RSVP_HOP object to identify the tunnel
+ across the backbone, rather than the simple RSVP_HOP object described
+ in Section 3.2. The procedures of [RFC4804] should be followed here
+ as well.
+
+ To achieve effective admission control in the backbone, there needs
+ to be some way to separate the data-plane traffic that has a
+ reservation from that which does not. We assume that packets that
+ are subject to admission control on the core will be given a
+ particular MPLS EXP value, and that no other packets will be allowed
+ to enter the core with this value unless they have passed admission
+ control. Some fraction of link resources will be allocated to queues
+ on core links for packets bearing that EXP value, and the MPLS-TE
+ tunnels will use that resource pool to make their constraint-based
+ routing and admission control decisions. This is all consistent with
+ the principles of aggregate RSVP reservations described in [RFC3175].
+
+5. Inter-AS Operation
+
+ [RFC4364] defines three modes of inter-AS operation for MPLS/BGP
+ VPNs, referred to as Options A, B, and C. In the following sections
+ we describe how the scheme described above can operate in each
+ inter-AS environment.
+
+5.1. Inter-AS Option A
+
+ Operation of RSVP in Inter-AS Option A is quite straightforward.
+ Each ASBR operates like a PE, and the ASBR-ASBR links can be viewed
+ as PE-CE links in terms of admission control. If the procedures
+ defined in Section 3 are enabled on both ASBRs, then admission
+ control may be performed on the inter-ASBR links. In addition, the
+ operator of each AS can independently decide whether or not to
+ perform admission control across his backbone. The new objects
+ described in this document MUST NOT be sent in any RSVP message
+ between two Option-A ASBRs.
+
+5.2. Inter-AS Option B
+
+ To support inter-AS Option B, we require some additional processing
+ of RSVP messages on the ASBRs. Recall that, when packets are
+ forwarded from one AS to another in Option B, the VPN label is
+ swapped by each ASBR as a packet goes from one AS to another. The
+
+
+
+Davie, et al. Standards Track [Page 15]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ BGP next hop seen by the ingress PE will be the ASBR, and there need
+ not be IP visibility between the ingress and egress PEs. Hence, when
+ the ingress PE sends the Path message to the BGP next hop of the VPN-
+ IPv4 route towards the destination, it will be received by the ASBR.
+ The ASBR determines the next hop of the route in a similar way as the
+ ingress PE -- by finding a matching BGP VPN-IPv4 route with the same
+ RD and a matching prefix.
+
+ The provider(s) who interconnect ASes using Option B may or may not
+ desire to perform admission control on the inter-AS links. This
+ choice affects the detailed operation of ASBRs. We describe the two
+ modes of operation -- with and without admission control at the ASBRs
+ -- in the following sections.
+
+5.2.1. Admission Control on ASBR
+
+ In this scenario, the ASBR performs full RSVP signaling and admission
+ control. The RSVP database is indexed on the ASBR using the VPN-IPv4
+ SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects (which uniquely
+ identify RSVP sessions and flows as per the requirements of
+ [RFC2205]). These objects are forwarded unmodified in both
+ directions by the ASBR. All other procedures of RSVP are performed
+ as if the ASBR was an RSVP hop. In particular, the RSVP_HOP objects
+ 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
+ sent. Note that since the VPN-IPv4 SESSION, SENDER_TEMPLATE, and
+ FILTER_SPEC objects satisfy the uniqueness properties required for an
+ RSVP database implementation as per [RFC2209], no customer VRF
+ awareness is required on the ASBR.
+
+5.2.2. No Admission Control on ASBR
+
+ If the ASBR is not doing admission control, it is desirable that per-
+ 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 send RSVP messages directly to each other. This is only possible
+ if they are MPLS encapsulated. The use of the VPN-IPv4 RSVP_HOP
+ object described in Section 3.1 is REQUIRED in this case.
+
+ 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
+ described in Section 3.2, and sends the Path message to the next hop,
+ without modifying any RSVP objects (including the RSVP_HOP). This
+ process is repeated at subsequent ASBRs until the Path message
+ arrives at a router that is installing local RSVP state (either the
+ ultimate egress PE, or an ASBR configured to perform admission
+ 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
+
+
+
+Davie, et al. Standards Track [Page 16]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ ASBR performing admission control. When this router sends the Resv
+ upstream, it looks up the routing table for a next hop+label for the
+ VPN-IPv4 address in the PHOP, encapsulates the Resv with that label,
+ and sends it upstream. This message will be received for control
+ processing directly on the upstream RSVP hop (that last updated the
+ RSVP_HOP field in the Path message), without any involvement of
+ intermediate ASBRs.
+
+ The ASBR is not expected to process any other RSVP messages apart
+ 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
+ wishes to do admission control or insert itself into the RSVP
+ signaling flow may do so by writing its own RSVP_HOP object with IPv4
+ and VPN-IPv4 addresses pointing to itself.
+
+ If an Option-B ASBR that receives an RSVP Path message with an IPv4
+ RSVP_HOP does not wish to perform admission control but is willing to
+ install local state for this flow, the ASBR MUST process and forward
+ RSVP signaling messages for this flow as described in Section 5.2.1
+ (with the exception that it does not perform admission control). If
+ an Option-B ASBR receives an RSVP Path message with an 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 message. In
+ addition, the ASBR SHOULD send a PathError message of Error Code
+ "RSVP over MPLS Problem" and Error Value "RSVP_HOP not reachable
+ across VPN" (see Section 9) signifying to the upstream RSVP hop that
+ the supplied RSVP_HOP object is insufficient to provide reachability
+ across this VPN. This failure condition is not expected to be
+ recoverable.
+
+5.3. Inter-AS Option C
+
+ Operation of RSVP in Inter-AS Option C is also quite straightforward,
+ because there exists an LSP directly from ingress PE to egress PE.
+ In this case, there is no significant difference in operation from
+ the single AS case described in Section 3. Furthermore, if it is
+ desired to provide admission control from PE to PE, it can be done by
+ building an inter-AS TE tunnel and then using the procedures
+ described in Section 4.
+
+6. Operation with RSVP Disabled
+
+ It is often the case that RSVP will not be enabled on the PE-CE
+ links. In such an environment, a customer may reasonably expect that
+ RSVP messages sent into the L3 VPN network should be forwarded just
+ like any other IP datagrams. This transparency is useful when the
+ customer wishes to use RSVP within his own sites or perhaps to
+ perform admission control on the CE-PE links (in CE->PE direction
+
+
+
+Davie, et al. Standards Track [Page 17]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ only), without involvement of the PEs. For this reason, a PE SHOULD
+ NOT discard or modify RSVP messages sent towards it from a CE when
+ RSVP is not enabled on the PE-CE links. Similarly a PE SHOULD NOT
+ discard or modify RSVP messages that are destined for one of its
+ attached CEs, even when RSVP is not enabled on those links. Note
+ that the presence of the Router Alert Option in some RSVP messages
+ may cause them to be forwarded outside of the normal forwarding path,
+ but that the guidance of this paragraph still applies in that case.
+ Note also that this guidance applies regardless of whether RSVP-TE is
+ used in some, all, or none of the L3VPN network.
+
+7. Other RSVP Procedures
+
+ This section describes modifications to other RSVP procedures
+ introduced by MPLS VPNs.
+
+7.1. Refresh Overhead Reduction
+
+ The following points ought to be noted regarding RSVP refresh
+ overhead reduction [RFC2961] across an MPLS VPN:
+
+ 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
+ procedures described in Section 5.3 of [RFC2961] relating to non-
+ RSVP hops SHOULD be followed.
+
+ o The source IP address of a SRefresh message MUST match the IPv4
+ address signaled in the RSVP_HOP object contained in the
+ corresponding Path or Resv message. The IPv4 address in any
+ received VPN-IPv4 RSVP_HOP object MUST be used as the source
+ address of that message for this purpose.
+
+7.2. Cryptographic Authentication
+
+ The following points ought to be noted regarding RSVP cryptographic
+ authentication ([RFC2747]) across an MPLS VPN:
+
+ 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
+ identifying the security association.
+
+ o Forwarding of Challenge and Response messages MUST follow the same
+ rules as described above for hop-by-hop messages. Specifically,
+ if the originator of a Challenge/Response message has received a
+ VPN-IPv4 RSVP_HOP object from the corresponding neighbor, it MUST
+ use the label associated with that VPN-IPv4 address in BGP to
+ forward the Challenge/Response message.
+
+
+
+
+Davie, et al. Standards Track [Page 18]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+7.3. RSVP Aggregation
+
+ [RFC3175] and [RFC4860] describe mechanisms to aggregate multiple
+ individual RSVP reservations into a single larger reservation on the
+ basis of a common Differentiated Services Code Point/Per-Hop Behavior
+ (DSCP/PHB) for traffic classification. The following points ought to
+ be noted in this regard:
+
+ o The procedures described in this section apply only in the case
+ where the Aggregator and Deaggregator nodes are C/CE devices, and
+ the entire MPLS VPN lies within the Aggregation Region. The case
+ where the PE is also an Aggregator/Deaggregator is more complex
+ and not considered in this document.
+
+ o Support of Aggregate RSVP sessions is OPTIONAL. When supported:
+
+ * Aggregate RSVP sessions MUST be treated in the same way as
+ regular IPv4 RSVP sessions. To this end, all the procedures
+ described in Sections 3 and 4 MUST be followed for aggregate
+ RSVP sessions. The corresponding new SESSION, SENDER_TEMPLATE,
+ and FILTERSPEC objects are defined in Section 8.
+
+ * End-To-End (E2E) RSVP sessions are passed unmodified through
+ 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
+
+ [RFC5824] describes a set of requirements for the establishment for
+ CE-CE MPLS LSPs across networks offering an L3VPN service. The
+ requirements specified in that document are similar to those
+ addressed by this document, in that both address the issue of
+ handling RSVP requests from customers in a VPN context. It is
+ possible that the solution described here could be adapted to meet
+ the requirements of [RFC5824]. To the extent that this document uses
+ signaling extensions described in [RFC3473] that have already been
+ used for GMPLS/TE, we expect that CE-CE RSVP/TE will be incremental
+ work built on these extensions. These extensions will be considered
+ in a separate document.
+
+
+
+Davie, et al. Standards Track [Page 19]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+8. Object Definitions
+
+8.1. VPN-IPv4 and VPN-IPv6 SESSION Objects
+
+ The usage of the VPN-IPv4 (or VPN-IPv6) SESSION object is described
+ in Sections 3.2 to 3.6. The VPN-IPv4 (or VPN-IPv6) SESSION object
+ appears in RSVP messages that ordinarily contain a SESSION object and
+ are sent between ingress PE and egress PE in either direction. The
+ object MUST NOT be included in any RSVP messages that are sent
+ outside of the provider's backbone (except in the inter-AS Option-B
+ and Option-C cases, as described above, when it may appear on
+ inter-AS links).
+
+ The VPN-IPv6 SESSION object is analogous to the VPN-IPv4 SESSION
+ object, using an VPN-IPv6 address ([RFC4659]) instead of an VPN-IPv4
+ address ([RFC4364]).
+
+ The formats of the objects are as follows:
+
+ o VPN-IPv4 SESSION object: Class = 1, C-Type = 19
+
+ +-------------+-------------+-------------+-------------+
+ | |
+ + +
+ | VPN-IPv4 DestAddress (12 bytes) |
+ + +
+ | |
+ +-------------+-------------+-------------+-------------+
+ | Protocol Id | Flags | DstPort |
+ +-------------+-------------+-------------+-------------+
+
+
+ o VPN-IPv6 SESSION object: Class = 1, C-Type = 20
+
+ +-------------+-------------+-------------+-------------+
+ | |
+ + +
+ | |
+ + VPN-IPv6 DestAddress (24 bytes) +
+ / /
+ . .
+ / /
+ | |
+ +-------------+-------------+-------------+-------------+
+ | Protocol Id | Flags | DstPort |
+ +-------------+-------------+-------------+-------------+
+
+
+
+
+
+Davie, et al. Standards Track [Page 20]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ The VPN-IPv4 DestAddress (respectively, VPN-IPv6 DestAddress) field
+ contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address
+ family encoded as specified in [RFC4364] (respectively, [RFC4659]).
+ The content of this field is discussed in Sections 3.2 and 3.3.
+
+ The protocol ID, flags, and DstPort are identical to the same fields
+ in the IPv4 and IPv6 SESSION objects ([RFC2205]).
+
+8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE Objects
+
+ The usage of the VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object is
+ described in Sections 3.2 and 3.3. The VPN-IPv4 (or VPN-IPv6)
+ SENDER_TEMPLATE object appears in RSVP messages that ordinarily
+ contain a SENDER_TEMPLATE object and are sent between ingress PE and
+ egress PE in either direction (such as Path, PathError, and
+ PathTear). The object MUST NOT be included in any RSVP messages that
+ are sent outside of the provider's backbone (except in the inter-AS
+ Option-B and Option-C cases, as described above, when it may appear
+ on inter-AS links). The format of the object is as follows:
+
+ o VPN-IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = 14
+
+ +-------------+-------------+-------------+-------------+
+ | |
+ + +
+ | VPN-IPv4 SrcAddress (12 bytes) |
+ + +
+ | |
+ +-------------+-------------+-------------+-------------+
+ | Reserved | SrcPort |
+ +-------------+-------------+-------------+-------------+
+
+
+ o VPN-IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = 15
+
+ +-------------+-------------+-------------+-------------+
+ | |
+ + +
+ | |
+ + VPN-IPv6 SrcAddress (24 bytes) +
+ / /
+ . .
+ / /
+ | |
+ +-------------+-------------+-------------+-------------+
+ | Reserved | SrcPort |
+ +-------------+-------------+-------------+-------------+
+
+
+
+
+Davie, et al. Standards Track [Page 21]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ The VPN-IPv4 SrcAddress (respectively, VPN-IPv6 SrcAddress) field
+ contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address
+ family encoded as specified in [RFC4364] (respectively, [RFC4659]).
+ The content of this field is discussed in Sections 3.2 and 3.3.
+
+ The SrcPort is identical to the SrcPort field in the IPv4 and IPv6
+ SENDER_TEMPLATE objects ([RFC2205]).
+
+ The Reserved field MUST be set to zero on transmit and ignored on
+ receipt.
+
+8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC Objects
+
+ The usage of the VPN-IPv4 (or VPN-IPv6) FILTER_SPEC object is
+ described in Sections 3.4 and 3.5. The VPN-IPv4 (or VPN-IPv6)
+ FILTER_SPEC object appears in RSVP messages that ordinarily contain a
+ FILTER_SPEC object and are sent between ingress PE and egress PE in
+ either direction (such as Resv, ResvError, and ResvTear). The object
+ MUST NOT be included in any RSVP messages that are sent outside of
+ the provider's backbone (except in the inter-AS Option-B and Option-C
+ cases, as described above, when it may appear on inter-AS links).
+
+ o VPN-IPv4 FILTER_SPEC object: Class = 10, C-Type = 14
+
+ Definition same as VPN-IPv4 SENDER_TEMPLATE object.
+
+
+ o VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = 15
+
+ Definition same as VPN-IPv6 SENDER_TEMPLATE object.
+
+ The content of the VPN-IPv4 SrcAddress (or VPN-IPv6 SrcAddress) field
+ is discussed in Sections 3.4 and 3.5.
+
+ The SrcPort is identical to the SrcPort field in the IPv4 and IPv6
+ SENDER_TEMPLATE objects ([RFC2205]).
+
+ The Reserved field MUST be set to zero on transmit and ignored on
+ receipt.
+
+8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP Objects
+
+ Usage of the VPN-IPv4 (or VPN-IPv6) RSVP_HOP object is described in
+ Sections 3.1 and 5.2.2. The VPN-IPv4 (VPN-IPv6) RSVP_HOP object is
+ used to establish signaling reachability between RSVP neighbors
+ separated by one or more Option-B ASBRs. This object may appear in
+ RSVP messages that carry an RSVP_HOP object, and that travel between
+ the ingress and egress PEs. It MUST NOT be included in any RSVP
+
+
+
+Davie, et al. Standards Track [Page 22]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ messages that are sent outside of the provider's backbone (except in
+ the inter-AS Option-B and Option-C cases, as described above, when it
+ may appear on inter-AS links). The format of the object is as
+ follows:
+
+ o VPN-IPv4 RSVP_HOP object: Class = 3, C-Type = 5
+
+ +-------------+-------------+-------------+-------------+
+ | IPv4 Next/Previous Hop Address (4 bytes) |
+ +-------------+-------------+-------------+-------------+
+ | |
+ + +
+ | VPN-IPv4 Next/Previous Hop Address (12 bytes) |
+ + +
+ | |
+ +-------------+-------------+-------------+-------------+
+ | Logical Interface Handle |
+ +-------------+-------------+-------------+-------------+
+
+
+ o VPN-IPv6 RSVP_HOP object: Class = 3, C-Type = 6
+
+ +-------------+-------------+-------------+-------------+
+ | |
+ + +
+ | |
+ + IPv6 Next/Previous Hop Address (16 bytes) +
+ | |
+ + +
+ | |
+ +-------------+-------------+-------------+-------------+
+ | |
+ + +
+ | |
+ + VPN-IPv6 Next/Previous Hop Address (24 bytes) +
+ / /
+ . .
+ / /
+ | |
+ +-------------+-------------+-------------+-------------+
+ | Logical Interface Handle |
+ +-------------+-------------+-------------+-------------+
+
+ The IPv4 Next/Previous Hop Address, IPv6 Next/Previous Hop Address,
+ and the Logical Interface Handle fields are identical to those of the
+ RSVP_HOP object ([RFC2205]).
+
+
+
+
+
+Davie, et al. Standards Track [Page 23]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ The VPN-IPv4 Next/Previous Hop Address (respectively, VPN-IPv6 Next/
+ Previous Hop Address) field contains an address of the VPN-IPv4
+ (respectively, VPN-IPv6) address family encoded as specified in
+ [RFC4364] (respectively, [RFC4659]). The content of this field is
+ discussed in Section 3.1.
+
+8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION Objects
+
+ The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SESSION object is
+ described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively,
+ AGGREGATE-IPv6-VPN) SESSION object appears in RSVP messages that
+ ordinarily contain a AGGREGATE-IPv4 (respectively, AGGREGATE-IPv6)
+ SESSION object as defined in [RFC3175] and are sent between ingress
+ PE and egress PE in either direction. The GENERIC-AGGREGATE-VPN-IPv4
+ (respectively, AGGREGATE-VPN-IPv6) SESSION object should appear in
+ all RSVP messages that ordinarily contain a GENERIC-AGGREGATE-IPv4
+ (respectively, GENERIC-AGGREGATE-IPv6) SESSION object as defined in
+ [RFC4860] 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 outside of the provider's backbone (except in the
+ inter-AS Option-B and Option-C cases, as described above, when it may
+ appear on inter-AS links). The processing rules for these objects
+ are otherwise identical to those of the VPN-IPv4 (respectively, VPN-
+ IPv6) SESSION object defined in Section 8.1. The format of the
+ object is as follows:
+
+ o AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = 21
+
+ +-------------+-------------+-------------+-------------+
+ | |
+ + +
+ | VPN-IPv4 DestAddress (12 bytes) |
+ + +
+ | |
+ +-------------+-------------+-------------+-------------+
+ | Reserved | Flags | Reserved | DSCP |
+ +-------------+-------------+-------------+-------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davie, et al. Standards Track [Page 24]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ o AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = 22
+
+ +-------------+-------------+-------------+-------------+
+ | |
+ + +
+ | |
+ + VPN-IPv6 DestAddress (24 bytes) +
+ / /
+ . .
+ / /
+ | |
+ +-------------+-------------+-------------+-------------+
+ | Reserved | Flags | Reserved | DSCP |
+ +-------------+-------------+-------------+-------------+
+
+ The VPN-IPv4 DestAddress (respectively, VPN-IPv6 DestAddress) field
+ contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address
+ family encoded as specified in [RFC4364] (respectively, [RFC4659]).
+ The content of this field is discussed in Sections 3.2 and 3.3.
+
+ The flags and DSCP are identical to the same fields of the AGGREGATE-
+ 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:
+ Class = 1, C-Type = 23
+
+ +-------------+-------------+-------------+-------------+
+ | |
+ + +
+ | VPN-IPv4 DestAddress (12 bytes) |
+ + +
+ | |
+ +-------------+-------------+-------------+-------------+
+ | Reserved | Flags | PHB-ID |
+ +-------------+-------------+-------------+-------------+
+ | Reserved | vDstPort |
+ +-------------+-------------+-------------+-------------+
+ | Extended vDstPort |
+ +-------------+-------------+-------------+-------------+
+
+
+
+
+
+
+
+
+
+Davie, et al. Standards Track [Page 25]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ o GENERIC-AGGREGATE-VPN-IPv6 SESSION object:
+ Class = 1, C-Type = 24
+
+ +-------------+-------------+-------------+-------------+
+ | |
+ + +
+ | |
+ + VPN-IPv6 DestAddress (24 bytes) +
+ / /
+ . .
+ / /
+ | |
+ +-------------+-------------+-------------+-------------+
+ | Reserved | Flags | PHB-ID |
+ +-------------+-------------+-------------+-------------+
+ | Reserved | vDstPort |
+ +-------------+-------------+-------------+-------------+
+ | Extended vDstPort |
+ +-------------+-------------+-------------+-------------+
+
+ The VPN-IPv4 DestAddress (respectively, VPN-IPv6 DestAddress) field
+ contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address
+ family encoded as specified in [RFC4364] (respectively, [RFC4659]).
+ The content of this field is discussed in Sections 3.2 and 3.3.
+
+ The flags, PHB-ID, vDstPort, and Extended vDstPort are identical to
+ the same fields of the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE-
+ 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
+
+ The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object
+ is described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively,
+ AGGREGATE-VPN-IPv6) SENDER_TEMPLATE object appears in RSVP messages
+ that ordinarily contain a AGGREGATE-IPv4 (respectively, AGGREGATE-
+ IPv6) SENDER_TEMPLATE object as defined in [RFC3175] and [RFC4860],
+ 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
+ outside of the provider's backbone (except in the inter-AS Option-B
+ and Option-C cases, as described above, when it may appear on
+ inter-AS links). The processing rules for these objects are
+ otherwise identical to those of the VPN-IPv4 (respectively, VPN-IPv6)
+ SENDER_TEMPLATE object defined in Section 8.2. The format of the
+ object is as follows:
+
+
+
+
+Davie, et al. Standards Track [Page 26]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ o AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object:
+ Class = 11, C-Type = 16
+
+ +-------------+-------------+-------------+-------------+
+ | |
+ + +
+ | VPN-IPv4 AggregatorAddress (12 bytes) |
+ + +
+ | |
+ +-------------+-------------+-------------+-------------+
+
+
+ o AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object:
+ Class = 11, C-Type = 17
+
+ +-------------+-------------+-------------+-------------+
+ | |
+ + +
+ | |
+ + VPN-IPv6 AggregatorAddress (24 bytes) +
+ / /
+ . .
+ / /
+ | |
+ +-------------+-------------+-------------+-------------+
+
+ The VPN-IPv4 AggregatorAddress (respectively, VPN-IPv6
+ AggregatorAddress) field contains an address of the VPN-IPv4
+ (respectively, VPN-IPv6) address family encoded as specified in
+ [RFC4364] (respectively, [RFC4659]). The content and processing
+ rules for these objects are similar to those of the VPN-IPv4
+ SENDER_TEMPLATE object defined in Section 8.2.
+
+ The flags and DSCP are identical to the same fields of the AGGREGATE-
+ IPv4 and AGGREGATE-IPv6 SESSION objects.
+
+8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC Objects
+
+ The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in
+ Section 7.3. The AGGREGATE-VPN-IPv4 FILTER_SPEC object appears in
+ RSVP messages that ordinarily contain a AGGREGATE-IPv4 FILTER_SPEC
+ object as defined in [RFC3175] and [RFC4860], 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 outside of the
+ provider's backbone (except in the inter-AS Option-B and Option-C
+ cases, as described above, when it may appear on inter-AS links).
+
+
+
+
+
+Davie, et al. Standards Track [Page 27]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ The processing rules for these objects are otherwise identical to
+ those of the VPN-IPv4 FILTER_SPEC object defined in Section 8.3. The
+ format of the object is as follows:
+
+ o AGGREGATE-VPN-IPv4 FILTER_SPEC object:
+ Class = 10, C-Type = 16
+
+ Definition same as AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object.
+
+
+ o AGGREGATE-VPN-IPv6 FILTER_SPEC object:
+ Class = 10, C-Type = 17
+
+ Definition same as AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object.
+
+9. IANA Considerations
+
+ Section 8 defines new objects. Therefore, IANA has modified the RSVP
+ parameters registry, 'Class Names, Class Numbers, and Class Types'
+ subregistry, and:
+
+ o assigned six new C-Types under the existing SESSION Class (Class
+ number 1), as follows:
+
+ Class
+ Number Class Name Reference
+ ------ ----------------------- ---------
+
+ 1 SESSION [RFC2205]
+
+ Class Types or C-Types:
+
+ .. ... ...
+ 19 VPN-IPv4 [RFC6016]
+ 20 VPN-IPv6 [RFC6016]
+ 21 AGGREGATE-VPN-IPv4 [RFC6016]
+ 22 AGGREGATE-VPN-IPv6 [RFC6016]
+ 23 GENERIC-AGGREGATE-VPN-IPv4 [RFC6016]
+ 24 GENERIC-AGGREGATE-VPN-IPv6 [RFC6016]
+
+ o assigned four new C-Types under the existing SENDER_TEMPLATE Class
+ (Class number 11), as follows:
+
+
+
+
+
+
+
+
+
+Davie, et al. Standards Track [Page 28]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ Class
+ Number Class Name Reference
+ ------ ----------------------- ---------
+
+ 11 SENDER_TEMPLATE [RFC2205]
+
+ Class Types or C-Types:
+
+ .. ... ...
+ 14 VPN-IPv4 [RFC6016]
+ 15 VPN-IPv6 [RFC6016]
+ 16 AGGREGATE-VPN-IPv4 [RFC6016]
+ 17 AGGREGATE-VPN-IPv6 [RFC6016]
+
+ o assigned four new C-Types under the existing FILTER_SPEC Class
+ (Class number 10), as follows:
+
+ Class
+ Number Class Name Reference
+ ------ ----------------------- ---------
+
+ 10 FILTER_SPEC [RFC2205]
+
+ Class Types or C-Types:
+
+ .. ... ...
+ 14 VPN-IPv4 [RFC6016]
+ 15 VPN-IPv6 [RFC6016]
+ 16 AGGREGATE-VPN-IPv4 [RFC6016]
+ 17 AGGREGATE-VPN-IPv6 [RFC6016]
+
+ o assigned two new C-Types under the existing RSVP_HOP Class (Class
+ number 3), as follows:
+
+ Class
+ Number Class Name Reference
+ ------ ----------------------- ---------
+
+ 3 RSVP_HOP [RFC2205]
+
+ Class Types or C-Types:
+
+ .. ... ...
+ 5 VPN-IPv4 [RFC6016]
+ 6 VPN-IPv6 [RFC6016]
+
+
+
+
+
+
+Davie, et al. Standards Track [Page 29]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ In addition, a new PathError code/value is required to identify a
+ signaling reachability failure and the need for a VPN-IPv4 or VPN-
+ IPv6 RSVP_HOP object as described in Section 5.2.2. Therefore, IANA
+ has modified the RSVP parameters registry, 'Error Codes and Globally-
+ Defined Error Value Sub-Codes' subregistry, and:
+
+ o assigned a new Error Code and sub-code, as follows:
+
+ 37 RSVP over MPLS Problem [RFC6016]
+
+ This Error Code has the following globally-defined Error
+ Value sub-codes:
+
+ 1 = RSVP_HOP not reachable across VPN [RFC6016]
+
+10. Security Considerations
+
+ [RFC4364] addresses the security considerations of BGP/MPLS VPNs in
+ general. General RSVP security considerations are discussed in
+ [RFC2205]. To ensure the integrity of RSVP, the RSVP Authentication
+ mechanisms defined in [RFC2747] and [RFC3097] SHOULD be supported.
+ Those protect RSVP message integrity hop-by-hop and provide node
+ authentication as well as replay protection, thereby protecting
+ against corruption and spoofing of RSVP messages. [RSVP-KEYING]
+ discusses applicability of various keying approaches for RSVP
+ Authentication. First, we note that the discussion about
+ applicability of group keying to an intra-provider environment where
+ RSVP hops are not IP hops is relevant to securing of RSVP among PEs
+ of a given Service Provider deploying the solution specified in the
+ present document. We note that the RSVP signaling in MPLS VPN is
+ likely to spread over multiple administrative domains (e.g., the
+ service provider operating the VPN service, and the customers of the
+ service). Therefore the considerations in [RSVP-KEYING] about inter-
+ domain issues are likely to apply.
+
+ Since RSVP messages travel through the L3VPN cloud directly addressed
+ to PE or ASBR routers (without IP Router Alert Option), P routers
+ remain isolated from RSVP messages signaling customer reservations.
+ Providers MAY choose to block PEs from sending datagrams with the
+ Router Alert Option to P routers as a security practice, without
+ impacting the functionality described herein.
+
+ Beyond those general issues, four specific issues are introduced by
+ this document: resource usage on PEs, resource usage in the provider
+ backbone, PE route advertisement outside the AS, and signaling
+ exposure to ASBRs and PEs. We discuss these in turn.
+
+
+
+
+
+Davie, et al. Standards Track [Page 30]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ A customer who makes resource reservations on the CE-PE links for his
+ sites is only competing for link resources with himself, as in
+ standard RSVP, at least in the common case where each CE-PE link is
+ dedicated to a single customer. Thus, from the perspective of the
+ CE-PE links, the present document does not introduce any new security
+ issues. However, because a PE typically serves multiple customers,
+ there is also the possibility that a customer might attempt to use
+ excessive computational resources on a PE (CPU cycles, memory, etc.)
+ by sending large numbers of RSVP messages to a PE. In the extreme,
+ this could represent a form of denial-of-service attack. In order to
+ prevent such an attack, a PE SHOULD support mechanisms to limit the
+ fraction of its processing resources that can be consumed by any one
+ CE or by the set of CEs of a given customer. For example, a PE might
+ implement a form of rate limiting on RSVP messages that it receives
+ from each CE. We observe that these security risks and measures
+ related to PE resource usage are very similar for any control-plane
+ protocol operating between CE and PE (e.g., RSVP, routing,
+ multicast).
+
+ The second concern arises only when the service provider chooses to
+ offer resource reservation across the backbone, as described in
+ Section 4. In this case, the concern may be that a single customer
+ might attempt to reserve a large fraction of backbone capacity,
+ perhaps with a coordinated effort from several different CEs, thus
+ denying service to other customers using the same backbone.
+ [RFC4804] provides some guidance on the security issues when RSVP
+ reservations are aggregated onto MPLS tunnels, which are applicable
+ to the situation described here. We note that a provider MAY use
+ local policy to limit the amount of resources that can be reserved by
+ a given customer from a particular PE, and that a policy server could
+ be used to control the resource usage of a given customer across
+ multiple PEs if desired. It is RECOMMENDED that an implementation of
+ this specification support local policy on the PE to control the
+ amount of resources that can be reserved by a given customer/CE.
+
+ Use of the VPN-IPv4 RSVP_HOP object requires exporting a PE VPN-IPv4
+ route to another AS, and potentially could allow unchecked access to
+ remote PEs if those routes were indiscriminately redistributed.
+ However, as described in Section 3.1, no route that is not within a
+ customer's VPN should ever be advertised to (or be reachable from)
+ that customer. If a PE uses a local address already within a
+ customer VRF (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 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 advertised to, or made reachable from, any customer. An
+ implementation of the present document MAY support such operation
+ using a "control-plane" VPN. Alternatively, ASBRs MAY implement the
+
+
+
+Davie, et al. Standards Track [Page 31]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ signaling procedures described in Section 5.2.1, even if admission
+ 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.
+
+ Finally, certain operations described herein (Section 3) require an
+ ASBR or PE to receive and locally process a signaling packet
+ addressed to the BGP next hop address advertised by that router.
+ This requirement does not strictly apply to MPLS/BGP VPNs [RFC4364].
+ This could be viewed as opening ASBRs and PEs to being directly
+ addressable by customer devices where they were not open before, and
+ could be considered a security issue. If a provider wishes to
+ mitigate this situation, the implementation MAY support the "control
+ protocol VPN" approach described above. That is, whenever a
+ 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",
+ 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
+ not reachable by customer devices.
+
+ [RFC4364] mentions use of IPsec both on a CE-CE basis and PE-PE
+ basis:
+
+ Cryptographic privacy is not provided by this architecture, 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 desired.
+
+ The use of cryptography on a PE-PE basis is for further study.
+
+ The procedures specified in the present document for admission
+ control on the PE-CE links (Section 3) are compatible with the use of
+ IPsec on a PE-PE basis. The optional procedures specified in the
+ present document for admission control in the Service Provider's
+ backbone (Section 4) are not compatible with the use of IPsec on a
+ PE-PE basis, since those procedures depend on the use of PE-PE MPLS
+ TE Tunnels to perform aggregate reservations through the Service
+ Provider's backbone.
+
+ [RFC4923] describes a model for RSVP operation through IPsec
+ Gateways. In a nutshell, a form of hierarchical RSVP reservation is
+ used where an RSVP reservation is made for the IPsec tunnel and then
+ individual RSVP reservations are admitted/aggregated over the tunnel
+ reservation. This model applies to the case where IPsec is used on a
+ CE-CE basis. In that situation, the procedures defined in the
+ present document would simply apply "as is" to the reservation
+ established for the IPsec tunnel(s).
+
+
+
+
+
+
+Davie, et al. Standards Track [Page 32]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+11. Acknowledgments
+
+ Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric
+ Rosen, Dan Tappan, and Lou Berger for their many contributions to
+ solving the problems described in this document. Thanks to Ferit
+ Yegenoglu for his useful comments. We also thank Stefan Santesson,
+ 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 MPLS VPN cloud. Also, we thank
+ Adrian Farrel for his detailed review and contributions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davie, et al. Standards Track [Page 33]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+Appendix A. Alternatives Considered
+
+ At this stage, a number of alternatives to the approach described
+ above have been considered. We document some of the approaches
+ considered here to assist future discussion. None of these have been
+ shown to improve upon the approach described above, and the first two
+ seem to have significant drawbacks relative to the approach described
+ above.
+
+Appendix A.1. GMPLS UNI Approach
+
+ [RFC4208] defines the GMPLS UNI. In Section 7, the operation of the
+ GMPLS UNI in a VPN context is briefly described. This is somewhat
+ similar to the problem tackled in the current document. The main
+ difference is that the GMPLS UNI is primarily aimed at the problem of
+ allowing a CE device to request the establishment of a Label Switched
+ Path (LSP) across the network on the other side of the UNI. Hence,
+ the procedures in [RFC4208] would lead to the establishment of an LSP
+ across the VPN provider's network for every RSVP request received,
+ which is not desired in this case.
+
+ To the extent possible, the approach described in this document is
+ consistent with [RFC4208], while filling in more of the details and
+ avoiding the problem noted above.
+
+Appendix A.2. Label Switching Approach
+
+ Implementations that always look at IP headers inside the MPLS label
+ on the egress PE can intercept Path messages and determine the
+ correct VRF and RSVP state by using a combination of the
+ encapsulating VPN label and the IP header. In our view, this is an
+ undesirable approach for two reasons. Firstly, it imposes a new MPLS
+ forwarding requirement for all data packets on the egress PE.
+ Secondly, it requires using the encapsulating MPLS label to identify
+ RSVP state, which runs counter to existing RSVP principle and
+ practice where all information used to identify RSVP state is
+ included within RSVP objects. RSVP extensions such as COPS/RSVP
+ [RFC2749] which re-encapsulate RSVP messages are incompatible with
+ this change.
+
+Appendix A.3. VRF Label Approach
+
+ Another approach to solving the problems described here involves the
+ use of label switching to ensure that Path, Resv, and other RSVP
+ messages are directed to the appropriate VRF on the next RSVP hop
+ (e.g., egress PE). One challenge with such an approach is that
+ [RFC4364] does not require labels to be allocated for VRFs, only for
+ customer prefixes, and that there is no simple, existing method for
+
+
+
+Davie, et al. Standards Track [Page 34]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ advertising the fact that a label is bound to a VRF. If, for
+ example, an ingress PE sent a Path message labelled with a VPN label
+ that was advertised by the egress PE for the prefix that matches the
+ destination address in the Path, there is a risk that the egress PE
+ would simply label-switch the Path directly on to the CE without
+ performing RSVP processing.
+
+ A second challenge with this approach is that an IP address needs to
+ be associated with a VRF and used as the PHOP address for the Path
+ message sent from ingress PE to egress PE. That address needs to be
+ reachable from the egress PE, and to exist in the VRF at the ingress
+ PE. Such an address is not always available in today's deployments,
+ so this represents at least a change to existing deployment
+ practices.
+
+Appendix A.4. VRF Label Plus VRF Address Approach
+
+ It is possible to create an approach based on that described in the
+ previous section that addresses the main challenges of that approach.
+ The basic approach has two parts: (a) define a new BGP Extended
+ Community to tag a route (and its associated MPLS label) as pointing
+ to a VRF; (b) allocate a "dummy" address to each VRF, specifically to
+ be used for routing RSVP messages. The dummy address (which could be
+ anything, e.g., a loopback of the associated PE) would be used as a
+ PHOP for Path messages and would serve as the destination for Resv
+ messages but would not be imported into VRFs of any other PE.
+
+References
+
+Normative References
+
+ [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
+ February 1997.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
+ Jamin, "Resource ReSerVation Protocol (RSVP) --
+ Version 1 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, "Aggregation of RSVP for IPv4 and IPv6
+ Reservations", RFC 3175, September 2001.
+
+
+
+Davie, et al. Standards Track [Page 35]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+ Networks (VPNs)", RFC 4364, February 2006.
+
+ [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le
+ Faucheur, "BGP-MPLS IP Virtual Private Network (VPN)
+ Extension for IPv6 VPN", RFC 4659, September 2006.
+
+ [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation
+ Protocol (RSVP) Reservations over MPLS TE/DS-TE
+ Tunnels", RFC 4804, February 2007.
+
+Informative References
+
+ [ALERT-USAGE] Le Faucheur, F., Ed., "IP Router Alert Considerations
+ and Usage", Work in Progress, July 2010.
+
+ [LER-OPTIONS] Smith, D., Mullooly, J., Jaeger, W., and T. Scholl,
+ "Requirements for Label Edge Router Forwarding of IPv4
+ Option Packets", Work in Progress, May 2010.
+
+ [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
+ Services in the Internet Architecture: an Overview",
+ RFC 1633, June 1994.
+
+ [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation
+ Protocol (RSVP) -- Version 1 Message Processing
+ Rules", RFC 2209, September 1997.
+
+ [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
+ Services", RFC 2210, September 1997.
+
+ [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
+ Cryptographic Authentication", RFC 2747, January 2000.
+
+ [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan,
+ R., and A. Sastry, "The COPS (Common Open Policy
+ Service) Protocol", RFC 2748, January 2000.
+
+ [RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan,
+ R., and A. Sastry, "COPS usage for RSVP", RFC 2749,
+ January 2000.
+
+ [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
+ F., and S. Molendini, "RSVP Refresh Overhead Reduction
+ Extensions", RFC 2961, April 2001.
+
+
+
+
+
+
+Davie, et al. Standards Track [Page 36]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+ [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
+ Authentication -- Updated Message Type Value",
+ RFC 3097, April 2001.
+
+ [RFC3473] Berger, L., "Generalized Multi-Protocol Label
+ Switching (GMPLS) Signaling Resource ReserVation
+ Protocol-Traffic Engineering (RSVP-TE) Extensions",
+ RFC 3473, January 2003.
+
+ [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
+ (LSP) Hierarchy with Generalized Multi-Protocol Label
+ Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
+ October 2005.
+
+ [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
+ "Generalized Multiprotocol Label Switching (GMPLS)
+ User-Network Interface (UNI): Resource ReserVation
+ Protocol-Traffic Engineering (RSVP-TE) Support for the
+ Overlay Model", RFC 4208, October 2005.
+
+ [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C.,
+ and M. Davenport, "Generic Aggregate Resource
+ ReSerVation Protocol (RSVP) Reservations", RFC 4860,
+ May 2007.
+
+ [RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS)
+ Signaling in a Nested Virtual Private Network",
+ RFC 4923, August 2007.
+
+ [RFC5824] Kumaki, K., Zhang, R., and Y. Kamite, "Requirements
+ for Supporting Customer Resource ReSerVation Protocol
+ (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a
+ BGP/MPLS IP-VPN", RFC 5824, April 2010.
+
+ [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General
+ Internet Signalling Transport", RFC 5971,
+ October 2010.
+
+ [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS
+ Signaling Layer Protocol (NSLP) for Quality-of-Service
+ Signaling", RFC 5974, October 2010.
+
+ [RSVP-KEYING] Behringer, M., Faucheur, F., and B. Weis,
+ "Applicability of Keying Methods for RSVP Security",
+ Work in Progress, September 2010.
+
+
+
+
+
+
+Davie, et al. Standards Track [Page 37]
+
+RFC 6016 RSVP for L3VPNs October 2010
+
+
+Authors' Addresses
+
+ Bruce Davie
+ Cisco Systems, Inc.
+ 1414 Mass. Ave.
+ Boxborough, MA 01719
+ USA
+
+ EMail: bsd@cisco.com
+
+
+ Francois Le Faucheur
+ Cisco Systems, Inc.
+ Village d'Entreprise Green Side - Batiment T3
+ 400, Avenue de Roumanille
+ Biot Sophia-Antipolis 06410
+ France
+
+ EMail: flefauch@cisco.com
+
+
+ Ashok Narayanan
+ Cisco Systems, Inc.
+ 1414 Mass. Ave.
+ Boxborough, MA 01719
+ USA
+
+ EMail: ashokn@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davie, et al. Standards Track [Page 38]
+