<pre>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


  <span class="h1">Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs</span>

Abstract

   <a href="./rfc4364">RFC 4364</a> and <a href="./rfc4659">RFC 4659</a> 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 <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6016">http://www.rfc-editor.org/info/rfc6016</a>.

















<span class="grey">Davie, et al.                Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.

























<span class="grey">Davie, et al.                Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
      <a href="#section-1.1">1.1</a>. Terminology ................................................<a href="#page-5">5</a>
      <a href="#section-1.2">1.2</a>. Requirements Language ......................................<a href="#page-5">5</a>
   <a href="#section-2">2</a>. Problem Statement ...............................................<a href="#page-5">5</a>
      <a href="#section-2.1">2.1</a>. Model of Operation .........................................<a href="#page-8">8</a>
   <a href="#section-3">3</a>. Admission Control on PE-CE Links ................................<a href="#page-9">9</a>
      <a href="#section-3.1">3.1</a>. New Objects of Type VPN-IPv4 ...............................<a href="#page-9">9</a>
      <a href="#section-3.2">3.2</a>. Path Message Processing at Ingress PE .....................<a href="#page-11">11</a>
      <a href="#section-3.3">3.3</a>. Path Message Processing at Egress PE ......................<a href="#page-12">12</a>
      <a href="#section-3.4">3.4</a>. Resv Processing at Egress PE ..............................<a href="#page-13">13</a>
      <a href="#section-3.5">3.5</a>. Resv Processing at Ingress PE .............................<a href="#page-13">13</a>
      <a href="#section-3.6">3.6</a>. Other RSVP Messages .......................................<a href="#page-14">14</a>
   <a href="#section-4">4</a>. Admission Control in Provider's Backbone .......................<a href="#page-14">14</a>
   <a href="#section-5">5</a>. Inter-AS Operation .............................................<a href="#page-15">15</a>
      <a href="#section-5.1">5.1</a>. Inter-AS Option A .........................................<a href="#page-15">15</a>
      <a href="#section-5.2">5.2</a>. Inter-AS Option B .........................................<a href="#page-15">15</a>
           <a href="#section-5.2.1">5.2.1</a>. Admission Control on ASBR ..........................<a href="#page-16">16</a>
           <a href="#section-5.2.2">5.2.2</a>. No Admission Control on ASBR .......................<a href="#page-16">16</a>
      <a href="#section-5.3">5.3</a>. Inter-AS Option C .........................................<a href="#page-17">17</a>
   <a href="#section-6">6</a>. Operation with RSVP Disabled ...................................<a href="#page-17">17</a>
   <a href="#section-7">7</a>. Other RSVP Procedures ..........................................<a href="#page-18">18</a>
      <a href="#section-7.1">7.1</a>. Refresh Overhead Reduction ................................<a href="#page-18">18</a>
      <a href="#section-7.2">7.2</a>. Cryptographic Authentication ..............................<a href="#page-18">18</a>
      <a href="#section-7.3">7.3</a>. RSVP Aggregation ..........................................<a href="#page-19">19</a>
      <a href="#section-7.4">7.4</a>. Support for CE-CE RSVP-TE .................................<a href="#page-19">19</a>
   <a href="#section-8">8</a>. Object Definitions .............................................<a href="#page-20">20</a>
      <a href="#section-8.1">8.1</a>. VPN-IPv4 and VPN-IPv6 SESSION Objects .....................<a href="#page-20">20</a>
      <a href="#section-8.2">8.2</a>. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE Objects .............<a href="#page-21">21</a>
      <a href="#section-8.3">8.3</a>. VPN-IPv4 and VPN-IPv6 FILTER_SPEC Objects .................<a href="#page-22">22</a>
      <a href="#section-8.4">8.4</a>. VPN-IPv4 and VPN-IPv6 RSVP_HOP Objects ....................<a href="#page-22">22</a>
      <a href="#section-8.5">8.5</a>. Aggregated VPN-IPv4 and VPN-IPv6 SESSION Objects ..........<a href="#page-24">24</a>
      8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6
           SENDER_TEMPLATE Objects ...................................<a href="#page-26">26</a>
      8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6
           FILTER_SPEC Objects .......................................<a href="#page-27">27</a>
   <a href="#section-9">9</a>. IANA Considerations ............................................<a href="#page-28">28</a>
   <a href="#section-10">10</a>. Security Considerations .......................................<a href="#page-30">30</a>
   <a href="#section-11">11</a>. Acknowledgments ...............................................<a href="#page-33">33</a>
   <a href="#appendix-A">Appendix A</a>.   Alternatives Considered .............................<a href="#page-34">34</a>
      <a href="#appendix-A.1">A.1</a>. GMPLS UNI Approach ........................................<a href="#page-34">34</a>
      <a href="#appendix-A.2">A.2</a>. Label Switching Approach ..................................<a href="#page-34">34</a>
      <a href="#appendix-A.3">A.3</a>. VRF Label Approach ........................................<a href="#page-34">34</a>
      <a href="#appendix-A.4">A.4</a>. VRF Label Plus VRF Address Approach .......................<a href="#page-35">35</a>
   References ........................................................<a href="#page-35">35</a>
      Normative References ...........................................<a href="#page-35">35</a>
      Informative References .........................................<a href="#page-36">36</a>



<span class="grey">Davie, et al.                Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   [<a id="ref-RFC4364">RFC4364</a>] and [<a href="./rfc4659" title="&quot;BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN&quot;">RFC4659</a>] define a Layer 3 VPN service known as BGP/
   MPLS VPNs for IPv4 and for IPv6, respectively.  [<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>] defines the
   Resource Reservation Protocol (RSVP), which may be used to perform
   admission control as part of the Integrated Services (Int-Serv)
   architecture [<a href="./rfc1633" title="&quot;Integrated Services in the Internet Architecture: an Overview&quot;">RFC1633</a>][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 ([<a href="./rfc2113" title="&quot;IP Router Alert Option&quot;">RFC2113</a>], [<a href="./rfc2711" title="&quot;IPv6 Router Alert Option&quot;">RFC2711</a>]) 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 <a href="#section-2">Section 2</a>.

   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 [<a href="./rfc5974" title="&quot;NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling&quot;">RFC5974</a>] and General Internet Signaling Transport (GIST)
   protocol [<a href="./rfc5971" title="&quot;GIST: General Internet Signalling Transport&quot;">RFC5971</a>].



<span class="grey">Davie, et al.                Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Terminology</span>

   This document draws freely on the terminology defined in [<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>]
   and [<a href="./rfc4364" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC4364</a>].  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.

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Requirements Language</span>

   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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Problem Statement</span>

   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.




<span class="grey">Davie, et al.                Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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 [<a href="#ref-ALERT-USAGE" title="&quot;IP Router Alert Considerations and Usage&quot;">ALERT-USAGE</a>].  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 [<a href="#ref-LER-OPTIONS" title="&quot;Requirements for Label Edge Router Forwarding of IPv4 Option Packets&quot;">LER-OPTIONS</a>].  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 ([<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>], [<a href="./rfc2209" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules&quot;">RFC2209</a>]), which relies solely on RSVP
   objects to identify sessions.  Further, it is incompatible with
   protocols like COPS/RSVP (Common Open Policy Service) ([<a href="./rfc2748" title="&quot;The COPS (Common Open Policy Service) Protocol&quot;">RFC2748</a>],



<span class="grey">Davie, et al.                Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   [<a href="./rfc2749" title="&quot;COPS usage for RSVP&quot;">RFC2749</a>]), 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 [<a href="./rfc3175" title="&quot;Aggregation of RSVP for IPv4 and IPv6 Reservations&quot;">RFC3175</a>] and
   [<a href="./rfc4804" title="&quot;Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels&quot;">RFC4804</a>], 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--&gt;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





<span class="grey">Davie, et al.                Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Model of Operation</span>

   Figure 1 illustrates the basic model of operation with which this
   document is concerned.

                      --------------------------
                     /       Provider           \
        |----|      |         Backbone           |      |----|
Sender-&gt;| CE1|  |-----|                       |-----|   |CE2 |-&gt;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.



<span class="grey">Davie, et al.                Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Admission Control on PE-CE Links</span>

   In the following sections, we trace through the steps outlined in
   <a href="#section-2.1">Section 2.1</a> 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 <a href="#section-8">Section 8</a>.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  New Objects of Type VPN-IPv4</span>

   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.







<span class="grey">Davie, et al.                Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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 [<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>].  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
   [<a href="./rfc2961" title="&quot;RSVP Refresh Overhead Reduction Extensions&quot;">RFC2961</a>], authentication [<a href="./rfc2747" title="&quot;RSVP Cryptographic Authentication&quot;">RFC2747</a>], 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.






<span class="grey">Davie, et al.                Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Path Message Processing at Ingress PE</span>

   When a Path message arrives at the ingress PE (step 3 of <a href="#section-2.1">Section 2.1</a>)
   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 [<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>].  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 <a href="#section-3.3">Section 3.3</a>.
   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 [<a href="./rfc4206" title="&quot;Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)&quot;">RFC4206</a>] and [<a href="./rfc4804" title="&quot;Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels&quot;">RFC4804</a>].

   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



<span class="grey">Davie, et al.                Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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 <a href="#section-3.1">Section 3.1</a>.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Path Message Processing at Egress PE</span>

   When a Path message arrives at the egress PE, (step 4 of <a href="#section-2.1">Section 2.1</a>)
   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 [<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>].





<span class="grey">Davie, et al.                Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Resv Processing at Egress PE</span>

   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
   <a href="#section-2.1">Section 2.1</a>).  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 <a href="#section-3.1">Section 3.1</a>.  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 <a href="#section-3.1">Section 3.1</a>.  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.

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>.  Resv Processing at Ingress PE</span>

   Upon receiving a Resv message at the ingress PE (step 8 of
   <a href="#section-2.1">Section 2.1</a>) 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.








<span class="grey">Davie, et al.                Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>.  Other RSVP Messages</span>

   Processing of PathError, PathTear, ResvError, ResvTear, and ResvConf
   messages is generally straightforward and follows the rules of
   [<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>].  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.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Admission Control in Provider's Backbone</span>

   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
   [<a href="./rfc4804" title="&quot;Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels&quot;">RFC4804</a>].  MPLS-TE tunnels can be established between PEs as a means
   to perform aggregate admission control in the backbone.




<span class="grey">Davie, et al.                Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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
   [<a href="./rfc4804" title="&quot;Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels&quot;">RFC4804</a>] uses the IF_ID RSVP_HOP object to identify the tunnel
   across the backbone, rather than the simple RSVP_HOP object described
   in <a href="#section-3.2">Section 3.2</a>.  The procedures of [<a href="./rfc4804" title="&quot;Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels&quot;">RFC4804</a>] 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 [<a href="./rfc3175" title="&quot;Aggregation of RSVP for IPv4 and IPv6 Reservations&quot;">RFC3175</a>].

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Inter-AS Operation</span>

   [<a id="ref-RFC4364">RFC4364</a>] 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.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Inter-AS Option A</span>

   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 <a href="#section-3">Section 3</a> 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.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Inter-AS Option B</span>

   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



<span class="grey">Davie, et al.                Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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.

<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>.  Admission Control on ASBR</span>

   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
   [<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>]).  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 [<a href="./rfc2209" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules&quot;">RFC2209</a>], no customer VRF
   awareness is required on the ASBR.

<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>.  No Admission Control on ASBR</span>

   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 <a href="#section-3.1">Section 3.1</a> 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 <a href="#section-3.2">Section 3.2</a>, 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 <a href="#section-3.3">Section 3.3</a> if it is a PE, or <a href="#section-5.2.1">Section 5.2.1</a> if it is an



<span class="grey">Davie, et al.                Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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 <a href="#section-5.2.1">Section 5.2.1</a>
   (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 <a href="#section-9">Section 9</a>) 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.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Inter-AS Option C</span>

   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 <a href="#section-3">Section 3</a>.  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 <a href="#section-4">Section 4</a>.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Operation with RSVP Disabled</span>

   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-&gt;PE direction



<span class="grey">Davie, et al.                Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Other RSVP Procedures</span>

   This section describes modifications to other RSVP procedures
   introduced by MPLS VPNs.

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Refresh Overhead Reduction</span>

   The following points ought to be noted regarding RSVP refresh
   overhead reduction [<a href="./rfc2961" title="&quot;RSVP Refresh Overhead Reduction Extensions&quot;">RFC2961</a>] 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 <a href="./rfc2961#section-5.3">Section&nbsp;5.3 of [RFC2961]</a> 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.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  Cryptographic Authentication</span>

   The following points ought to be noted regarding RSVP cryptographic
   authentication ([<a href="./rfc2747" title="&quot;RSVP Cryptographic Authentication&quot;">RFC2747</a>]) 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.




<span class="grey">Davie, et al.                Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>.  RSVP Aggregation</span>

   [<a id="ref-RFC3175">RFC3175</a>] and [<a href="./rfc4860" title="&quot;Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations&quot;">RFC4860</a>] 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 <a href="#section-3">3</a> and <a href="#section-4">4</a> MUST be followed for aggregate
         RSVP sessions.  The corresponding new SESSION, SENDER_TEMPLATE,
         and FILTERSPEC objects are defined in <a href="#section-8">Section 8</a>.

      *  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 [<a href="./rfc4860" title="&quot;Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations&quot;">RFC4860</a>]) MUST be
         conveyed unmodified across the MPLS VPN.

<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>.  Support for CE-CE RSVP-TE</span>

   [<a id="ref-RFC5824">RFC5824</a>] 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 [<a href="./rfc5824" title="&quot;Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN&quot;">RFC5824</a>].  To the extent that this document uses
   signaling extensions described in [<a href="./rfc3473" title="&quot;Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions&quot;">RFC3473</a>] 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.



<span class="grey">Davie, et al.                Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Object Definitions</span>

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  VPN-IPv4 and VPN-IPv6 SESSION Objects</span>

   The usage of the VPN-IPv4 (or VPN-IPv6) SESSION object is described
   in Sections <a href="#section-3.2">3.2</a> to <a href="#section-3.6">3.6</a>.  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 ([<a href="./rfc4659" title="&quot;BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN&quot;">RFC4659</a>]) instead of an VPN-IPv4
   address ([<a href="./rfc4364" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC4364</a>]).

   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          |
              +-------------+-------------+-------------+-------------+





<span class="grey">Davie, et al.                Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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 [<a href="./rfc4364" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC4364</a>] (respectively, [<a href="./rfc4659" title="&quot;BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN&quot;">RFC4659</a>]).
   The content of this field is discussed in Sections <a href="#section-3.2">3.2</a> and <a href="#section-3.3">3.3</a>.

   The protocol ID, flags, and DstPort are identical to the same fields
   in the IPv4 and IPv6 SESSION objects ([<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>]).

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE Objects</span>

   The usage of the VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object is
   described in Sections <a href="#section-3.2">3.2</a> and <a href="#section-3.3">3.3</a>.  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          |
              +-------------+-------------+-------------+-------------+




<span class="grey">Davie, et al.                Standards Track                   [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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 [<a href="./rfc4364" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC4364</a>] (respectively, [<a href="./rfc4659" title="&quot;BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN&quot;">RFC4659</a>]).
   The content of this field is discussed in Sections <a href="#section-3.2">3.2</a> and <a href="#section-3.3">3.3</a>.

   The SrcPort is identical to the SrcPort field in the IPv4 and IPv6
   SENDER_TEMPLATE objects ([<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>]).

   The Reserved field MUST be set to zero on transmit and ignored on
   receipt.

<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>.  VPN-IPv4 and VPN-IPv6 FILTER_SPEC Objects</span>

   The usage of the VPN-IPv4 (or VPN-IPv6) FILTER_SPEC object is
   described in Sections <a href="#section-3.4">3.4</a> and <a href="#section-3.5">3.5</a>.  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 <a href="#section-3.4">3.4</a> and <a href="#section-3.5">3.5</a>.

   The SrcPort is identical to the SrcPort field in the IPv4 and IPv6
   SENDER_TEMPLATE objects ([<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>]).

   The Reserved field MUST be set to zero on transmit and ignored on
   receipt.

<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>.  VPN-IPv4 and VPN-IPv6 RSVP_HOP Objects</span>

   Usage of the VPN-IPv4 (or VPN-IPv6) RSVP_HOP object is described in
   Sections <a href="#section-3.1">3.1</a> and <a href="#section-5.2.2">5.2.2</a>.  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



<span class="grey">Davie, et al.                Standards Track                   [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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 ([<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>]).





<span class="grey">Davie, et al.                Standards Track                   [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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
   [<a href="./rfc4364" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC4364</a>] (respectively, [<a href="./rfc4659" title="&quot;BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN&quot;">RFC4659</a>]).  The content of this field is
   discussed in <a href="#section-3.1">Section 3.1</a>.

<span class="h3"><a class="selflink" id="section-8.5" href="#section-8.5">8.5</a>.  Aggregated VPN-IPv4 and VPN-IPv6 SESSION Objects</span>

   The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SESSION object is
   described in <a href="#section-7.3">Section 7.3</a>.  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 [<a href="./rfc3175" title="&quot;Aggregation of RSVP for IPv4 and IPv6 Reservations&quot;">RFC3175</a>] 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
   [<a href="./rfc4860" title="&quot;Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations&quot;">RFC4860</a>] 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 <a href="#section-8.1">Section 8.1</a>.  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    |
              +-------------+-------------+-------------+-------------+














<span class="grey">Davie, et al.                Standards Track                   [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


         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 [<a href="./rfc4364" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC4364</a>] (respectively, [<a href="./rfc4659" title="&quot;BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN&quot;">RFC4659</a>]).
   The content of this field is discussed in Sections <a href="#section-3.2">3.2</a> and <a href="#section-3.3">3.3</a>.

   The flags and DSCP are identical to the same fields of the AGGREGATE-
   IPv4 and AGGREGATE-IPv6 SESSION objects ([<a href="./rfc3175" title="&quot;Aggregation of RSVP for IPv4 and IPv6 Reservations&quot;">RFC3175</a>]).

   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                  |
              +-------------+-------------+-------------+-------------+









<span class="grey">Davie, et al.                Standards Track                   [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


         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 [<a href="./rfc4364" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC4364</a>] (respectively, [<a href="./rfc4659" title="&quot;BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN&quot;">RFC4659</a>]).
   The content of this field is discussed in Sections <a href="#section-3.2">3.2</a> and <a href="#section-3.3">3.3</a>.

   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 ([<a href="./rfc4860" title="&quot;Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations&quot;">RFC4860</a>]).

   The Reserved field MUST be set to zero on transmit and ignored on
   receipt.

<span class="h3"><a class="selflink" id="section-8.6" href="#section-8.6">8.6</a>.  AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 SENDER_TEMPLATE Objects</span>

   The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object
   is described in <a href="#section-7.3">Section 7.3</a>.  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 [<a href="./rfc3175" title="&quot;Aggregation of RSVP for IPv4 and IPv6 Reservations&quot;">RFC3175</a>] and [<a href="./rfc4860" title="&quot;Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations&quot;">RFC4860</a>],
   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 <a href="#section-8.2">Section 8.2</a>.  The format of the
   object is as follows:




<span class="grey">Davie, et al.                Standards Track                   [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


         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
   [<a href="./rfc4364" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC4364</a>] (respectively, [<a href="./rfc4659" title="&quot;BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN&quot;">RFC4659</a>]).  The content and processing
   rules for these objects are similar to those of the VPN-IPv4
   SENDER_TEMPLATE object defined in <a href="#section-8.2">Section 8.2</a>.

   The flags and DSCP are identical to the same fields of the AGGREGATE-
   IPv4 and AGGREGATE-IPv6 SESSION objects.

<span class="h3"><a class="selflink" id="section-8.7" href="#section-8.7">8.7</a>.  AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC Objects</span>

   The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in
   <a href="#section-7.3">Section 7.3</a>.  The AGGREGATE-VPN-IPv4 FILTER_SPEC object appears in
   RSVP messages that ordinarily contain a AGGREGATE-IPv4 FILTER_SPEC
   object as defined in [<a href="./rfc3175" title="&quot;Aggregation of RSVP for IPv4 and IPv6 Reservations&quot;">RFC3175</a>] and [<a href="./rfc4860" title="&quot;Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations&quot;">RFC4860</a>], 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).





<span class="grey">Davie, et al.                Standards Track                   [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   The processing rules for these objects are otherwise identical to
   those of the VPN-IPv4 FILTER_SPEC object defined in <a href="#section-8.3">Section 8.3</a>.  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.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  IANA Considerations</span>

   <a href="#section-8">Section 8</a> 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                               [<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>]

              Class Types or C-Types:

               ..   ...                             ...
               19   VPN-IPv4                        [<a href="./rfc6016">RFC6016</a>]
               20   VPN-IPv6                        [<a href="./rfc6016">RFC6016</a>]
               21   AGGREGATE-VPN-IPv4              [<a href="./rfc6016">RFC6016</a>]
               22   AGGREGATE-VPN-IPv6              [<a href="./rfc6016">RFC6016</a>]
               23   GENERIC-AGGREGATE-VPN-IPv4      [<a href="./rfc6016">RFC6016</a>]
               24   GENERIC-AGGREGATE-VPN-IPv6      [<a href="./rfc6016">RFC6016</a>]

   o  assigned four new C-Types under the existing SENDER_TEMPLATE Class
      (Class number 11), as follows:









<span class="grey">Davie, et al.                Standards Track                   [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


      Class
      Number  Class Name                            Reference
      ------  -----------------------               ---------

          11  SENDER_TEMPLATE                       [<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>]

              Class Types or C-Types:

               ..   ...                             ...
               14   VPN-IPv4                        [<a href="./rfc6016">RFC6016</a>]
               15   VPN-IPv6                        [<a href="./rfc6016">RFC6016</a>]
               16   AGGREGATE-VPN-IPv4              [<a href="./rfc6016">RFC6016</a>]
               17   AGGREGATE-VPN-IPv6              [<a href="./rfc6016">RFC6016</a>]

   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                           [<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>]

              Class Types or C-Types:

               ..   ...                             ...
               14   VPN-IPv4                        [<a href="./rfc6016">RFC6016</a>]
               15   VPN-IPv6                        [<a href="./rfc6016">RFC6016</a>]
               16   AGGREGATE-VPN-IPv4              [<a href="./rfc6016">RFC6016</a>]
               17   AGGREGATE-VPN-IPv6              [<a href="./rfc6016">RFC6016</a>]

   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                              [<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>]

              Class Types or C-Types:

               ..   ...                             ...
                5   VPN-IPv4                        [<a href="./rfc6016">RFC6016</a>]
                6   VPN-IPv6                        [<a href="./rfc6016">RFC6016</a>]






<span class="grey">Davie, et al.                Standards Track                   [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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 <a href="#section-5.2.2">Section 5.2.2</a>.  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                      [<a href="./rfc6016">RFC6016</a>]

         This Error Code has the following globally-defined Error
         Value sub-codes:

           1 = RSVP_HOP not reachable across VPN     [<a href="./rfc6016">RFC6016</a>]

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Security Considerations</span>

   [<a id="ref-RFC4364">RFC4364</a>] addresses the security considerations of BGP/MPLS VPNs in
   general.  General RSVP security considerations are discussed in
   [<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>].  To ensure the integrity of RSVP, the RSVP Authentication
   mechanisms defined in [<a href="./rfc2747" title="&quot;RSVP Cryptographic Authentication&quot;">RFC2747</a>] and [<a href="./rfc3097" title="&quot;RSVP Cryptographic Authentication -- Updated Message Type Value&quot;">RFC3097</a>] 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.  [<a href="#ref-RSVP-KEYING" title="&quot;Applicability of Keying Methods for RSVP Security&quot;">RSVP-KEYING</a>]
   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 [<a href="#ref-RSVP-KEYING" title="&quot;Applicability of Keying Methods for RSVP Security&quot;">RSVP-KEYING</a>] 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.





<span class="grey">Davie, et al.                Standards Track                   [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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
   <a href="#section-4">Section 4</a>.  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.
   [<a href="./rfc4804" title="&quot;Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels&quot;">RFC4804</a>] 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 <a href="#section-3.1">Section 3.1</a>, 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



<span class="grey">Davie, et al.                Standards Track                   [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   signaling procedures described in <a href="#section-5.2.1">Section 5.2.1</a>, 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 (<a href="#section-3">Section 3</a>) 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 [<a href="./rfc4364" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC4364</a>].
   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.

   [<a id="ref-RFC4364">RFC4364</a>] 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 (<a href="#section-3">Section 3</a>) 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 (<a href="#section-4">Section 4</a>) 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.

   [<a id="ref-RFC4923">RFC4923</a>] 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).






<span class="grey">Davie, et al.                Standards Track                   [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  Acknowledgments</span>

   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.








































<span class="grey">Davie, et al.                Standards Track                   [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Alternatives Considered</span>

   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.

<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">Appendix A.1</a>.  GMPLS UNI Approach</span>

   [<a id="ref-RFC4208">RFC4208</a>] defines the GMPLS UNI.  In <a href="#section-7">Section 7</a>, 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 [<a href="./rfc4208" title="&quot;Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model&quot;">RFC4208</a>] 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 [<a href="./rfc4208" title="&quot;Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model&quot;">RFC4208</a>], while filling in more of the details and
   avoiding the problem noted above.

<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">Appendix A.2</a>.  Label Switching Approach</span>

   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
   [<a href="./rfc2749" title="&quot;COPS usage for RSVP&quot;">RFC2749</a>] which re-encapsulate RSVP messages are incompatible with
   this change.

<span class="h3"><a class="selflink" id="appendix-A.3" href="#appendix-A.3">Appendix A.3</a>.  VRF Label Approach</span>

   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
   [<a href="./rfc4364" title="&quot;BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC4364</a>] does not require labels to be allocated for VRFs, only for
   customer prefixes, and that there is no simple, existing method for



<span class="grey">Davie, et al.                Standards Track                   [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   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.

<span class="h3"><a class="selflink" id="appendix-A.4" href="#appendix-A.4">Appendix A.4</a>.  VRF Label Plus VRF Address Approach</span>

   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

   [<a id="ref-RFC2113">RFC2113</a>]      Katz, D., "IP Router Alert Option", <a href="./rfc2113">RFC 2113</a>,
                  February 1997.

   [<a id="ref-RFC2119">RFC2119</a>]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC2205">RFC2205</a>]      Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
                  Jamin, "Resource ReSerVation Protocol (RSVP) --
                  Version 1 Functional Specification", <a href="./rfc2205">RFC 2205</a>,
                  September 1997.

   [<a id="ref-RFC2711">RFC2711</a>]      Partridge, C. and A. Jackson, "IPv6 Router Alert
                  Option", <a href="./rfc2711">RFC 2711</a>, October 1999.

   [<a id="ref-RFC3175">RFC3175</a>]      Baker, F., Iturralde, C., Le Faucheur, F., and B.
                  Davie, "Aggregation of RSVP for IPv4 and IPv6
                  Reservations", <a href="./rfc3175">RFC 3175</a>, September 2001.



<span class="grey">Davie, et al.                Standards Track                   [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   [<a id="ref-RFC4364">RFC4364</a>]      Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
                  Networks (VPNs)", <a href="./rfc4364">RFC 4364</a>, February 2006.

   [<a id="ref-RFC4659">RFC4659</a>]      De Clercq, J., Ooms, D., Carugi, M., and F. Le
                  Faucheur, "BGP-MPLS IP Virtual Private Network (VPN)
                  Extension for IPv6 VPN", <a href="./rfc4659">RFC 4659</a>, September 2006.

   [<a id="ref-RFC4804">RFC4804</a>]      Le Faucheur, F., "Aggregation of Resource ReSerVation
                  Protocol (RSVP) Reservations over MPLS TE/DS-TE
                  Tunnels", <a href="./rfc4804">RFC 4804</a>, February 2007.

Informative References

   [<a id="ref-ALERT-USAGE">ALERT-USAGE</a>]  Le Faucheur, F., Ed., "IP Router Alert Considerations
                  and Usage", Work in Progress, July 2010.

   [<a id="ref-LER-OPTIONS">LER-OPTIONS</a>]  Smith, D., Mullooly, J., Jaeger, W., and T. Scholl,
                  "Requirements for Label Edge Router Forwarding of IPv4
                  Option Packets", Work in Progress, May 2010.

   [<a id="ref-RFC1633">RFC1633</a>]      Braden, B., Clark, D., and S. Shenker, "Integrated
                  Services in the Internet Architecture: an Overview",
                  <a href="./rfc1633">RFC 1633</a>, June 1994.

   [<a id="ref-RFC2209">RFC2209</a>]      Braden, B. and L. Zhang, "Resource ReSerVation
                  Protocol (RSVP) -- Version 1 Message Processing
                  Rules", <a href="./rfc2209">RFC 2209</a>, September 1997.

   [<a id="ref-RFC2210">RFC2210</a>]      Wroclawski, J., "The Use of RSVP with IETF Integrated
                  Services", <a href="./rfc2210">RFC 2210</a>, September 1997.

   [<a id="ref-RFC2747">RFC2747</a>]      Baker, F., Lindell, B., and M. Talwar, "RSVP
                  Cryptographic Authentication", <a href="./rfc2747">RFC 2747</a>, January 2000.

   [<a id="ref-RFC2748">RFC2748</a>]      Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan,
                  R., and A. Sastry, "The COPS (Common Open Policy
                  Service) Protocol", <a href="./rfc2748">RFC 2748</a>, January 2000.

   [<a id="ref-RFC2749">RFC2749</a>]      Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan,
                  R., and A. Sastry, "COPS usage for RSVP", <a href="./rfc2749">RFC 2749</a>,
                  January 2000.

   [<a id="ref-RFC2961">RFC2961</a>]      Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
                  F., and S. Molendini, "RSVP Refresh Overhead Reduction
                  Extensions", <a href="./rfc2961">RFC 2961</a>, April 2001.






<span class="grey">Davie, et al.                Standards Track                   [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


   [<a id="ref-RFC3097">RFC3097</a>]      Braden, R. and L. Zhang, "RSVP Cryptographic
                  Authentication -- Updated Message Type Value",
                  <a href="./rfc3097">RFC 3097</a>, April 2001.

   [<a id="ref-RFC3473">RFC3473</a>]      Berger, L., "Generalized Multi-Protocol Label
                  Switching (GMPLS) Signaling Resource ReserVation
                  Protocol-Traffic Engineering (RSVP-TE) Extensions",
                  <a href="./rfc3473">RFC 3473</a>, January 2003.

   [<a id="ref-RFC4206">RFC4206</a>]      Kompella, K. and Y. Rekhter, "Label Switched Paths
                  (LSP) Hierarchy with Generalized Multi-Protocol Label
                  Switching (GMPLS) Traffic Engineering (TE)", <a href="./rfc4206">RFC 4206</a>,
                  October 2005.

   [<a id="ref-RFC4208">RFC4208</a>]      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", <a href="./rfc4208">RFC 4208</a>, October 2005.

   [<a id="ref-RFC4860">RFC4860</a>]      Le Faucheur, F., Davie, B., Bose, P., Christou, C.,
                  and M. Davenport, "Generic Aggregate Resource
                  ReSerVation Protocol (RSVP) Reservations", <a href="./rfc4860">RFC 4860</a>,
                  May 2007.

   [<a id="ref-RFC4923">RFC4923</a>]      Baker, F. and P. Bose, "Quality of Service (QoS)
                  Signaling in a Nested Virtual Private Network",
                  <a href="./rfc4923">RFC 4923</a>, August 2007.

   [<a id="ref-RFC5824">RFC5824</a>]      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", <a href="./rfc5824">RFC 5824</a>, April 2010.

   [<a id="ref-RFC5971">RFC5971</a>]      Schulzrinne, H. and R. Hancock, "GIST: General
                  Internet Signalling Transport", <a href="./rfc5971">RFC 5971</a>,
                  October 2010.

   [<a id="ref-RFC5974">RFC5974</a>]      Manner, J., Karagiannis, G., and A. McDonald, "NSIS
                  Signaling Layer Protocol (NSLP) for Quality-of-Service
                  Signaling", <a href="./rfc5974">RFC 5974</a>, October 2010.

   [<a id="ref-RSVP-KEYING">RSVP-KEYING</a>]  Behringer, M., Faucheur, F., and B. Weis,
                  "Applicability of Keying Methods for RSVP Security",
                  Work in Progress, September 2010.






<span class="grey">Davie, et al.                Standards Track                   [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc6016">RFC 6016</a>                     RSVP for L3VPNs                October 2010</span>


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]
</pre>