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

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