idnits 2.17.1 draft-ietf-tsvwg-rsvp-l3vpn-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 16, 2010) is 5056 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1349, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-intarea-router-alert-considerations-00 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-ip-options-04 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-05 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Davie 3 Internet-Draft F. le Faucheur 4 Intended status: Standards Track A. Narayanan 5 Expires: December 18, 2010 Cisco Systems, Inc. 6 June 16, 2010 8 Support for RSVP in Layer 3 VPNs 9 draft-ietf-tsvwg-rsvp-l3vpn-07.txt 11 Abstract 13 RFC 4364 and RFC 4659 define an approach to building provider- 14 provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to 15 use RSVP to perform admission control on the links between Customer 16 Edge (CE) routers and Provider Edge (PE) routers. This document 17 specifies procedures by which RSVP messages travelling from CE to CE 18 across an L3VPN may be appropriately handled by PE routers so that 19 admission control can be performed on PE-CE links. Optionally, 20 admission control across the provider's backbone may also be 21 supported. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 18, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 77 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 78 2.1. Model of Operation . . . . . . . . . . . . . . . . . . . . 7 79 3. Admission Control on PE-CE Links . . . . . . . . . . . . . . . 9 80 3.1. New Objects of Type VPN-IPv4 . . . . . . . . . . . . . . . 9 81 3.2. Path Message Processing at Ingress PE . . . . . . . . . . 11 82 3.3. Path Message Processing at Egress PE . . . . . . . . . . . 12 83 3.4. Resv Processing at Egress PE . . . . . . . . . . . . . . . 12 84 3.5. Resv Processing at Ingress PE . . . . . . . . . . . . . . 13 85 3.6. Other RSVP Messages . . . . . . . . . . . . . . . . . . . 13 86 4. Admission Control in Provider's Backbone . . . . . . . . . . . 14 87 5. Inter-AS operation . . . . . . . . . . . . . . . . . . . . . . 15 88 5.1. Inter-AS Option A . . . . . . . . . . . . . . . . . . . . 15 89 5.2. Inter-AS Option B . . . . . . . . . . . . . . . . . . . . 15 90 5.2.1. Admission control on ASBR . . . . . . . . . . . . . . 15 91 5.2.2. No admission control on ASBR . . . . . . . . . . . . . 16 92 5.3. Inter-AS Option C . . . . . . . . . . . . . . . . . . . . 17 93 6. Operation with RSVP disabled . . . . . . . . . . . . . . . . . 17 94 7. Other RSVP procedures . . . . . . . . . . . . . . . . . . . . 17 95 7.1. Refresh overhead reduction . . . . . . . . . . . . . . . . 18 96 7.2. Cryptographic Authentication . . . . . . . . . . . . . . . 18 97 7.3. RSVP Aggregation . . . . . . . . . . . . . . . . . . . . . 18 98 7.4. Support for CE-CE RSVP-TE . . . . . . . . . . . . . . . . 19 99 8. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 19 100 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . . . . . . 19 101 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects . . . . . . 21 102 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects . . . . . . . . 22 103 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects . . . . . . . . . . 22 104 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . 24 105 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 106 SENDER_TEMPLATE objects . . . . . . . . . . . . . . . . . 26 107 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC 108 objects . . . . . . . . . . . . . . . . . . . . . . . . . 27 109 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 110 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 111 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 112 Appendix A. Alternatives Considered . . . . . . . . . . . . . . 34 113 Appendix A.1. GMPLS UNI approach . . . . . . . . . . . . . . . . . 34 114 Appendix A.2. Label switching approach . . . . . . . . . . . . . . 34 115 Appendix A.3. VRF label approach . . . . . . . . . . . . . . . . . 35 116 Appendix A.4. VRF label plus VRF address approach . . . . . . . . 35 117 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 118 12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 119 12.2. Informative References . . . . . . . . . . . . . . . . . . 36 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 122 1. Introduction 124 [RFC4364] and [RFC4659] define a Layer 3 VPN service known as BGP/ 125 MPLS VPNs for IPv4 and for IPv6 respectively. [RFC2205] defines the 126 Resource Reservation Protocol (RSVP) which may be used to perform 127 admission control as part of the Integrated Services (Int-Serv) 128 architecture [RFC1633][RFC2210]. 130 Customers of a layer 3 VPN service may run RSVP for the purposes of 131 admission control (and associated resource reservation) in their own 132 networks. Since the links between Provider Edge (PE) and Customer 133 Edge (CE) routers in a layer 3 VPN may often be resource constrained, 134 it may be desirable to be able to perform admission control over 135 those links. In order to perform admission control using RSVP in 136 such an environment, it is necessary that RSVP control messages, such 137 as Path messages and Resv messages, are appropriately handled by the 138 PE routers. This presents a number of challenges in the context of 139 BGP/MPLS VPNs: 141 o RSVP Path message processing depends on routers recognizing the 142 router alert option ([RFC2113], [RFC2711]) in the IP header. 143 However, packets traversing the backbone of a BGP/MPLS VPN are 144 MPLS encapsulated and thus the router alert option may not be 145 visible to the egress PE due to implementation or policy 146 considerations (e.g. if the egress PE processes the message as 147 "pop and go" without examining the IP header). 149 o BGP/MPLS VPNs support non-unique addressing of customer networks. 150 Thus a PE at the ingress or egress of the provider backbone may be 151 called upon to process Path messages from different customer VPNs 152 with non-unique destination addresses within the RSVP message. 153 Current mechanisms for identifying customer context from data 154 packets are incompatible with RSVP message processing rules. 156 o A PE at the ingress of the provider's backbone may receive Resv 157 messages corresponding to different customer VPNs from other PEs, 158 and needs to be able to associate those Resv messages with the 159 appropriate customer VPNs. 161 Further discussion of these issues is presented in Section 2. 163 This document describes a set of procedures to overcome these 164 challenges and thus to enable admission control using RSVP over the 165 PE-CE links. We note that similar techniques may be applicable to 166 other protocols used for admission control such as the combination of 167 the NSIS Signaling Layer Protocol (NSLP) for QoS Signaling 168 ([I-D.ietf-nsis-qos-nslp]) and General Internet Signaling Transport 169 (GIST) protocol ([I-D.ietf-nsis-ntlp]). 171 Additionally, it may be desirable to perform admission control over 172 the provider's backbone on behalf of one or more L3VPN customers. 173 Core (P) routers in a BGP/MPLS VPN do not have forwarding entries for 174 customer routes, and thus cannot natively process RSVP messages for 175 customer flows. Also the core is a shared resource that carries 176 traffic for many customers, so issues of resource allocation among 177 customers and trust (or lack thereof) also ought to be addressed. 178 This document specifies procedures for supporting such a scenario. 180 This document deals with establishing reservations for unicast flows 181 only. Because the support of multicast traffic in BGP/MPLS VPNs is 182 still evolving, and raises additional challenges for admission 183 control, we leave the support of multicast flows for further study at 184 this point. 186 1.1. Terminology 188 This document draws freely on the terminology defined in [RFC2205] 189 and [RFC4364]. For convenience, we provide a few brief definitions 190 here: 192 o CE (Customer Edge) Router: Router at the edge of a customer site 193 that attaches to the network of the VPN provider. 195 o PE (Provider Edge) Router: Router at the edge of the service 196 provider's network that attaches to one or more customer sites. 198 o VPN Label: An MPLS label associated with a route to a customer 199 prefix in a VPN (also called a VPN route label). 201 o VRF: VPN Routing and Forwarding Table. A PE typically has 202 multiple VRFs, enabling it to be connected to CEs that are in 203 different VPNs. 205 2. Problem Statement 207 The problem space of this document is the support of admission 208 control between customer sites when the customer subscribes to a BGP/ 209 MPLS VPN. We subdivide the problem into (a) the problem of admission 210 control on the PE-CE links (in both directions), and (b) the problem 211 of admission control across the provider's backbone. 213 RSVP Path messages are normally addressed to the destination of a 214 session, and contain the Router Alert Option (RAO) within the IP 215 header. Routers along the path to the destination that are 216 configured to process RSVP messages need to detect the presence of 217 the RAO to allow them to intercept Path messages. However, the 218 egress PEs of a network supporting BGP/MPLS VPNs receive packets 219 destined for customer sites as MPLS-encapsulated packets, and 220 possibly forwards those based only on examination of the MPLS label. 221 In order to process RSVP Path messages, the egress VPN PE would have 222 to pop the VPN label and examine the IP header underneath, before 223 forwarding the packet (based on the VPN label disposition rules), 224 which is not a requirement for data packet processing today. Hence, 225 a Path message would be forwarded without examination of the IP 226 options and would therefore not receive appropriate processing at the 227 PE. Another potential issue is doing CAC at an ASBR. Even an 228 implementation that examines the IP header when removing the VPN 229 label (e.g. PE-CE link) would not be able to do CAC at an Option-B 230 ASBR; that requires examining the (interior) IP header while doing a 231 label swap, which is much less desirable behaviour. 233 In general, there are significant issues with requiring support for 234 IP Router-Alert outside of a controlled, "walled-garden" network, as 235 described in [I-D.ietf-intarea-router-alert-considerations]. The 236 case of a MPLS L3VPN falls under the "Overlay Model" described 237 therein. Fundamental to this model is that providers would seek to 238 eliminate the requirement to process IP-RAO marked packets from 239 customers, on any routers except the PEs facing those customers. 240 Issues with requiring interior MPLS routers to process IP Router- 241 Alert marked packets are also described in 242 [I-D.ietf-mpls-ip-options]. The approach for RSVP packet handling 243 described in this document has the advantage of being independent of 244 any data-plane requirements such as IP Router-Alert support within 245 the VPN, or examining any IP options for MPLS-encapsulated packets. 246 The only requirement for processing IP Router-Alert packets is for 247 RSVP packets received from the CE, which do not carry any MPLS 248 encapsulation. 250 For the PE-CE link subproblem, the most basic challenge is that RSVP 251 control messages contain IP addresses that are drawn from the 252 customer's address space, and PEs need to deal with traffic from many 253 customers who may have non-unique (or overlapping) address spaces. 254 Thus, it is essential that a PE be able in all cases to identify the 255 correct VPN context in which to process an RSVP control message. The 256 current mechanism for identifying the customer context is the VPN 257 Label, which is carried in a MPLS header outside of the RSVP message. 258 This is divergent from the general RSVP model of session 259 identification ([RFC2205], [RFC2209]), which relies solely on RSVP 260 objects to identify sessions. Further, it is incompatible with 261 protocols like COPS/RSVP ([RFC2748], [RFC2749]), which replace the IP 262 encapsulation of the RSVP message and send only RSVP objects to a 263 COPS server. We believe it is important to retain the model of 264 completely identifying an RSVP session from the contents of RSVP 265 objects. Much of this document deals with this issue. 267 For the case of making reservations across the provider backbone, we 268 observe that BGP/MPLS VPNs do not create any per-customer forwarding 269 state in the P (provider core) routers. Thus, in order to make 270 reservations on behalf of customer-specified flows, it is clearly 271 necessary to make some sort of aggregated reservation from PE-PE and 272 then map individual, customer-specific reservations onto an aggregate 273 reservation. That is similar to the problem tackled in [RFC3175] and 274 [RFC4804], with the additional complications of handling customer- 275 specific addressing associated with BGP/MPLS VPNs. 277 Consider the case where an MPLS VPN customer uses RSVP signaling 278 across his sites for resource reservation and admission control. 279 Let's further assume that, initially, RSVP is not processed through 280 the MPLS VPN cloud (i.e RSVP messages from the sender to the receiver 281 travel transparently from CE to CE). In that case, RSVP allows 282 establishment of resource reservations and admission control on a 283 subset of the flow path (from sender to ingress CE; and from the RSVP 284 router downstream of the egress CE to the receiver). If admission 285 control is then activated on any of the CE-PE link, provider's 286 backbone or PE-CE link (as allowed by the present document), the 287 customer will benefit from an extended coverage of admission control 288 and resource reservation: the resource reservation will now span over 289 a bigger subset of (and possibly the whole) flow path, which in turn 290 will increase the quality of service granted to the corresponding 291 flow. Specific flows whose reservation is successful through 292 admission control on the newly enabled segments will indeed benefit 293 from this quality of service enhancement. However, it must be noted 294 that, in case there is not enough resources on one (or more) of the 295 newly enabled segments (e.g. Say admission control is enabled on a 296 given PE-->CE link and there is not enough capacity on that link to 297 admit all reservations for all the flows traversing that link) then 298 some flows will not be able to maintain, or establish, their 299 reservation. While this may appear undesirable for these flows, we 300 observe that this only occurs if there is indeed a lack of capacity 301 on a segment, and that in the absence of admission control all flows 302 would be established but would all suffer from the resulting 303 congestion on the bottleneck segment. We also observe that, in case 304 of such lack of capacity, admission control allows enforcement of 305 controlled and flexible policies (so that, for example, more 306 important flows can be granted higher priority at reserving 307 resources). We note also that flows are given a chance to establish 308 smaller reservations so that the aggregate load can adapt dynamically 309 to the bottleneck capacity. 311 2.1. Model of Operation 313 Figure 1 illustrates the basic model of operation with which this 314 document is concerned. 316 -------------------------- 317 / Provider \ 318 |----| | Backbone | |----| 319 Sender->| CE1| |-----| |-----| |CE2 |->Receiver 320 | |--| | |---| |---| | |---| | 321 |----| | | | P | | P | | | |----| 322 | PE1 |---| |-----| |-----| PE2 | 323 | | | | | | | | 324 | | |---| |---| | | 325 |-----| |-----| 326 | | 327 \ / 328 -------------------------- 330 Figure 1. Model of Operation for RSVP-based admission control over 331 MPLS/BGP VPN 333 To establish a unidirectional reservation for a point-to-point flow 334 from Sender to Receiver that takes account of resource availability 335 on the CE-PE and PE-CE links only, the following steps need to take 336 place: 338 1. Sender sends a Path message to an IP address of the Receiver. 340 2. Path message is processed by CE1 using normal RSVP procedures 341 and forwarded towards the Receiver along the link CE1-PE1. 343 3. PE1 processes Path message and forwards towards the Receiver 344 across the provider backbone. 346 4. PE2 processes Path message and forwards towards the Receiver 347 along link PE2-CE2. 349 5. CE2 processes Path message using normal RSVP procedures and 350 forwards towards Receiver. 352 6. Receiver sends Resv message to CE2. 354 7. CE2 sends Resv message to PE2. 356 8. PE2 processes Resv message (including performing admission 357 control on link PE2-CE2) and sends Resv to PE1. 359 9. PE1 processes Resv message and sends Resv to CE1. 361 10. CE1 processes Resv using normal RSVP procedures, performs 362 admission control on the link CE1-PE1 and sends Resv message to 363 Sender if successful. 365 In each of the steps involving Resv messages (6 through 10) the node 366 sending the Resv uses the previously established Path state to 367 determine the "RSVP Previous Hop (PHOP)" and sends a Resv message to 368 that address. We note that establishing that Path state correctly at 369 PEs is one of the challenges posed by the BGP/MPLS environment. 371 3. Admission Control on PE-CE Links 373 In the following sections we trace through the steps outlined in 374 Section 2.1 and expand on the details for those steps where standard 375 RSVP procedures need to be extended or modified to support the BGP/ 376 MPLS VPN environment. For all the remaining steps described in the 377 preceding section, standard RSVP processing rules apply. 379 All the procedures described below support both IPv4 and IPv6 380 addressing. In all cases where IPv4 is referenced, IPv6 can be 381 substituted with identical procedures and results. Object 382 definitions for both IPv4 and IPv6 are provided in Section 8. 384 3.1. New Objects of Type VPN-IPv4 386 For RSVP signaling within a VPN, certain RSVP objects need to be 387 extended. Since customer IP addresses need not be unique, the 388 current types of SESSION, SENDER_TEMPLATE and FILTERSPEC objects are 389 no longer sufficient to globally identify RSVP states in P/PE 390 routers, since those are currently based on IP addresses. We propose 391 new types of SESSION, SENDER_TEMPLATE and FILTERSPEC objects, which 392 contain globally unique VPN-IPv4 format addresses. The ingress and 393 egress PE nodes translate between the regular IPv4 addresses for 394 messages to and from the CE, and VPN-IPv4 addresses for messages to 395 and from PE routers. The rules for this translation are described in 396 later sections. 398 The RSVP_HOP object in a RSVP message currently specifies an IP 399 address to be used by the neighboring RSVP hop to reply to the 400 message sender. However, MPLS VPN PE routers (especially those 401 separated by Option-B Autonomous System Border Routers -ASBRs) are 402 not required to have direct IP reachability to each other. To solve 403 this issue, we propose the use of label switching to forward RSVP 404 messages between nodes within a MPLS VPN. This is achieved by 405 defining a new VPN-IPv4 RSVP_HOP object. Use of the VPN-IPv4 406 RSVP_HOP object enables any two adjacent RSVP hops in a MPLS VPN 407 (e.g. a PE in AS 1 and a PE in AS2) to correctly identify each other 408 and send RSVP messages directly to each other. 410 The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message 411 sender and a Logical Interface Handle (LIH) as before, but in 412 addition carries a VPN-IPv4 address which also represents the sender 413 of the message. The message sender MUST also advertise this VPN-IPv4 414 address into BGP, associated with a locally allocated label, and this 415 advertisement MUST be propagated by BGP throughout the VPN and to 416 adjacent ASes if required to provide reachability to this PE. Frames 417 received by the PE marked with this label MUST be given to the local 418 control plane for processing. When a neighboring RSVP hop wishes to 419 reply to a message carrying a VPN-IPv4 RSVP_HOP, it looks for a BGP 420 advertisement of the VPN-IPv4 address contained in that RSVP_HOP. If 421 this address is found and carries an associated label, the 422 neighboring RSVP node MUST encapsulate the RSVP message with this 423 label and send it via MPLS encapsulation to the BGP next-hop 424 associated with the route. The destination IP address of the message 425 is taken from the IP address field of the RSVP_HOP object, as 426 described in [RFC2205]. Additionally, the IPv4 address in the 427 RSVP_HOP object continues to be used for all other existing purposes, 428 including neighbor matching between Path/Resv and SRefresh messages 429 ([RFC2961]), authentication ([RFC2747]), etc. 431 The VPN-IPv4 address used in the VPN-IPv4 RSVP_HOP object MAY 432 represent an existing address in the VRF that corresponds to the flow 433 (e.g. a local loopback or PE-CE link address within the VRF for this 434 customer), or MAY be created specially for this purpose. In the case 435 where the address is specially created for RSVP signaling (and 436 possibly other control protocols), the BGP advertisement MUST NOT be 437 redistributed to, or reachable by, any CEs outside the MPLS VPN. One 438 way to achieve this is by creating a special "control protocols VPN" 439 with VRF state on every PE/ASBR, carrying route targets not imported 440 into customer VRFs. In the case where a customer VRF address is used 441 as the VPN-IPv4 address, a VPN-IPv4 address in one customer VRF MUST 442 NOT be used to signal RSVP messages for a flow in a different VRF. 444 If a PE/ASBR is sending a Path message to another PE/ASBR within the 445 VPN, and it has any appropriate VPN-IPv4 address for signaling that 446 satisfies the requirements outlined above, it MUST use a VPN-IPv4 447 RSVP_HOP object with this address for all RSVP messages within the 448 VPN. If a PE/ASBR does not have any appropriate VPN-IPv4 address to 449 use for signaling, it MAY send the Path message with a regular IPv4 450 RSVP_HOP object. In this case, the reply will be IP encapsulated. 451 This option is not preferred because there is no guarantee that the 452 neighboring RSVP hop has IP reachability to the sending node. If a 453 PE/ASBR receives or originates a Path message with a VPN-IPv4 454 RSVP_HOP object, any RSVP_HOP object in corresponding upstream 455 messages for this flow (e.g. Resv, ResvTear) or downstream messages 456 (e.g. ResvError, PathTear) sent by this node within the VPN MUST be 457 a VPN-IPv4 RSVP_HOP. 459 3.2. Path Message Processing at Ingress PE 461 When a Path message arrives at the ingress PE (step 3 of Section 2.1) 462 the PE needs to establish suitable Path state and forward the Path 463 message on to the egress PE. In the following paragraphs we 464 described the steps taken by the ingress PE. 466 The Path message is addressed to the eventual destination (the 467 receiver at the remote customer site) and carries the IP router alert 468 option, in accordance with [RFC2205]. The ingress PE MUST recognize 469 the router alert option, intercept these messages and process them as 470 RSVP signaling messages. 472 As noted above, there is an issue in recognizing Path messages as 473 they arrive at the egress PE (PE 2 in Figure 1). The approach 474 defined here is to address the Path messages sent by the ingress PE 475 directly to the egress PE, and send it without IP router alert 476 option; that is, rather than using the ultimate receiver's 477 destination address as the destination address of the Path message, 478 we use the loopback address of the egress PE as the destination 479 address of the Path message. This approach has the advantage that it 480 does not require any new data plane capabilities for the egress PE 481 beyond those of a standard BGP/MPLS VPN PE. Details of the 482 processing of this message at the egress PE are described below in 483 Section 3.3. The approach of addressing a Path message directly to 484 an RSVP next hop (that may or may not be the next IP hop) is already 485 used in other environments such as those of [RFC4206] and [RFC4804]. 487 The details of operation at the ingress PE are as follows. When the 488 ingress PE (PE1 in Figure 1) receives a Path message from CE1 that is 489 addressed to the receiver, the VRF that is associated with the 490 incoming interface is identified, just as for normal data path 491 operations. The Path state for the session is stored, and is 492 associated with that VRF, so that potentially overlapping addresses 493 among different VPNs do not appear to belong to the same session. 494 The destination address of the receiver is looked up in the 495 appropriate VRF, and the BGP Next-Hop for that destination is 496 identified. That next-hop is the egress PE (PE2 in Figure 1). A new 497 VPN-IPv4 SESSION object is constructed, containing the Route 498 Distinguisher (RD) that is part of the VPN-IPv4 route prefix for this 499 destination, and the IPv4 address from the SESSION. In addition, a 500 new VPN-IPv4 SENDER_TEMPLATE object is constructed, with the original 501 IPv4 address from the incoming SENDER_TEMPLATE plus the RD that is 502 used by this PE to advertise that prefix for this customer into the 503 VPN. A new Path message is constructed with a destination address 504 equal to the address of the egress PE identified above. This new 505 Path message will contain all the objects from the original Path 506 message, replacing the original SESSION and SENDER_TEMPLATE objects 507 with the new VPN-IPv4 type objects. The Path message is sent without 508 router alert option and contains a RSVP_HOP object constructed as 509 specified in Section 3.1. 511 3.3. Path Message Processing at Egress PE 513 When a Path message arrives at the egress PE, (step 4 of Section 2.1) 514 it is addressed to the PE itself, and is handed to RSVP for 515 processing. The router extracts the RD and IPv4 address from the 516 VPN-IPv4 SESSION object, and determines the local VRF context by 517 finding a matching VPN-IPv4 prefix with the specified RD that has 518 been advertised by this router into BGP. The entire incoming RSVP 519 message, including the VRF information, is stored as part of the Path 520 state. 522 Now the RSVP module can construct a Path message which differs from 523 the Path it received in the following ways: 525 a. Its destination address is the IP address extracted from the 526 SESSION Object; 528 b. The SESSION and SENDER_TEMPLATE objects are converted back to 529 IPv4-type by discarding the attached RD 531 c. The RSVP_HOP Object contains the IP address of the outgoing 532 interface of the egress PE and a Logical Interface Handle (LIH), 533 as per normal RSVP processing. 535 The router then sends the Path message on towards its destination 536 over the interface identified above. This Path message carries the 537 router alert option as required by [RFC2205]. 539 3.4. Resv Processing at Egress PE 541 When a receiver at the customer site originates a Resv message for 542 the session, normal RSVP procedures apply until the Resv, making its 543 way back towards the sender, arrives at the "egress" PE (step 8 of 544 Section 2.1). Note that this is the "egress" PE with respect to the 545 direction of data flow, i.e. PE2 in figure 1. On arriving at PE2, 546 the SESSION and FILTER_SPEC objects in the Resv, and the VRF in which 547 the Resv was received, are used to find the matching Path state 548 stored previously. At this stage, admission control can be performed 549 on the PE-CE link. 551 Assuming admission control is successful, the PE constructs a Resv 552 message to send to the RSVP HOP stored in the Path state, i.e., the 553 ingress PE (PE1 in Figure 1). The IPv4 SESSION object is replaced 554 with the same VPN-IPv4 SESSION object received in the Path. The IPv4 555 FILTER_SPEC object is replaced with a VPN-IPv4 FILTER_SPEC object, 556 which copies the VPN-IPv4 address from the SENDER_TEMPLATE received 557 in the matching Path message. The RSVP_HOP in the Resv message MUST 558 be constructed as specified in Section 3.1. The Resv message MUST be 559 addressed to the IP address contained within the RSVP_HOP object in 560 the Path message. If the Path message contained a VPN-IPv4 RSVP_HOP 561 object, the Resv MUST be MPLS-encapsulated using the label associated 562 with that VPN-IPv4 address in BGP, as described in Section 3.1. If 563 the Path message contained an IPv4 RSVP_HOP object, the Resv is 564 simply IP-encapsulated and addressed directly to the IP address in 565 the RSVP_HOP object. 567 If admission control is not successful on the egress PE, a ResvError 568 message is sent towards the receiver as per normal RSVP processing. 570 3.5. Resv Processing at Ingress PE 572 Upon receiving a Resv message at the ingress PE (step 8 of 573 Section 2.1) with respect to data flow (i.e. PE1 in Figure 1), the 574 PE determines the local VRF context and associated Path state for 575 this Resv by decoding the received SESSION and FILTER_SPEC objects. 576 It is now possible to generate a Resv message to send to the 577 appropriate CE. The Resv message sent to the ingress CE will contain 578 IPv4 SESSION and FILTER_SPEC objects, derived from the appropriate 579 Path state. Since we assume in this section that admission control 580 over the Provider's backbone is not needed, the ingress PE does not 581 perform any admission control for this reservation. 583 3.6. Other RSVP Messages 585 Processing of PathError, PathTear, ResvError, ResvTear and ResvConf 586 messages is generally straightforward and follows the rules of 587 [RFC2205]. These additional rules MUST be observed for messages 588 transmitted within the VPN (i.e. Between the PEs): 590 o The SESSION, SENDER_TEMPLATE and FILTER_SPEC objects MUST be 591 converted from IPv4 to VPN-IPv4 form and back in the same manner 592 as described above for Path and Resv messages. 594 o The appropriate type of RSVP_HOP object (VPN-IPv4 or IPv4) MUST be 595 used as described above. 597 o Depending on the type of RSVP_HOP object received from the 598 neighbor, the message MUST be MPLS-encapsulated or IP-encapsulated 599 as described above. 601 o The matching state & VRF MUST be determined by decoding the RD and 602 IPv4 addresses in the SESSION and FILTER_SPEC objects. 604 o The message MUST be directly addressed to the appropriate PE, 605 without using the router alert option. 607 4. Admission Control in Provider's Backbone 609 The preceding section outlines how per-customer reservations can be 610 made over the PE-CE links. This may be sufficient in many situations 611 where the backbone is well engineered with ample capacity and there 612 is no need to perform any sort of admission control in the backbone. 613 However, in some cases where excess capacity cannot be relied upon 614 (e.g., during failures or unanticipated periods of overload) it may 615 be desirable to be able to perform admission control in the backbone 616 on behalf of customer traffic. 618 Because of the fact that routes to customer addresses are not present 619 in the P routers, along with the concerns of scalability that would 620 arise if per-customer reservations were allowed in the P routers, it 621 is clearly necessary to map the per-customer reservations described 622 in the preceding section onto some sort of aggregate reservations. 623 Furthermore, customer data packets need to be tunneled across the 624 provider backbone just as in normal BGP/MPLS VPN operation. 626 Given these considerations, a feasible way to achieve the objective 627 of admission control in the backbone is to use the ideas described in 628 [RFC4804]. MPLS-TE tunnels can be established between PEs as a means 629 to perform aggregate admission control in the backbone. 631 An MPLS-TE tunnel from an ingress PE to an egress PE can be thought 632 of as a virtual link of a certain capacity. The main change to the 633 procedures described above is that when a Resv is received at the 634 ingress PE, an admission control decision can be performed by 635 checking whether sufficient capacity of that virtual link remains 636 available to admit the new customer reservation. We note also that 637 [RFC4804] uses the IF_ID RSVP_HOP object to identify the tunnel 638 across the backbone, rather than the simple RSVP_HOP object described 639 in Section 3.2. The procedures of [RFC4804] should be followed here 640 as well. 642 To achieve effective admission control in the backbone, there needs 643 to be some way to separate the data plane traffic that has a 644 reservation from that which does not. We assume that packets that 645 are subject to admission control on the core will be given a 646 particular MPLS EXP value, and that no other packets will be allowed 647 to enter the core with this value unless they have passed admission 648 control. Some fraction of link resources will be allocated to queues 649 on core links for packets bearing that EXP value, and the MPLS-TE 650 tunnels will use that resource pool to make their constraint-based 651 routing and admission control decisions. This is all consistent with 652 the principles of aggregate RSVP reservations described in [RFC3175]. 654 5. Inter-AS operation 656 [RFC4364] defines three modes of inter-AS operation for MPLS/BGP 657 VPNs, referred to as options A, B and C. In the following sections we 658 describe how the scheme described above can operate in each inter-AS 659 environment. 661 5.1. Inter-AS Option A 663 Operation of RSVP in Inter-AS Option A is quite straightforward. 664 Each ASBR operates like a PE, and the ASBR-ASBR links can be viewed 665 as PE-CE links in terms of admission control. If the procedures 666 defined in Section 3 are enabled on both ASBRs, then admission 667 control may be performed on the inter-ASBR links. In addition, the 668 operator of each AS can independently decide whether or not to 669 perform admission control across his backbone. The new objects 670 described in this document MUST NOT be sent in any RSVP message 671 between two Option-A ASBRs. 673 5.2. Inter-AS Option B 675 To support inter-AS Option B, we require some additional processing 676 of RSVP messages on the ASBRs. Recall that, when packets are 677 forwarded from one AS to another in option B, the VPN label is 678 swapped by each ASBR as a packet goes from one AS to another. The 679 BGP next hop seen by the ingress PE will be the ASBR, and there need 680 not be IP visibility between the ingress and egress PEs. Hence when 681 the ingress PE sends the Path message to the BGP next hop of the VPN- 682 IPv4 route towards the destination, it will be received by the ASBR. 683 The ASBR determines the next hop of the route in a similar way as the 684 ingress PE - by finding a matching BGP VPN-IPv4 route with the same 685 RD and a matching prefix. 687 The provider(s) who interconnect ASes using option B may or may not 688 desire to perform admission control on the inter-AS links. This 689 choice affects the detailed operation of ASBRs. We describe the two 690 modes of operation - with and without admission control at the ASBRs 691 - in the following sections. 693 5.2.1. Admission control on ASBR 695 In this scenario, the ASBR performs full RSVP signaling and admission 696 control. The RSVP database is indexed on the ASBR using the VPN-IPv4 697 SESSION, SENDER_TEMPLATE and FILTER_SPEC objects (which uniquely 698 identify RSVP sessions and flows as per the requirements of 699 [RFC2205]). These objects are forwarded unmodified in both 700 directions by the ASBR. All other procedures of RSVP are performed 701 as if the ASBR was a RSVP hop. In particular, the RSVP_HOP objects 702 sent in Path and Resv messages contain IP addresses of the ASBR, 703 which MUST be reachable by the neighbor to whom the message is being 704 sent. Note that since the VPN-IPv4 SESSION, SENDER_TEMPLATE and 705 FILTER_SPEC objects satisfy the uniqueness properties required for a 706 RSVP database implementation as per [RFC2209], no customer VRF 707 awareness is required on the ASBR. 709 5.2.2. No admission control on ASBR 711 If the ASBR is not doing admission control, it is desirable that per- 712 flow state not be maintained on the ASBR. This requires adjacent 713 RSVP hops (i.e. The ingress and egress PEs of the respective ASes) 714 to send RSVP messages directly between them. This is only possible 715 if they are MPLS-encapsulated. The use of the VPN-IPv4 RSVP_HOP 716 object described in Section 3.1 is REQUIRED in this case. 718 When an ASBR that is not installing local RSVP state receives a Path 719 message, it looks up the next-hop of the matching BGP route as 720 described in Section 3.2, and sends the Path message to the next-hop, 721 without modifying any RSVP objects (including the RSVP_HOP). This 722 process is repeated at subsequent ASBRs until the Path message 723 arrives at a router that is installing local RSVP state (either the 724 ultimate egress PE, or an ASBR configured to perform admission 725 control). This router receives the Path and processes it as 726 described in Section 3.3 if it is a PE, or Section 5.2.1 if it is an 727 ASBR performing admission control. When this router sends the Resv 728 upstream, it looks up the routing table for a next-hop+label for the 729 VPN-IPv4 address in the PHOP, encapsulates the Resv with that label 730 and sends it upstream. This message will be received for control 731 processing directly on the upstream RSVP hop (that last updated the 732 RSVP_HOP field in the Path message), without any involvement of 733 intermediate ASBRs. 735 The ASBR is not expected to process any other RSVP messages apart 736 from the Path message as described above. The ASBR also does not 737 need to store any RSVP state. Note that any ASBR along the path that 738 wishes to do admission control or insert itself into the RSVP 739 signaling flow, may do so by writing its own RSVP_HOP object with 740 IPv4 and VPN-IPv4 address pointing to itself. 742 If an Option-B ASBR receives a RSVP Path message with an IPv4 743 RSVP_HOP, does not wish to perform admission control but is willing 744 to install local state for this flow, the ASBR MUST process and 745 forward RSVP signaling messages for this flow as described in 746 Section 5.2.1 (with the exception that it does not perform admission 747 control). If an Option-B ASBR receives a RSVP Path message with an 748 IPv4 RSVP_HOP, but does not wish to install local state or perform 749 admission control for this flow, the ASBR MUST NOT forward the Path 750 message. In addition, the ASBR SHOULD send a PathError message of 751 Error Code "RSVP over MPLS Problem" and Error Value "RSVP_HOP not 752 reachable across VPN" (see Section 9) signifying to the upstream RSVP 753 hop that the supplied RSVP_HOP object is insufficient to provide 754 reachability across this VPN. This failure condition is not expected 755 to be recoverable. 757 5.3. Inter-AS Option C 759 Operation of RSVP in Inter-AS Option C is also quite straightforward, 760 because there exists an LSP directly from ingress PE to egress PE. 761 In this case, there is no significant difference in operation from 762 the single AS case described in Section 3. Furthermore, if it is 763 desired to provide admission control from PE to PE, it can be done by 764 building an inter-AS TE tunnel and then using the procedures 765 described in Section 4. 767 6. Operation with RSVP disabled 769 It is often the case that RSVP will not be enabled on the PE-CE 770 links. In such an environment, a customer may reasonably expect that 771 RSVP messages sent into the L3 VPN network should be forwarded just 772 like any other IP datagrams. This transparency is useful when the 773 customer wishes to use RSVP within his own sites or perhaps to 774 perform admission control on the CE-PE links (in CE->PE direction 775 only), without involvement of the PEs. For this reason, a PE SHOULD 776 NOT discard or modify RSVP messages sent towards it from a CE when 777 RSVP is not enabled on the PE-CE links. Similarly a PE SHOULD NOT 778 discard or modify RSVP messages which are destined for one of its 779 attached CEs, even when RSVP is not enabled on those links. Note 780 that the presence of the router alert option in some RSVP messages 781 may cause them to be forwarded outside of the normal forwarding path, 782 but that the guidance of this paragraph still applies in that case. 783 Note also that this guidance applies regardless of whether RSVP-TE is 784 used in some, all, or none of the L3VPN network. 786 7. Other RSVP procedures 788 This section describes modifications to other RSVP procedures 789 introduced by MPLS VPNs 791 7.1. Refresh overhead reduction 793 The following points ought to be noted regarding RSVP refresh 794 overhead reduction ([RFC2961]) across a MPLS VPN: 796 o The hop between the ingress and egress PE of a VPN is to be 797 considered as traversing one or more non-RSVP hops. As such, the 798 procedures described in Section 5.3 of [RFC2961] relating to non- 799 RSVP hops SHOULD be followed. 801 o The source IP address of a SRefresh message MUST match the IPv4 802 address signalled in the RSVP_HOP object contained in the 803 corresponding Path or Resv message. The IPv4 address in any 804 received VPN-IPv4 RSVP_HOP object MUST be used as the source 805 address of that message for this purpose. 807 7.2. Cryptographic Authentication 809 The following points ought to be noted regarding RSVP cryptographic 810 authentication ([RFC2747]) across a MPLS VPN: 812 o The IPv4 address in any received VPN-IPv4 RSVP_HOP object MUST be 813 used as the source address of that message for purposes of 814 identifying the security association. 816 o Forwarding of Challenge and Response messages MUST follow the same 817 rules as described above for hop-by-hop messages. Specifically, 818 if the originator of a Challenge/Response message has received a 819 VPN-IPv4 RSVP_HOP object from the corresponding neighbor, it MUST 820 use the label associated with that VPN-IPv4 address in BGP to 821 forward the Challenge/Response message. 823 7.3. RSVP Aggregation 825 [RFC3175] and [RFC4860] describe mechanisms to aggregate multiple 826 individual RSVP reservations into a single larger reservation on the 827 basis of a common DSCP/PHB for traffic classification. The following 828 points ought to be noted in this regard: 830 o The procedures described in this section apply only in the case 831 where the Aggregator and Deaggregator nodes are C/CE devices, and 832 the entire MPLS VPN lies within the Aggregation Region. The case 833 where the PE is also an Aggregator/Deaggregator is more complex 834 and not considered in this document. 836 o Support of Aggregate RSVP sessions is OPTIONAL. When supported: 838 * Aggregate RSVP sessions MUST be treated in the same way as 839 regular IPv4 RSVP sessions. To this end, all the procedures 840 described in Section 3 and Section 4 MUST be followed for 841 aggregate RSVP sessions. The corresponding new SESSION, 842 SENDER_TEMPLATE and FILTERSPEC objects are defined in 843 Section 8. 845 * End-To-End (E2E) RSVP sessions are passed unmodified through 846 the MPLS VPN. These RSVP messages SHOULD be identified by 847 their IP protocol (RSVP-E2E-IGNORE, 134). When the ingress PE 848 receives any RSVP message with this IP protocol, it MUST 849 process this frame as if it is regular customer traffic and 850 ignore any router alert option. The appropriate VPN and 851 transport labels are applied to the frame and it is forwarded 852 towards the remote CE. Note that this message will not be 853 received or processed by any other P or PE node. 855 * Any SESSION-OF-INTEREST object (defined in [RFC4860]) MUST be 856 conveyed unmodified across the MPLS VPN. 858 7.4. Support for CE-CE RSVP-TE 860 [I-D.ietf-l3vpn-e2e-rsvp-te-reqts] describes a set of requirements 861 for the establishment for CE-CE MPLS LSPs across networks offering an 862 L3VPN service. The requirements specified in that document are 863 similar to those addressed by this document, in that both address the 864 issue of handling RSVP requests from customers in a VPN context. It 865 is possible that the solution described here could be adapted to meet 866 the requirements of [I-D.ietf-l3vpn-e2e-rsvp-te-reqts]. To the 867 extent that this document uses signaling extensions described in 868 [RFC3473] which have already been used for GMPLS/TE, we expect that 869 CE-CE RSVP/TE will be incremental work built on these extensions. 870 These extensions will be considered in a separate document. 872 8. Object Definitions 874 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects 876 The usage of the VPN-IPv4 (or VPN-IPv6) SESSION Object is described 877 in Section 3.2 to Section 3.6. The VPN-IPv4 (or VPN-IPv6) SESSION 878 object appears in RSVP messages that ordinarily contain a SESSION 879 object and are sent between ingress PE and egress PE in either 880 direction. The object MUST NOT be included in any RSVP messages that 881 are sent outside of the provider's backbone (except in the inter-AS 882 option B and C cases, as described above, when it may appear on 883 inter-AS links). 885 The VPN-IPv6 SESSION object is analogous to the VPN-IPv4 SESSION 886 object, using an VPN-IPv6 address ([RFC4659]) instead of an VPN-IPv4 887 address ([RFC4364]). 889 The formats of the objects are as follows: 891 o VPN-IPv4 SESSION object: Class = 1, C-Type = TBA 893 +-------------+-------------+-------------+-------------+ 894 | | 895 + + 896 | VPN-IPv4 DestAddress (12 bytes) | 897 + + 898 | | 899 +-------------+-------------+-------------+-------------+ 900 | Protocol Id | Flags | DstPort | 901 +-------------+-------------+-------------+-------------+ 903 o VPN-IPv6 SESSION object: Class = 1, C-Type = TBA 905 +-------------+-------------+-------------+-------------+ 906 | | 907 + + 908 | | 909 + VPN-IPv6 DestAddress (24 bytes) + 910 / / 911 . . 912 / / 913 | | 914 +-------------+-------------+-------------+-------------+ 915 | Protocol Id | Flags | DstPort | 916 +-------------+-------------+-------------+-------------+ 918 The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field 919 contains an address of the VPN-IPv4 (respectively VPN-IPv6) address 920 family encoded as specified in [RFC4364] (respectively [RFC4659]). 921 The content of this field is discussed in Section 3.2 and 922 Section 3.3. 924 The protocol ID, flags, and DstPort are identical to the same fields 925 in the IPv4 and IPv6 SESSION objects ([RFC2205]). 927 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects 929 The usage of the VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE Object is 930 described in Section 3.2 and Section 3.3. The VPN-IPv4 (or VPN-IPv6) 931 SENDER_TEMPLATE object appears in RSVP messages that ordinarily 932 contain a SENDER_TEMPLATE object and are sent between ingress PE and 933 egress PE in either direction (such as Path, PathError, and 934 PathTear). The object MUST NOT be included in any RSVP messages that 935 are sent outside of the provider's backbone (except in the inter-AS 936 option B and C cases, as described above, when it may appear on 937 inter-AS links). The format of the object is as follows: 939 o VPN-IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = TBA 941 +-------------+-------------+-------------+-------------+ 942 | | 943 + + 944 | VPN-IPv4 SrcAddress (12 bytes) | 945 + + 946 | | 947 +-------------+-------------+-------------+-------------+ 948 | Reserved | SrcPort | 949 +-------------+-------------+-------------+-------------+ 951 o VPN-IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = TBA 953 +-------------+-------------+-------------+-------------+ 954 | | 955 + + 956 | | 957 + VPN-IPv6 SrcAddress (24 bytes) + 958 / / 959 . . 960 / / 961 | | 962 +-------------+-------------+-------------+-------------+ 963 | Reserved | SrcPort | 964 +-------------+-------------+-------------+-------------+ 966 The VPN-IPv4 SrcAddress (respectively VPN-IPv6 SrcAddress) field 967 contains an address of the VPN-IPv4 (respectively VPN-IPv6) address 968 family encoded as specified in [RFC4364] (respectively [RFC4659]). 969 The content of this field is discussed in Section 3.2 and 970 Section 3.3. 972 The SrcPort is identical to the SrcPort field in the IPv4 and IPv6 973 SENDER_TEMPLATE objects ([RFC2205]). 975 The Reserved field MUST be set to zero on transmit and ignored on 976 receipt. 978 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects 980 The usage of the VPN-IPv4 (or VPN-IPv6) FILTER_SPEC Object is 981 described in Section 3.4 and Section 3.5. The VPN-IPv4 (or VPN-IPv6) 982 FILTER_SPEC object appears in RSVP messages that ordinarily contain a 983 FILTER_SPEC object and are sent between ingress PE and egress PE in 984 either direction (such as Resv, ResvError, and ResvTear). The object 985 MUST NOT be included in any RSVP messages that are sent outside of 986 the provider's backbone (except in the inter-AS option B and C cases, 987 as described above, when it may appear on inter-AS links). 989 o VPN-IPv4 FILTER_SPEC object: Class = 10, C-Type = TBA 991 Definition same as VPN-IPv4 SENDER_TEMPLATE object. 993 o VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = TBA 995 Definition same as VPN-IPv6 SENDER_TEMPLATE object. 997 The content of the VPN-IPv4 SrcAddress (or VPN-IPv6 SrcAddress) field 998 is discussed in Section 3.4 and Section 3.5. 1000 The SrcPort is identical to the SrcPort field in the IPv4 and IPv6 1001 SENDER_TEMPLATE objects ([RFC2205]). 1003 The Reserved field MUST be set to zero on transmit and ignored on 1004 receipt. 1006 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects 1008 Usage of the VPN-IPv4 (or VPN-IPv6) RSVP_HOP Object is described in 1009 Section 3.1 and Section 5.2.2. The VPN-IPv4 (VPN-IPv6) RSVP_HOP 1010 object is used to establish signaling reachability between RSVP 1011 neighbors separated by one or more Option-B ASBRs. This object may 1012 appear in RSVP messages that carry a RSVP_HOP object, and that travel 1013 between the Ingress and Egress PEs. It MUST NOT be included in any 1014 RSVP messages that are sent outside of the provider's backbone 1015 (except in the inter-AS option B and C cases, as described above, 1016 when it may appear on inter-AS links). The format of the object is 1017 as follows: 1019 o VPN-IPv4 RSVP_HOP object: Class = 3, C-Type = TBA 1021 +-------------+-------------+-------------+-------------+ 1022 | IPv4 Next/Previous Hop Address (4 bytes) | 1023 +-------------+-------------+-------------+-------------+ 1024 | | 1025 + + 1026 | VPN-IPv4 Next/Previous Hop Address (12 bytes) | 1027 + + 1028 | | 1029 +-------------+-------------+-------------+-------------+ 1030 | Logical Interface Handle | 1031 +-------------+-------------+-------------+-------------+ 1033 o VPN-IPv6 RSVP_HOP object: Class = 3, C-Type = TBA 1035 +-------------+-------------+-------------+-------------+ 1036 | | 1037 + + 1038 | | 1039 + IPv6 Next/Previous Hop Address (16 bytes) + 1040 | | 1041 + + 1042 | | 1043 +-------------+-------------+-------------+-------------+ 1044 | | 1045 + + 1046 | | 1047 + VPN-IPv6 Next/Previous Hop Address (24 bytes) + 1048 / / 1049 . . 1050 / / 1051 | | 1052 +-------------+-------------+-------------+-------------+ 1053 | Logical Interface Handle | 1054 +-------------+-------------+-------------+-------------+ 1056 The IPv4 Next/Previous Hop Address, IPv6 Next/Previous Hop Address 1057 and the Logical Interface Handle fields are identical to those of the 1058 RSVP_HOP object ([RFC2205]). 1060 The VPN-IPv4 Next/Previous Hop Address (respectively VPN-IPv6 Next/ 1061 Previous Hop Address) field contains an address of the VPN-IPv4 1062 (respectively VPN-IPv6) address family encoded as specified in 1063 [RFC4364] (respectively [RFC4659]). The content of this field is 1064 discussed in Section 3.1. 1066 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects 1068 The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SESSION object is 1069 described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively 1070 AGGREGATE-IPv6-VPN) SESSION object appears in RSVP messages that 1071 ordinarily contain a AGGREGATE-IPv4 (respectively AGGREGATE-IPv6) 1072 SESSION object as defined in [RFC3175] and are sent between ingress 1073 PE and egress PE in either direction. The GENERIC-AGGREGATE-VPN-IPv4 1074 (respectively AGGREGATE-VPN-IPv6) SESSION object should appear in all 1075 RSVP messages that ordinarily contain a GENERIC-AGGREGATE-IPv4 1076 (respectively GENERIC-AGGREGATE-IPv6) SESSION object as defined in 1077 [RFC4860] and are sent between ingress PE and egress PE in either 1078 direction. These objects MUST NOT be included in any RSVP messages 1079 that are sent outside of the provider's backbone (except in the 1080 inter-AS option B and C cases, as described above, when it may appear 1081 on inter-AS links). The processing rules for these objects are 1082 otherwise identical to those of the VPN-IPv4 (respectively VPN-IPv6) 1083 SESSION object defined in Section 8.1. The format of the object is 1084 as follows: 1086 o AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = TBA 1088 +-------------+-------------+-------------+-------------+ 1089 | | 1090 + + 1091 | VPN-IPv4 DestAddress (12 bytes) | 1092 + + 1093 | | 1094 +-------------+-------------+-------------+-------------+ 1095 | Reserved | Flags | Reserved | DSCP | 1096 +-------------+-------------+-------------+-------------+ 1098 o AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = TBA 1100 +-------------+-------------+-------------+-------------+ 1101 | | 1102 + + 1103 | | 1104 + VPN-IPv6 DestAddress (24 bytes) + 1105 / / 1106 . . 1107 / / 1108 | | 1109 +-------------+-------------+-------------+-------------+ 1110 | Reserved | Flags | Reserved | DSCP | 1111 +-------------+-------------+-------------+-------------+ 1113 The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field 1114 contains an address of the VPN-IPv4 (respectively VPN-IPv6) address 1115 family encoded as specified in [RFC4364] (respectively [RFC4659]). 1116 The content of this field is discussed in Section 3.2 and 1117 Section 3.3. 1119 The flags and DSCP are identical to the same fields of the AGGREGATE- 1120 IPv4 and AGGREGATE-IPv6 SESSION objects ([RFC3175]). 1122 The Reserved field MUST be set to zero on transmit and ignored on 1123 receipt. 1125 o GENERIC-AGGREGATE-VPN-IPv4 SESSION object: 1126 Class = 1, C-Type = TBA 1128 +-------------+-------------+-------------+-------------+ 1129 | | 1130 + + 1131 | VPN-IPv4 DestAddress (12 bytes) | 1132 + + 1133 | | 1134 +-------------+-------------+-------------+-------------+ 1135 | Reserved | Flags | PHB-ID | 1136 +-------------+-------------+-------------+-------------+ 1137 | Reserved | vDstPort | 1138 +-------------+-------------+-------------+-------------+ 1139 | Extended vDstPort | 1140 +-------------+-------------+-------------+-------------+ 1142 o GENERIC-AGGREGATE-VPN-IPv6 SESSION object: 1143 Class = 1, C-Type = TBA 1145 +-------------+-------------+-------------+-------------+ 1146 | | 1147 + + 1148 | | 1149 + VPN-IPv6 DestAddress (24 bytes) + 1150 / / 1151 . . 1152 / / 1153 | | 1154 +-------------+-------------+-------------+-------------+ 1155 | Reserved | Flags | PHB-ID | 1156 +-------------+-------------+-------------+-------------+ 1157 | Reserved | vDstPort | 1158 +-------------+-------------+-------------+-------------+ 1159 | Extended vDstPort | 1160 +-------------+-------------+-------------+-------------+ 1162 The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field 1163 contains an address of the VPN-IPv4 (respectively VPN-IPv6) address 1164 family encoded as specified in [RFC4364] (respectively [RFC4659]). 1165 The content of this field is discussed in Section 3.2 and 1166 Section 3.3. 1168 The flags, PHB-ID, vDstPort and Extended vDstPort are identical to 1169 the same fields of the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE- 1170 IPv6 SESSION objects ([RFC4860]). 1172 The Reserved field MUST be set to zero on transmit and ignored on 1173 receipt. 1175 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 SENDER_TEMPLATE objects 1177 The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object 1178 is described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively 1179 AGGREGATE-VPN-IPv6) SENDER_TEMPLATE object appears in RSVP messages 1180 that ordinarily contain a AGGREGATE-IPv4 (respectively AGGREGATE- 1181 IPv6) SENDER_TEMPLATE object as defined in [RFC3175] and [RFC4860], 1182 and are sent between ingress PE and egress PE in either direction. 1183 These objects MUST NOT be included in any RSVP messages that are sent 1184 outside of the provider's backbone (except in the inter-AS option B 1185 and C cases, as described above, when it may appear on inter-AS 1186 links). The processing rules for these objects are otherwise 1187 identical to those of the VPN-IPv4 (respectively VPN-IPv6) 1188 SENDER_TEMPLATE object defined in Section 8.2. The format of the 1189 object is as follows: 1191 o AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object: 1192 Class = 11, C-Type = TBA 1194 +-------------+-------------+-------------+-------------+ 1195 | | 1196 + + 1197 | VPN-IPv4 AggregatorAddress (12 bytes) | 1198 + + 1199 | | 1200 +-------------+-------------+-------------+-------------+ 1202 o AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object: 1203 Class = 11, C-Type = TBA 1205 +-------------+-------------+-------------+-------------+ 1206 | | 1207 + + 1208 | | 1209 + VPN-IPv6 AggregatorAddress (24 bytes) + 1210 / / 1211 . . 1212 / / 1213 | | 1214 +-------------+-------------+-------------+-------------+ 1216 The VPN-IPv4 AggregatorAddress (respectively VPN-IPv6 1217 AggregatorAddress) field contains an address of the VPN-IPv4 1218 (respectively VPN-IPv6) address family encoded as specified in 1219 [RFC4364] (respectively [RFC4659]). The content and processing rules 1220 for these objects are similar to those of the VPN-IPv4 1221 SENDER_TEMPLATE object defined in Section 8.2. 1223 The flags and DSCP are identical to the same fields of the AGGREGATE- 1224 IPv4 and AGGREGATE-IPv6 SESSION objects. 1226 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC objects 1228 The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in 1229 Section 7.3. The AGGREGATE-VPN-IPv4 FILTER_SPEC object appears in 1230 RSVP messages that ordinarily contain a AGGREGATE-IPv4 FILTER_SPEC 1231 object as defined in [RFC3175] and [RFC4860], and are sent between 1232 ingress PE and egress PE in either direction. These objects MUST NOT 1233 be included in any RSVP messages that are sent outside of the 1234 provider's backbone (except in the inter-AS option B and C cases, as 1235 described above, when it may appear on inter-AS links). The 1236 processing rules for these objects are otherwise identical to those 1237 of the VPN-IPv4 FILTER_SPEC object defined in Section 8.3. The 1238 format of the object is as follows: 1240 o AGGREGATE-VPN-IPv4 FILTER_SPEC object: 1241 Class = 10, C-Type = TBA 1243 Definition same as AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object. 1245 o AGGREGATE-VPN-IPv6 FILTER_SPEC object: 1246 Class = 10, C-Type = TBA 1248 Definition same as AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object. 1250 9. IANA Considerations 1252 Section 8 defines new objects. Therefore, this document requests 1253 IANA to modify the RSVP parameters registry, 'Class Names, Class 1254 Numbers, and Class Types' subregistry, and: 1256 o assign six new C-Types under the existing SESSION Class (Class 1257 number 1), as suggested below: 1259 Class 1260 Number Class Name Reference 1261 ------ ----------------------- --------- 1263 1 SESSION [RFC2205] 1265 Class Types or C-Types: 1267 .. ... ... 1268 aa VPN-IPv4 [RFCXXXX] 1269 bb VPN-IPv6 [RFCXXXX] 1270 cc AGGREGATE-VPN-IPv4 [RFCXXXX] 1271 dd AGGREGATE-VPN-IPv6 [RFCXXXX] 1272 ee GENERIC-AGGREGATE-VPN-IPv4 [RFCXXXX] 1273 ff GENERIC-AGGREGATE-VPN-IPv6 [RFCXXXX] 1275 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1276 number of this specification. Suggested values: aa-ff=19-24] 1278 o assign four new C-Types under the existing SENDER_TEMPLATE Class 1279 (Class number 11), as suggested below: 1281 Class 1282 Number Class Name Reference 1283 ------ ----------------------- --------- 1285 11 SENDER_TEMPLATE [RFC2205] 1287 Class Types or C-Types: 1289 .. ... ... 1290 aa VPN-IPv4 [RFCXXXX] 1291 bb VPN-IPv6 [RFCXXXX] 1292 cc AGGREGATE-VPN-IPv4 [RFCXXXX] 1293 dd AGGREGATE-VPN-IPv6 [RFCXXXX] 1295 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1296 number of this specification. Suggested values: aa-dd=14-17] 1298 o assign four new C-Types under the existing FILTER_SPEC Class 1299 (Class number 10), as suggested below: 1301 Class 1302 Number Class Name Reference 1303 ------ ----------------------- --------- 1305 10 FILTER_SPEC [RFC2205] 1307 Class Types or C-Types: 1309 .. ... ... 1310 aa VPN-IPv4 [RFCXXXX] 1311 bb VPN-IPv6 [RFCXXXX] 1312 cc AGGREGATE-VPN-IPv4 [RFCXXXX] 1313 dd AGGREGATE-VPN-IPv6 [RFCXXXX] 1315 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1316 number of this specification. Suggested values: aa-dd=14-17] 1318 o assign two new C-Types under the existing RSVP_HOP Class (Class 1319 number 3), as suggested below: 1321 Class 1322 Number Class Name Reference 1323 ------ ----------------------- --------- 1325 3 RSVP_HOP [RFC2205] 1327 Class Types or C-Types: 1329 .. ... ... 1330 aa VPN-IPv4 [RFCXXXX] 1331 bb VPN-IPv6 [RFCXXXX] 1333 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1334 number of this specification. Suggested values: aa-bb=5-6] 1336 In addition, a new PathError code/value is required to identify a 1337 signaling reachability failure and the need for a VPN-IPv4 or VPN- 1338 IPv6 RSVP_HOP object as described in Section 5.2.2. Therefore, this 1339 document requests IANA to modify the RSVP parameters registry, 'Error 1340 Codes and Globally-Defined Error Value Sub-Codes' subregistry, and: 1342 o assign a new Error Code and sub-code, as suggested below: 1344 aa RSVP over MPLS Problem [RFCXXXX] 1346 This Error Code has the following globally-defined Error 1347 Value sub-codes: 1349 1 = RSVP_HOP not reachable across VPN [RFCXXXX] 1351 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1352 number of this specification. Suggested values: aa=34] 1354 10. Security Considerations 1356 [RFC4364] addresses the security considerations of BGP/MPLS VPNs in 1357 general. General RSVP security considerations are discussed in 1358 [RFC2205]. To ensure the integrity of RSVP, the RSVP Authentication 1359 mechanisms defined in [RFC2747] and [RFC3097] SHOULD be supported. 1360 Those protect RSVP message integrity hop-by-hop and provide node 1361 authentication as well as replay protection, thereby protecting 1362 against corruption and spoofing of RSVP messages. 1363 [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of 1364 various keying approaches for RSVP Authentication. First, we note 1365 that the discussion about applicability of group keying to an intra- 1366 provider environment where RSVP hops are not IP hops is relevant to 1367 securing of RSVP among PEs of a given Service Provider deploying the 1368 solution specified in the present document. We note that the RSVP 1369 signaling in MPLS VPN is likely to spread over multiple 1370 administrative domains (e.g. The service provider operating the VPN 1371 service, and the customers of the service). Therefore the 1372 considerations in [I-D.ietf-tsvwg-rsvp-security-groupkeying] about 1373 inter-domain issues are likely to apply. 1375 Since RSVP messages travel through the L3VPN cloud directly addressed 1376 to PE or ASBR routers (without IP router alert option), P routers 1377 remain isolated from RSVP messages signaling customer reservations. 1378 Providers MAY choose to block PEs from sending datagrams with the 1379 router alert option to P routers as a security practice, without 1380 impacting the functionality described herein. 1382 Beyond those general issues, four specific issues are introduced by 1383 this document: resource usage on PEs, resource usage in the provider 1384 backbone, PE route advertisement outside the AS, and signaling 1385 exposure to ASBRs and PEs. We discuss these in turn. 1387 A customer who makes resource reservations on the CE-PE links for his 1388 sites is only competing for link resources with himself, as in 1389 standard RSVP, at least in the common case where each CE-PE link is 1390 dedicated to a single customer. Thus, from the perspective of the 1391 CE-PE links, the present document does not introduce any new security 1392 issues. However, because a PE typically serves multiple customers, 1393 there is also the possibility that a customer might attempt to use 1394 excessive computational resources on a PE (CPU cycles, memory etc.) 1395 by sending large numbers of RSVP messages to a PE. In the extreme 1396 this could represent a form of denial-of-service attack. In order to 1397 prevent such an attack, a PE SHOULD support mechanisms to limit the 1398 fraction of its processing resources that can be consumed by any one 1399 CE or by the set of CEs of a given customer. For example, a PE might 1400 implement a form of rate limiting on RSVP messages that it receives 1401 from each CE. We observe that these security risks and measures 1402 related to PE resource usage are very similar for any control plane 1403 protocol operating between CE and PE (e.g. RSVP, routing, 1404 multicast). 1406 The second concern arises only when the service provider chooses to 1407 offer resource reservation across the backbone, as described in 1408 Section 4. In this case, the concern may be that a single customer 1409 might attempt to reserve a large fraction of backbone capacity, 1410 perhaps with a co-ordinated effort from several different CEs, thus 1411 denying service to other customers using the same backbone. 1412 [RFC4804] provides some guidance on the security issues when RSVP 1413 reservations are aggregated onto MPLS tunnels, which are applicable 1414 to the situation described here. We note that a provider MAY use 1415 local policy to limit the amount of resources that can be reserved by 1416 a given customer from a particular PE, and that a policy server could 1417 be used to control the resource usage of a given customer across 1418 multiple PEs if desired. It is RECOMMENDED that an implementation of 1419 this specification support local policy on the PE to control the 1420 amount of resources that can be reserved by a given customer/CE. 1422 Use of the VPN-IPv4 RSVP_HOP object requires exporting a PE VPN-IPv4 1423 route to another AS, and potentially could allow unchecked access to 1424 remote PEs if those routes were indiscriminately redistributed. 1425 However, as described in Section 3.1, no route which is not within a 1426 customer's VPN should ever be advertised to (or reachable from) that 1427 customer. If a PE uses a local address already within a customer VRF 1428 (like PE-CE link address), it MUST NOT send this address in any RSVP 1429 messages in a different customer VRF. A "control plane" VPN MAY be 1430 created across PEs and ASBRs and addresses in this VPN can be used to 1431 signal RSVP sessions for any customers, but these routes MUST NOT be 1432 advertised to, or made reachable from, any customer. An 1433 implementation of the present document MAY support such operation 1434 using a "control plane" VPN. Alternatively, ASBRs MAY implement the 1435 signaling procedures described in Section 5.2.1, even if admission 1436 control is not required on the inter-AS link, as these procedures do 1437 not require any direct P/PE route advertisement out of the AS. 1439 Finally, certain operations described herein (Section 3) require an 1440 ASBR or PE to receive and locally process a signaling packet 1441 addressed to the BGP next-hop address advertised by that router. 1442 This requirement does not strictly apply to MPLS/BGP VPNs [RFC4364]. 1443 This could be viewed as opening ASBRs and PEs to being directly 1444 addressable by customer devices where they were not open before, and 1445 could be considered a security issue. If a provider wishes to 1446 mitigate this situation, the implementation MAY support the "control 1447 protocol VPN" approach described above. That is, whenever a 1448 signaling message is to be sent to a PE or ASBR, the address of the 1449 router in question would be looked up in the "control protocol VPN", 1450 and the message would then be sent on the LSP that is found as a 1451 result of that lookup. This would ensure that the router address is 1452 not reachable by customer devices. 1454 [RFC4364] mentions use of IPsec both on a CE-CE basis and PE-PE 1455 basis: "Cryptographic privacy is not provided by this architecture, 1456 nor by Frame Relay or ATM VPNs. These architectures are all 1457 compatible with the use of cryptography on a CE-CE basis, if that is 1458 desired. The use of cryptography on a PE-PE basis is for further 1459 study." 1461 The procedures specified in the present document for admission 1462 control on the PE-CE links (Section 3) are compatible with the use of 1463 IPsec on a PE-PE basis. The optional procedures specified in the 1464 present document for admission control in the Service Provider's 1465 backbone (Section 4) are not compatible with the use of IPsec on a 1466 PE-PE basis, since those procedures depend on the use of PE-PE MPLS 1467 TE Tunnels to perform aggregate reservations through the Service 1468 Provider's backbone. 1470 [RFC4923] describes a model for RSVP operation through IPsec 1471 Gateways. In a nutshell, a form of hierarchical RSVP reservation is 1472 used where an RSVP reservation is made for the IPsec tunnel and then 1473 individual RSVP reservations are admitted/aggregated over the tunnel 1474 reservation. This model applies to the case where IPsec is used on a 1475 CE-CE basis. In that situation, the procedures defined in the 1476 present document would simply apply "as is" to the reservation 1477 established for the IPsec tunnel(s). 1479 11. Acknowledgments 1481 Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric 1482 Rosen, Dan Tappan and Lou Berger for their many contributions to 1483 solving the problems described in this document. Thanks to Ferit 1484 Yegenoglu for his useful comments. We also thank Stefan Santesson 1485 Vijay Gurbani and Alexey Melnikov for their review comments. We 1486 thank Richard Woundy for his very thorough review and comments 1487 including those that resulted in additional text discussing scenarios 1488 of admission control reject in the MPLS VPN cloud. Also, we thank 1489 Adrian Farrel for his detailed review and contributions. 1491 Appendix A. Alternatives Considered 1493 At this stage a number of alternatives to the approach described 1494 above have been considered. We document some of the approaches 1495 considered here to assist future discussion. None of these has been 1496 shown to improve upon the approach described above, and the first two 1497 seem to have significant drawbacks relative to the approach described 1498 above. 1500 Appendix A.1. GMPLS UNI approach 1502 [RFC4208] defines the GMPLS UNI. In Section 7 the operation of the 1503 GMPLS UNI in a VPN context is briefly described. This is somewhat 1504 similar to the problem tackled in the current document. The main 1505 difference is that the GMPLS UNI is primarily aimed at the problem of 1506 allowing a CE device to request the establishment of an LSP across 1507 the network on the other side of the UNI. Hence the procedures in 1508 [RFC4208] would lead to the establishment of an LSP across the VPN 1509 provider's network for every RSVP request received, which is not 1510 desired in this case. 1512 To the extent possible, the approach described in this document is 1513 consistent with [RFC4208], while filling in more of the details and 1514 avoiding the problem noted above. 1516 Appendix A.2. Label switching approach 1518 Implementations that always look at IP headers inside the MPLS label 1519 on the egress PE can intercept Path messages and determine the 1520 correct VRF and RSVP state by using a combination of the 1521 encapsulating VPN label and the IP header. In our view, this is an 1522 undesirable approach for two reasons. Firstly, it imposes a new MPLS 1523 forwarding requirement for all data packets on the egress PE. 1524 Secondly, it requires using the encapsulating MPLS label to identify 1525 RSVP state, which runs counter to existing RSVP principle and 1526 practice where all information used to identify RSVP state is 1527 included within RSVP objects. RSVP extensions such as COPS/RSVP 1528 [RFC2749] which re-encapsulate RSVP messages are incompatible with 1529 this change. 1531 Appendix A.3. VRF label approach 1533 Another approach to solving the problems described here involves the 1534 use of label switching to ensure that Path, Resv, and other RSVP 1535 messages are directed to the appropriate VRF on the next RSVP hop 1536 (e.g. egress PE). One challenge with such an approach is that 1537 [RFC4364] does not require labels to be allocated for VRFs, only for 1538 customer prefixes, and that there is no simple, existing method for 1539 advertising the fact that a label is bound to a VRF. If, for 1540 example, an ingress PE sent a Path message labelled with a VPN label 1541 that was advertised by the egress PE for the prefix that matches the 1542 destination address in the Path, there is a risk that the egress PE 1543 would simply label-switch the Path directly on to the CE without 1544 performing RSVP processing. 1546 A second challenge with this approach is that an IP address needs to 1547 be associated with a VRF and used as the PHOP address for the Path 1548 message sent from ingress PE to egress PE. That address needs to be 1549 reachable from the egress PE, and to exist in the VRF at the ingress 1550 PE. Such an address is not always available in today's deployments, 1551 so this represents at least a change to existing deployment 1552 practices. 1554 Appendix A.4. VRF label plus VRF address approach 1556 It is possible to create an approach based on that described in the 1557 previous section which addresses the main challenges of that 1558 approach. The basic approach has two parts: (a) define a new BGP 1559 Extended Community to tag a route (and its associated MPLS label) as 1560 pointing to a VRF; (b) allocate a "dummy" address to each VRF, 1561 specifically to be used for routing RSVP messages. The dummy address 1562 (which could be anything, e.g. a loopback of the associated PE) would 1563 be used as a PHOP for Path messages and would serve as the 1564 destination for Resv messages but would not be imported into VRFs of 1565 any other PE. 1567 12. References 1569 12.1. Normative References 1571 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 1572 February 1997. 1574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1575 Requirement Levels", BCP 14, RFC 2119, March 1997. 1577 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1579 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1580 Functional Specification", RFC 2205, September 1997. 1582 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1583 RFC 2711, October 1999. 1585 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 1586 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 1587 RFC 3175, September 2001. 1589 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1590 Networks (VPNs)", RFC 4364, February 2006. 1592 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1593 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1594 IPv6 VPN", RFC 4659, September 2006. 1596 [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation 1597 Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", 1598 RFC 4804, February 2007. 1600 12.2. Informative References 1602 [I-D.ietf-intarea-router-alert-considerations] 1603 Faucheur, F., "IP Router Alert Considerations and Usage", 1604 draft-ietf-intarea-router-alert-considerations-00 (work in 1605 progress), March 2010. 1607 [I-D.ietf-l3vpn-e2e-rsvp-te-reqts] 1608 Kumaki, K., Kamite, Y., and R. Zhang, "Requirements for 1609 supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP- 1610 VPN", draft-ietf-l3vpn-e2e-rsvp-te-reqts-05 (work in 1611 progress), December 2009. 1613 [I-D.ietf-mpls-ip-options] 1614 Jaeger, W., Mullooly, J., Scholl, T., and D. Smith, 1615 "Requirements for Label Edge Router Forwarding of IPv4 1616 Option Packets", draft-ietf-mpls-ip-options-04 (work in 1617 progress), May 2010. 1619 [I-D.ietf-nsis-ntlp] 1620 Schulzrinne, H. and M. Stiemerling, "GIST: General 1621 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 1622 (work in progress), June 2009. 1624 [I-D.ietf-nsis-qos-nslp] 1625 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 1626 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 1627 (work in progress), January 2010. 1629 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 1630 Behringer, M. and F. Faucheur, "Applicability of Keying 1631 Methods for RSVP Security", 1632 draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in 1633 progress), June 2009. 1635 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1636 Services in the Internet Architecture: an Overview", 1637 RFC 1633, June 1994. 1639 [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol 1640 (RSVP) -- Version 1 Message Processing Rules", RFC 2209, 1641 September 1997. 1643 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1644 Services", RFC 2210, September 1997. 1646 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1647 Authentication", RFC 2747, January 2000. 1649 [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., 1650 and A. Sastry, "The COPS (Common Open Policy Service) 1651 Protocol", RFC 2748, January 2000. 1653 [RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., 1654 and A. Sastry, "COPS usage for RSVP", RFC 2749, 1655 January 2000. 1657 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1658 and S. Molendini, "RSVP Refresh Overhead Reduction 1659 Extensions", RFC 2961, April 2001. 1661 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 1662 Authentication -- Updated Message Type Value", RFC 3097, 1663 April 2001. 1665 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1666 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1667 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1669 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1670 Hierarchy with Generalized Multi-Protocol Label Switching 1671 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 1673 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1674 "Generalized Multiprotocol Label Switching (GMPLS) User- 1675 Network Interface (UNI): Resource ReserVation Protocol- 1676 Traffic Engineering (RSVP-TE) Support for the Overlay 1677 Model", RFC 4208, October 2005. 1679 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 1680 Davenport, "Generic Aggregate Resource ReSerVation 1681 Protocol (RSVP) Reservations", RFC 4860, May 2007. 1683 [RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling 1684 in a Nested Virtual Private Network", RFC 4923, 1685 August 2007. 1687 Authors' Addresses 1689 Bruce Davie 1690 Cisco Systems, Inc. 1691 1414 Mass. Ave. 1692 Boxborough, MA 01719 1693 USA 1695 Email: bsd@cisco.com 1697 Francois le Faucheur 1698 Cisco Systems, Inc. 1699 Village d'Entreprise Green Side - Batiment T3 1700 400, Avenue de Roumanille 1701 Biot Sophia-Antipolis 06410 1702 France 1704 Email: flefauch@cisco.com 1706 Ashok Narayanan 1707 Cisco Systems, Inc. 1708 1414 Mass. Ave. 1709 Boxborough, MA 01719 1710 USA 1712 Email: ashokn@cisco.com