idnits 2.17.1 draft-ietf-tsvwg-rsvp-l3vpn-06.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 (April 25, 2010) is 5115 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 1339, but not defined == Unused Reference: 'RFC2749' is defined on line 1625, but no explicit reference was found in the text == 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-03 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-05 Summary: 0 errors (**), 0 flaws (~~), 6 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: October 27, 2010 Cisco Systems, Inc. 6 April 25, 2010 8 Support for RSVP in Layer 3 VPNs 9 draft-ietf-tsvwg-rsvp-l3vpn-06.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 October 27, 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. VRF label approach . . . . . . . . . . . . . . . . . 34 115 Appendix A.3. VRF label plus VRF address approach . . . . . . . . 35 116 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 117 12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 118 12.2. Informative References . . . . . . . . . . . . . . . . . . 36 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 121 1. Introduction 123 [RFC4364] and [RFC4659] define a Layer 3 VPN service known as BGP/ 124 MPLS VPNs for IPv4 and for IPv6 respectively. [RFC2205] defines the 125 Resource Reservation Protocol (RSVP) which may be used to perform 126 admission control as part of the Integrated Services (Int-Serv) 127 architecture [RFC1633][RFC2210]. 129 Customers of a layer 3 VPN service may run RSVP for the purposes of 130 admission control (and associated resource reservation) in their own 131 networks. Since the links between Provider Edge (PE) and Customer 132 Edge (CE) routers in a layer 3 VPN may often be resource constrained, 133 it may be desirable to be able to perform admission control over 134 those links. In order to perform admission control using RSVP in 135 such an environment, it is necessary that RSVP control messages, such 136 as Path messages and Resv messages, are appropriately handled by the 137 PE routers. This presents a number of challenges in the context of 138 BGP/MPLS VPNs: 140 o RSVP Path message processing depends on routers recognizing the 141 router alert option ([RFC2113], [RFC2711]) in the IP header. 142 However, packets traversing the backbone of a BGP/MPLS VPN are 143 MPLS encapsulated and thus the router alert option may not be 144 normally visible to the egress PE, due to implementation or policy 145 considerations. 147 o BGP/MPLS VPNs support non-unique addressing of customer networks. 148 Thus a PE at the ingress or egress of the provider backbone may be 149 called upon to process Path messages from different customer VPNs 150 with non-unique destination addresses within the RSVP message. 151 Current mechanisms for identifying customer context from data 152 packets are incompatible with RSVP message processing rules. 154 o A PE at the ingress of the provider's backbone may receive Resv 155 messages corresponding to different customer VPNs from other PEs, 156 and needs to be able to associate those Resv messages with the 157 appropriate customer VPNs. 159 This document describes a set of procedures to overcome these 160 challenges and thus to enable admission control using RSVP over the 161 PE-CE links. We note that similar techniques may be applicable to 162 other protocols used for admission control such as the combination of 163 the NSIS Signaling Layer Protocol (NSLP) for QoS Signaling 164 ([I-D.ietf-nsis-qos-nslp]) and General Internet Signaling Transport 165 (GIST) protocol ([I-D.ietf-nsis-ntlp]). 167 Additionally, it may be desirable to perform admission control over 168 the provider's backbone on behalf of one or more L3VPN customers. 170 Core (P) routers in a BGP/MPLS VPN do not have forwarding entries for 171 customer routes, and thus cannot natively process RSVP messages for 172 customer flows. Also the core is a shared resource that carries 173 traffic for many customers, so issues of resource allocation among 174 customers and trust (or lack thereof) also ought to be addressed. 175 This document specifies procedures for supporting such a scenario. 177 This document deals with establishing reservations for unicast flows 178 only. Because the support of multicast traffic in BGP/MPLS VPNs is 179 still evolving, and raises additional challenges for admission 180 control, we leave the support of multicast flows for further study at 181 this point. 183 1.1. Terminology 185 This document draws freely on the terminology defined in [RFC2205] 186 and [RFC4364]. For convenience, we provide a few brief definitions 187 here: 189 o CE (Customer Edge) Router: Router at the edge of a customer site 190 that attaches to the network of the VPN provider. 192 o PE (Provider Edge) Router: Router at the edge of the service 193 provider's network that attaches to one or more customer sites. 195 o VPN Label: An MPLS label associated with a route to a customer 196 prefix in a VPN (also called a VPN route label). 198 o VRF: VPN Routing and Forwarding Table. A PE typically has 199 multiple VRFs, enabling it to be connected to CEs that are in 200 different VPNs. 202 2. Problem Statement 204 The problem space of this document is the support of admission 205 control between customer sites when the customer subscribes to a BGP/ 206 MPLS VPN. We subdivide the problem into (a) the problem of admission 207 control on the PE-CE links (in both directions), and (b) the problem 208 of admission control across the provider's backbone. 210 RSVP Path messages are normally addressed to the destination of a 211 session, and contain the Router Alert Option (RAO) within the IP 212 header. Routers along the path to the destination that are 213 configured to process RSVP messages need to detect the presence of 214 the RAO to allow them to intercept Path messages. However, the 215 egress PEs of a network supporting BGP/MPLS VPNs receive packets 216 destined for customer sites as MPLS-encapsulated packets, and 217 possibly forwards those based only on examination of the MPLS label. 218 Hence, a Path message would be forwarded without examination of the 219 IP options and would therefore not receive appropriate processing at 220 the PE. Another potential issue is doing CAC at an ASBR. Even an 221 implementation that examines the IP header when removing the VPN 222 label (e.g. PE-CE link) would not be able to do CAC at an Option-B 223 ASBR; that requires examining the (interior) IP header while doing a 224 label swap, which is a much less desirable feature. In general, 225 there are significant issues with requiring support for IP Router- 226 Alert outside of a controller, "walled-garden" network, as described 227 in [I-D.ietf-intarea-router-alert-considerations]. The issues with 228 requiring interior MPLS routers to process IP Router-Alert marked 229 packets are also described in [I-D.ietf-mpls-ip-options]. For these 230 reasons, it is highly desirable to remove the dependency on router 231 alert option across administrative domains (such as from a customer 232 network to an egress PE, or such as across ASBRs in inter- provider 233 MPLS VPN scenarios). The approach for RSVP packet handling described 234 in this document has the advantage of being independent of any data- 235 plane requirements such as IP Router-Alert support within the VPN. 236 The only requirement for processing IP Router-Alert packets is for 237 RSVP packets received from the CE, which do not carry any MPLS 238 encapsulation. 240 For the PE-CE link subproblem, the most basic challenge is that RSVP 241 control messages contain IP addresses that are drawn from the 242 customer's address space, and PEs need to deal with traffic from many 243 customers who may have non-unique (or overlapping) address spaces. 244 Thus, it is essential that a PE be able in all cases to identify the 245 correct VPN context in which to process an RSVP control message. The 246 current mechanism for identifying the customer context is the VPN 247 Label, which is carried in a MPLS header outside of the RSVP message. 248 This is divergent from the general RSVP model of session 249 identification ([RFC2205], [RFC2209]), which relies solely on RSVP 250 objects to identify sessions. Further, it is incompatible with 251 protocols like COPS/RSVP ([RFC2748],[RFC2748]), which replace the IP 252 encapsulation of the RSVP message and send only RSVP objects to a 253 COPS server. We believe it is important to retain the model of 254 completely identifying an RSVP session from the contents of RSVP 255 objects. Much of this document deals with this issue. 257 For the case of making reservations across the provider backbone, we 258 observe that BGP/MPLS VPNs do not create any per-customer forwarding 259 state in the P (provider core) routers. Thus, in order to make 260 reservations on behalf of customer-specified flows, it is clearly 261 necessary to make some sort of aggregated reservation from PE-PE and 262 then map individual, customer-specific reservations onto an aggregate 263 reservation. That is similar to the problem tackled in [RFC3175] and 264 [RFC4804], with the additional complications of handling customer- 265 specific addressing associated with BGP/MPLS VPNs. 267 Consider the case where an MPLS VPN customer uses RSVP signaling 268 across his sites for resource reservation and admission control. 269 Let's further assume that, initially, RSVP is not processed through 270 the MPLS VPN cloud (i.e RSVP messages from the sender to the receiver 271 travel transparently from CE to CE). In that case, RSVP allows 272 establishment of resource reservations and admission control on a 273 subset of the flow path (from sender to ingress CE; and from the RSVP 274 router downstream of the egress CE to the receiver). If admission 275 control is then activated on any of the CE-PE link, provider's 276 backbone or PE-CE link (as allowed by the present document), the 277 customer will benefit from an extended coverage of admission control 278 and resource reservation: the resource reservation will now span over 279 a bigger subset of (and possibly the whole) flow path, which in turn 280 will increase the quality of service granted to the corresponding 281 flow. Specific flows whose reservation is successful through 282 admission control on the newly enabled segments will indeed benefit 283 from this quality of service enhancement. However, it must be noted 284 that, in case there is not enough resources on one (or more) of the 285 newly enabled segments (e.g. Say admission control is enabled on a 286 given PE-->CE link and there is not enough capacity on that link to 287 admit all reservations for all the flows traversing that link) then 288 some flows will not be able to maintain, or establish, their 289 reservation. While this may appear undesirable for these flows, we 290 observe that this only occurs if there is indeed a lack of capacity 291 on a segment, and that in the absence of admission control all flows 292 would be established but would all suffer from the resulting 293 congestion on the bottleneck segment. We also observe that, in case 294 of such lack of capacity, admission control allows enforcement of 295 controlled and flexible policies (so that, for example, more 296 important flows can be granted higher priority at reserving 297 resources). We note also that flows are given a chance to establish 298 smaller reservations so that the aggregate load can adapt dynamically 299 to the bottleneck capacity. 301 2.1. Model of Operation 303 Figure 1 illustrates the basic model of operation with which this 304 document is concerned. 306 -------------------------- 307 / Provider \ 308 |----| | Backbone | |----| 309 Sender->| CE1| |-----| |-----| |CE2 |->Receiver 310 | |--| | |---| |---| | |---| | 311 |----| | | | P | | P | | | |----| 312 | PE1 |---| |-----| |-----| PE2 | 313 | | | | | | | | 314 | | |---| |---| | | 315 |-----| |-----| 316 | | 317 \ / 318 -------------------------- 320 Figure 1. Model of Operation for RSVP-based admission control over 321 MPLS/BGP VPN 323 To establish a unidirectional reservation for a point-to-point flow 324 from Sender to Receiver that takes account of resource availability 325 on the CE-PE and PE-CE links only, the following steps need to take 326 place: 328 1. Sender sends a Path message to an IP address of the Receiver. 330 2. Path message is processed by CE1 using normal RSVP procedures 331 and forwarded towards the Receiver along the link CE1-PE1. 333 3. PE1 processes Path message and forwards towards the Receiver 334 across the provider backbone. 336 4. PE2 processes Path message and forwards towards the Receiver 337 along link PE2-CE2. 339 5. CE2 processes Path message using normal RSVP procedures and 340 forwards towards Receiver. 342 6. Receiver sends Resv message to CE2. 344 7. CE2 sends Resv message to PE2. 346 8. PE2 processes Resv message (including performing admission 347 control on link PE2-CE2) and sends Resv to PE1. 349 9. PE1 processes Resv message and sends Resv to CE1. 351 10. CE1 processes Resv using normal RSVP procedures, performs 352 admission control on the link CE1-PE1 and sends Resv message to 353 Sender if successful. 355 In each of the steps involving Resv messages (6 through 10) the node 356 sending the Resv uses the previously established Path state to 357 determine the "RSVP Previous Hop (PHOP)" and sends a Resv message to 358 that address. We note that establishing that Path state correctly at 359 PEs is one of the challenges posed by the BGP/MPLS environment. 361 3. Admission Control on PE-CE Links 363 In the following sections we trace through the steps outlined in 364 Section 2.1 and expand on the details for those steps where standard 365 RSVP procedures need to be extended or modified to support the BGP/ 366 MPLS VPN environment. For all the remaining steps described in the 367 preceding section, standard RSVP processing rules apply. 369 All the procedures described below support both IPv4 and IPv6 370 addressing. In all cases where IPv4 is referenced, IPv6 can be 371 substituted with identical procedures and results. Object 372 definitions for both IPv4 and IPv6 are provided in Section 8. 374 3.1. New Objects of Type VPN-IPv4 376 For RSVP signaling within a VPN, certain RSVP objects need to be 377 extended. Since customer IP addresses need not be unique, the 378 current types of SESSION, SENDER_TEMPLATE and FILTERSPEC objects are 379 no longer sufficient to globally identify RSVP states in P/PE 380 routers, since those are currently based on IP addresses. We propose 381 new types of SESSION, SENDER_TEMPLATE and FILTERSPEC objects, which 382 contain globally unique VPN-IPv4 format addresses. The ingress and 383 egress PE nodes translate between the regular IPv4 addresses for 384 messages to and from the CE, and VPN-IPv4 addresses for messages to 385 and from PE routers. The rules for this translation are described in 386 later sections. 388 The RSVP_HOP object in a RSVP message currently specifies an IP 389 address to be used by the neighboring RSVP hop to reply to the 390 message sender. However, MPLS VPN PE routers (especially those 391 separated by Option-B Autonomous System Border Routers -ASBRs) are 392 not required to have direct IP reachability to each other. To solve 393 this issue, we propose the use of label switching to forward RSVP 394 messages between nodes within a MPLS VPN. This is achieved by 395 defining a new VPN-IPv4 RSVP_HOP object. Use of the VPN-IPv4 396 RSVP_HOP object enables any two adjacent RSVP hops in a MPLS VPN 397 (e.g. a PE in AS 1 and a PE in AS2) to correctly identify each other 398 and send RSVP messages directly to each other. 400 The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message 401 sender and a Logical Interface Handle (LIH) as before, but in 402 addition carries a VPN-IPv4 address which also represents the sender 403 of the message. The message sender MUST also advertise this VPN-IPv4 404 address into BGP, associated with a locally allocated label, and this 405 advertisement MUST be propagated by BGP throughout the VPN and to 406 adjacent ASes if required to provide reachability to this PE. Frames 407 received by the PE marked with this label MUST be given to the local 408 control plane for processing. When a neighboring RSVP hop wishes to 409 reply to a message carrying a VPN-IPv4 RSVP_HOP, it looks for a BGP 410 advertisement of the VPN-IPv4 address contained in that RSVP_HOP. If 411 this address is found and carries an associated label, the 412 neighboring RSVP node MUST encapsulate the RSVP message with this 413 label and send it via MPLS encapsulation to the BGP next-hop 414 associated with the route. The destination IP address of the message 415 is taken from the IP address field of the RSVP_HOP object, as 416 described in [RFC2205]. Additionally, the IPv4 address in the 417 RSVP_HOP object continues to be used for all other existing purposes, 418 including neighbor matching between Path/Resv and SRefresh messages 419 ([RFC2961]), authentication ([RFC2747]), etc. 421 The VPN-IPv4 address used in the VPN-IPv4 RSVP_HOP object MAY 422 represent an existing address in the VRF that corresponds to the flow 423 (e.g. a local loopback or PE-CE link address within the VRF for this 424 customer), or MAY be created specially for this purpose. In the case 425 where the address is specially created for RSVP signaling (and 426 possibly other control protocols), the BGP advertisement MUST NOT be 427 redistributed to, or reachable by, any CEs outside the MPLS VPN. One 428 way to achieve this is by creating a special "control protocols VPN" 429 with VRF state on every PE/ASBR, carrying route targets not imported 430 into customer VRFs. In the case where a customer VRF address is used 431 as the VPN-IPv4 address, a VPN-IPv4 address in one customer VRF MUST 432 NOT be used to signal RSVP messages for a flow in a different VRF. 434 If a PE/ASBR is sending a Path message to another PE/ASBR within the 435 VPN, and it has any appropriate VPN-IPv4 address for signaling that 436 satisfies the requirements outlined above, it MUST use a VPN-IPv4 437 RSVP_HOP object with this address for all RSVP messages within the 438 VPN. If a PE/ASBR does not have any appropriate VPN-IPv4 address to 439 use for signaling, it MAY send the Path message with a regular IPv4 440 RSVP_HOP object. In this case, the reply will be IP encapsulated. 441 This option is not preferred because there is no guarantee that the 442 neighboring RSVP hop has IP reachability to the sending node. If a 443 PE/ASBR receives or originates a Path message with a VPN-IPv4 444 RSVP_HOP object, any RSVP_HOP object in corresponding upstream 445 messages for this flow (e.g. Resv, ResvTear) or downstream messages 446 (e.g. ResvError, PathTear) sent by this node within the VPN MUST be 447 a VPN-IPv4 RSVP_HOP. 449 3.2. Path Message Processing at Ingress PE 451 When a Path message arrives at the ingress PE (step 3 of Section 2.1) 452 the PE needs to establish suitable Path state and forward the Path 453 message on to the egress PE. In the following paragraphs we 454 described the steps taken by the ingress PE. 456 The Path message is addressed to the eventual destination (the 457 receiver at the remote customer site) and carries the IP router alert 458 option, in accordance with [RFC2205]. The ingress PE MUST recognize 459 the router alert option, intercept these messages and process them as 460 RSVP signaling messages. 462 As noted above, there is an issue in recognizing Path messages as 463 they arrive at the egress PE (PE 2 in Figure 1). The approach 464 defined here is to address the Path messages sent by the ingress PE 465 directly to the egress PE, and send it without IP router alert 466 option; that is, rather than using the ultimate receiver's 467 destination address as the destination address of the Path message, 468 we use the loopback address of the egress PE as the destination 469 address of the Path message. This approach has the advantage that it 470 does not require any new data plane capabilities for the egress PE 471 beyond those of a standard BGP/MPLS VPN PE. Details of the 472 processing of this message at the egress PE are described below in 473 Section 3.3. The approach of addressing a Path message directly to 474 an RSVP next hop (that may or may not be the next IP hop) is already 475 used in other environments such as those of [RFC4206] and [RFC4804]. 477 The details of operation at the ingress PE are as follows. When the 478 ingress PE (PE1 in Figure 1) receives a Path message from CE1 that is 479 addressed to the receiver, the VRF that is associated with the 480 incoming interface is identified, just as for normal data path 481 operations. The Path state for the session is stored, and is 482 associated with that VRF, so that potentially overlapping addresses 483 among different VPNs do not appear to belong to the same session. 484 The destination address of the receiver is looked up in the 485 appropriate VRF, and the BGP Next-Hop for that destination is 486 identified. That next-hop is the egress PE (PE2 in Figure 1). A new 487 VPN-IPv4 SESSION object is constructed, containing the Route 488 Distinguisher (RD) that is part of the VPN-IPv4 route prefix for this 489 destination, and the IPv4 address from the SESSION. In addition, a 490 new VPN-IPv4 SENDER_TEMPLATE object is constructed, with the original 491 IPv4 address from the incoming SENDER_TEMPLATE plus the RD that is 492 used by this PE to advertise that prefix for this customer into the 493 VPN. A new Path message is constructed with a destination address 494 equal to the address of the egress PE identified above. This new 495 Path message will contain all the objects from the original Path 496 message, replacing the original SESSION and SENDER_TEMPLATE objects 497 with the new VPN-IPv4 type objects. The Path message is sent without 498 router alert option and contains a RSVP_HOP object constructed as 499 specified in Section 3.1. 501 3.3. Path Message Processing at Egress PE 503 When a Path message arrives at the egress PE, (step 4 of Section 2.1) 504 it is addressed to the PE itself, and is handed to RSVP for 505 processing. The router extracts the RD and IPv4 address from the 506 VPN-IPv4 SESSION object, and determines the local VRF context by 507 finding a matching VPN-IPv4 prefix with the specified RD that has 508 been advertised by this router into BGP. The entire incoming RSVP 509 message, including the VRF information, is stored as part of the Path 510 state. 512 Now the RSVP module can construct a Path message which differs from 513 the Path it received in the following ways: 515 a. Its destination address is the IP address extracted from the 516 SESSION Object; 518 b. The SESSION and SENDER_TEMPLATE objects are converted back to 519 IPv4-type by discarding the attached RD 521 c. The RSVP_HOP Object contains the IP address of the outgoing 522 interface of the egress PE and a Logical Interface Handle (LIH), 523 as per normal RSVP processing. 525 The router then sends the Path message on towards its destination 526 over the interface identified above. This Path message carries the 527 router alert option as required by [RFC2205]. 529 3.4. Resv Processing at Egress PE 531 When a receiver at the customer site originates a Resv message for 532 the session, normal RSVP procedures apply until the Resv, making its 533 way back towards the sender, arrives at the "egress" PE (step 8 of 534 Section 2.1). Note that this is the "egress" PE with respect to the 535 direction of data flow, i.e. PE2 in figure 1. On arriving at PE2, 536 the SESSION and FILTER_SPEC objects in the Resv, and the VRF in which 537 the Resv was received, are used to find the matching Path state 538 stored previously. At this stage, admission control can be performed 539 on the PE-CE link. 541 Assuming admission control is successful, the PE constructs a Resv 542 message to send to the RSVP HOP stored in the Path state, i.e., the 543 ingress PE (PE1 in Figure 1). The IPv4 SESSION object is replaced 544 with the same VPN-IPv4 SESSION object received in the Path. The IPv4 545 FILTER_SPEC object is replaced with a VPN-IPv4 FILTER_SPEC object, 546 which copies the VPN-IPv4 address from the SENDER_TEMPLATE received 547 in the matching Path message. The RSVP_HOP in the Resv message MUST 548 be constructed as specified in Section 3.1. The Resv message MUST be 549 addressed to the IP address contained within the RSVP_HOP object in 550 the Path message. If the Path message contained a VPN-IPv4 RSVP_HOP 551 object, the Resv MUST be MPLS-encapsulated using the label associated 552 with that VPN-IPv4 address in BGP, as described in Section 3.1. If 553 the Path message contained an IPv4 RSVP_HOP object, the Resv is 554 simply IP-encapsulated and addressed directly to the IP address in 555 the RSVP_HOP object. 557 If admission control is not successful on the egress PE, a ResvError 558 message is sent towards the receiver as per normal RSVP processing. 560 3.5. Resv Processing at Ingress PE 562 Upon receiving a Resv message at the ingress PE (step 8 of 563 Section 2.1) with respect to data flow (i.e. PE1 in Figure 1), the 564 PE determines the local VRF context and associated Path state for 565 this Resv by decoding the received SESSION and FILTER_SPEC objects. 566 It is now possible to generate a Resv message to send to the 567 appropriate CE. The Resv message sent to the ingress CE will contain 568 IPv4 SESSION and FILTER_SPEC objects, derived from the appropriate 569 Path state. Since we assume in this section that admission control 570 over the Provider's backbone is not needed, the ingress PE does not 571 perform any admission control for this reservation. 573 3.6. Other RSVP Messages 575 Processing of PathError, PathTear, ResvError, ResvTear and ResvConf 576 messages is generally straightforward and follows the rules of 577 [RFC2205]. These additional rules MUST be observed for messages 578 transmitted within the VPN (i.e. Between the PEs): 580 o The SESSION, SENDER_TEMPLATE and FILTER_SPEC objects MUST be 581 converted from IPv4 to VPN-IPv4 form and back in the same manner 582 as described above for Path and Resv messages. 584 o The appropriate type of RSVP_HOP object (VPN-IPv4 or IPv4) MUST be 585 used as described above. 587 o Depending on the type of RSVP_HOP object received from the 588 neighbor, the message MUST be MPLS-encapsulated or IP-encapsulated 589 as described above. 591 o The matching state & VRF MUST be determined by decoding the RD and 592 IPv4 addresses in the SESSION and FILTER_SPEC objects. 594 o The message MUST be directly addressed to the appropriate PE, 595 without using the router alert option. 597 4. Admission Control in Provider's Backbone 599 The preceding section outlines how per-customer reservations can be 600 made over the PE-CE links. This may be sufficient in many situations 601 where the backbone is well engineered with ample capacity and there 602 is no need to perform any sort of admission control in the backbone. 603 However, in some cases where excess capacity cannot be relied upon 604 (e.g., during failures or unanticipated periods of overload) it may 605 be desirable to be able to perform admission control in the backbone 606 on behalf of customer traffic. 608 Because of the fact that routes to customer addresses are not present 609 in the P routers, along with the concerns of scalability that would 610 arise if per-customer reservations were allowed in the P routers, it 611 is clearly necessary to map the per-customer reservations described 612 in the preceding section onto some sort of aggregate reservations. 613 Furthermore, customer data packets need to be tunneled across the 614 provider backbone just as in normal BGP/MPLS VPN operation. 616 Given these considerations, a feasible way to achieve the objective 617 of admission control in the backbone is to use the ideas described in 618 [RFC4804]. MPLS-TE tunnels can be established between PEs as a means 619 to perform aggregate admission control in the backbone. 621 An MPLS-TE tunnel from an ingress PE to an egress PE can be thought 622 of as a virtual link of a certain capacity. The main change to the 623 procedures described above is that when a Resv is received at the 624 ingress PE, an admission control decision can be performed by 625 checking whether sufficient capacity of that virtual link remains 626 available to admit the new customer reservation. We note also that 627 [RFC4804] uses the IF_ID RSVP_HOP object to identify the tunnel 628 across the backbone, rather than the simple RSVP_HOP object described 629 in Section 3.2. The procedures of [RFC4804] should be followed here 630 as well. 632 To achieve effective admission control in the backbone, there needs 633 to be some way to separate the data plane traffic that has a 634 reservation from that which does not. We assume that packets that 635 are subject to admission control on the core will be given a 636 particular MPLS EXP value, and that no other packets will be allowed 637 to enter the core with this value unless they have passed admission 638 control. Some fraction of link resources will be allocated to queues 639 on core links for packets bearing that EXP value, and the MPLS-TE 640 tunnels will use that resource pool to make their constraint-based 641 routing and admission control decisions. This is all consistent with 642 the principles of aggregate RSVP reservations described in [RFC3175]. 644 5. Inter-AS operation 646 [RFC4364] defines three modes of inter-AS operation for MPLS/BGP 647 VPNs, referred to as options A, B and C. In the following sections we 648 describe how the scheme described above can operate in each inter-AS 649 environment. 651 5.1. Inter-AS Option A 653 Operation of RSVP in Inter-AS Option A is quite straightforward. 654 Each ASBR operates like a PE, and the ASBR-ASBR links can be viewed 655 as PE-CE links in terms of admission control. If the procedures 656 defined in Section 3 are enabled on both ASBRs, then admission 657 control may be performed on the inter-ASBR links. In addition, the 658 operator of each AS can independently decide whether or not to 659 perform admission control across his backbone. The new objects 660 described in this document MUST NOT be sent in any RSVP message 661 between two Option-A ASBRs. 663 5.2. Inter-AS Option B 665 To support inter-AS Option B, we require some additional processing 666 of RSVP messages on the ASBRs. Recall that, when packets are 667 forwarded from one AS to another in option B, the VPN label is 668 swapped by each ASBR as a packet goes from one AS to another. The 669 BGP next hop seen by the ingress PE will be the ASBR, and there need 670 not be IP visibility between the ingress and egress PEs. Hence when 671 the ingress PE sends the Path message to the BGP next hop of the VPN- 672 IPv4 route towards the destination, it will be received by the ASBR. 673 The ASBR determines the next hop of the route in a similar way as the 674 ingress PE - by finding a matching BGP VPN-IPv4 route with the same 675 RD and a matching prefix. 677 The provider(s) who interconnect ASes using option B may or may not 678 desire to perform admission control on the inter-AS links. This 679 choice affects the detailed operation of ASBRs. We describe the two 680 modes of operation - with and without admission control at the ASBRs 681 - in the following sections. 683 5.2.1. Admission control on ASBR 685 In this scenario, the ASBR performs full RSVP signaling and admission 686 control. The RSVP database is indexed on the ASBR using the VPN-IPv4 687 SESSION, SENDER_TEMPLATE and FILTER_SPEC objects (which uniquely 688 identify RSVP sessions and flows as per the requirements of 689 [RFC2205]). These objects are forwarded unmodified in both 690 directions by the ASBR. All other procedures of RSVP are performed 691 as if the ASBR was a RSVP hop. In particular, the RSVP_HOP objects 692 sent in Path and Resv messages contain IP addresses of the ASBR, 693 which MUST be reachable by the neighbor to whom the message is being 694 sent. Note that since the VPN-IPv4 SESSION, SENDER_TEMPLATE and 695 FILTER_SPEC objects satisfy the uniqueness properties required for a 696 RSVP database implementation as per [RFC2209], no customer VRF 697 awareness is required on the ASBR. 699 5.2.2. No admission control on ASBR 701 If the ASBR is not doing admission control, it is desirable that per- 702 flow state not be maintained on the ASBR. This requires adjacent 703 RSVP hops (i.e. The ingress and egress PEs of the respective ASes) 704 to send RSVP messages directly between them. This is only possible 705 if they are MPLS-encapsulated. The use of the VPN-IPv4 RSVP_HOP 706 object described in Section 3.1 is REQUIRED in this case. 708 When an ASBR that is not installing local RSVP state receives a Path 709 message, it looks up the next-hop of the matching BGP route as 710 described in Section 3.2, and sends the Path message to the next-hop, 711 without modifying any RSVP objects (including the RSVP_HOP). This 712 process is repeated at subsequent ASBRs until the Path message 713 arrives at a router that is installing local RSVP state (either the 714 ultimate egress PE, or an ASBR configured to perform admission 715 control). This router receives the Path and processes it as 716 described in Section 3.3 if it is a PE, or Section 5.2.1 if it is an 717 ASBR performing admission control. When this router sends the Resv 718 upstream, it looks up the routing table for a next-hop+label for the 719 VPN-IPv4 address in the PHOP, encapsulates the Resv with that label 720 and sends it upstream. This message will be received for control 721 processing directly on the upstream RSVP hop (that last updated the 722 RSVP_HOP field in the Path message), without any involvement of 723 intermediate ASBRs. 725 The ASBR is not expected to process any other RSVP messages apart 726 from the Path message as described above. The ASBR also does not 727 need to store any RSVP state. Note that any ASBR along the path that 728 wishes to do admission control or insert itself into the RSVP 729 signaling flow, may do so by writing its own RSVP_HOP object with 730 IPv4 and VPN-IPv4 address pointing to itself. 732 If an Option-B ASBR receives a RSVP Path message with an IPv4 733 RSVP_HOP, does not wish to perform admission control but is willing 734 to install local state for this flow, the ASBR MUST process and 735 forward RSVP signaling messages for this flow as described in 736 Section 5.2.1 (with the exception that it does not perform admission 737 control). If an Option-B ASBR receives a RSVP Path message with an 738 IPv4 RSVP_HOP, but does not wish to install local state or perform 739 admission control for this flow, the ASBR MUST NOT forward the Path 740 message. In addition, the ASBR SHOULD send a PathError message of 741 Error Code "RSVP over MPLS Problem" and Error Value "RSVP_HOP not 742 reachable across VPN" (see Section 9) signifying to the upstream RSVP 743 hop that the supplied RSVP_HOP object is insufficient to provide 744 reachability across this VPN. This failure condition is not expected 745 to be recoverable. 747 5.3. Inter-AS Option C 749 Operation of RSVP in Inter-AS Option C is also quite straightforward, 750 because there exists an LSP directly from ingress PE to egress PE. 751 In this case, there is no significant difference in operation from 752 the single AS case described in Section 3. Furthermore, if it is 753 desired to provide admission control from PE to PE, it can be done by 754 building an inter-AS TE tunnel and then using the procedures 755 described in Section 4. 757 6. Operation with RSVP disabled 759 It is often the case that RSVP will not be enabled on the PE-CE 760 links. In such an environment, a customer may reasonably expect that 761 RSVP messages sent into the L3 VPN network should be forwarded just 762 like any other IP datagrams. This transparency is useful when the 763 customer wishes to use RSVP within his own sites or perhaps to 764 perform admission control on the CE-PE links (in CE->PE direction 765 only), without involvement of the PEs. For this reason, a PE SHOULD 766 NOT discard or modify RSVP messages sent towards it from a CE when 767 RSVP is not enabled on the PE-CE links. Similarly a PE SHOULD NOT 768 discard or modify RSVP messages which are destined for one of its 769 attached CEs, even when RSVP is not enabled on those links. Note 770 that the presence of the router alert option in some RSVP messages 771 may cause them to be forwarded outside of the normal forwarding path, 772 but that the guidance of this paragraph still applies in that case. 773 Note also that this guidance applies regardless of whether RSVP-TE is 774 used in some, all, or none of the L3VPN network. 776 7. Other RSVP procedures 778 This section describes modifications to other RSVP procedures 779 introduced by MPLS VPNs 781 7.1. Refresh overhead reduction 783 The following points ought to be noted regarding RSVP refresh 784 overhead reduction ([RFC2961]) across a MPLS VPN: 786 o The hop between the ingress and egress PE of a VPN is to be 787 considered as traversing one or more non-RSVP hops. As such, the 788 procedures described in Section 5.3 of [RFC2961] relating to non- 789 RSVP hops SHOULD be followed. 791 o The source IP address of a SRefresh message MUST match the IPv4 792 address signalled in the RSVP_HOP object contained in the 793 corresponding Path or Resv message. The IPv4 address in any 794 received VPN-IPv4 RSVP_HOP object MUST be used as the source 795 address of that message for this purpose. 797 7.2. Cryptographic Authentication 799 The following points ought to be noted regarding RSVP cryptographic 800 authentication ([RFC2747]) across a MPLS VPN: 802 o The IPv4 address in any received VPN-IPv4 RSVP_HOP object MUST be 803 used as the source address of that message for purposes of 804 identifying the security association. 806 o Forwarding of Challenge and Response messages MUST follow the same 807 rules as described above for hop-by-hop messages. Specifically, 808 if the originator of a Challenge/Response message has received a 809 VPN-IPv4 RSVP_HOP object from the corresponding neighbor, it MUST 810 use the label associated with that VPN-IPv4 address in BGP to 811 forward the Challenge/Response message. 813 7.3. RSVP Aggregation 815 [RFC3175] and [RFC4860] describe mechanisms to aggregate multiple 816 individual RSVP reservations into a single larger reservation on the 817 basis of a common DSCP/PHB for traffic classification. The following 818 points ought to be noted in this regard: 820 o The procedures described in this section apply only in the case 821 where the Aggregator and Deaggregator nodes are C/CE devices, and 822 the entire MPLS VPN lies within the Aggregation Region. The case 823 where the PE is also an Aggregator/Deaggregator is more complex 824 and not considered in this document. 826 o Support of Aggregate RSVP sessions is OPTIONAL. When supported: 828 * Aggregate RSVP sessions MUST be treated in the same way as 829 regular IPv4 RSVP sessions. To this end, all the procedures 830 described in Section 3 and Section 4 MUST be followed for 831 aggregate RSVP sessions. The corresponding new SESSION, 832 SENDER_TEMPLATE and FILTERSPEC objects are defined in 833 Section 8. 835 * End-To-End (E2E) RSVP sessions are passed unmodified through 836 the MPLS VPN. These RSVP messages SHOULD be identified by 837 their IP protocol (RSVP-E2E-IGNORE, 134). When the ingress PE 838 receives any RSVP message with this IP protocol, it MUST 839 process this frame as if it is regular customer traffic and 840 ignore any router alert option. The appropriate VPN and 841 transport labels are applied to the frame and it is forwarded 842 towards the remote CE. Note that this message will not be 843 received or processed by any other P or PE node. 845 * Any SESSION-OF-INTEREST object (defined in [RFC4860]) MUST be 846 conveyed unmodified across the MPLS VPN. 848 7.4. Support for CE-CE RSVP-TE 850 [I-D.ietf-l3vpn-e2e-rsvp-te-reqts] describes a set of requirements 851 for the establishment for CE-CE MPLS LSPs across networks offering an 852 L3VPN service. The requirements specified in that document are 853 similar to those addressed by this document, in that both address the 854 issue of handling RSVP requests from customers in a VPN context. It 855 is possible that the solution described here could be adapted to meet 856 the requirements of [I-D.ietf-l3vpn-e2e-rsvp-te-reqts]. To the 857 extent that this document uses signaling extensions described in 858 [RFC3473] which have already been used for GMPLS/TE, we expect that 859 CE-CE RSVP/TE will be incremental work built on these extensions. 860 These extensions will be considered in a separate document. 862 8. Object Definitions 864 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects 866 The usage of the VPN-IPv4 (or VPN-IPv6) SESSION Object is described 867 in Section 3.2 to Section 3.6. The VPN-IPv4 (or VPN-IPv6) SESSION 868 object appears in RSVP messages that ordinarily contain a SESSION 869 object and are sent between ingress PE and egress PE in either 870 direction. The object MUST NOT be included in any RSVP messages that 871 are sent outside of the provider's backbone (except in the inter-AS 872 option B and C cases, as described above, when it may appear on 873 inter-AS links). 875 The VPN-IPv6 SESSION object is analogous to the VPN-IPv4 SESSION 876 object, using an VPN-IPv6 address ([RFC4659]) instead of an VPN-IPv4 877 address ([RFC4364]). 879 The formats of the objects are as follows: 881 o VPN-IPv4 SESSION object: Class = 1, C-Type = TBA 883 +-------------+-------------+-------------+-------------+ 884 | | 885 + + 886 | VPN-IPv4 DestAddress (12 bytes) | 887 + + 888 | | 889 +-------------+-------------+-------------+-------------+ 890 | Protocol Id | Flags | DstPort | 891 +-------------+-------------+-------------+-------------+ 893 o VPN-IPv6 SESSION object: Class = 1, C-Type = TBA 895 +-------------+-------------+-------------+-------------+ 896 | | 897 + + 898 | | 899 + VPN-IPv6 DestAddress (24 bytes) + 900 / / 901 . . 902 / / 903 | | 904 +-------------+-------------+-------------+-------------+ 905 | Protocol Id | Flags | DstPort | 906 +-------------+-------------+-------------+-------------+ 908 The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field 909 contains an address of the VPN-IPv4 (respectively VPN-IPv6) address 910 family encoded as specified in [RFC4364] (respectively [RFC4659]). 911 The content of this field is discussed in Section 3.2 and 912 Section 3.3. 914 The protocol ID, flags, and DstPort are identical to the same fields 915 in the IPv4 and IPv6 SESSION objects ([RFC2205]). 917 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects 919 The usage of the VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE Object is 920 described in Section 3.2 and Section 3.3. The VPN-IPv4 (or VPN-IPv6) 921 SENDER_TEMPLATE object appears in RSVP messages that ordinarily 922 contain a SENDER_TEMPLATE object and are sent between ingress PE and 923 egress PE in either direction (such as Path, PathError, and 924 PathTear). The object MUST NOT be included in any RSVP messages that 925 are sent outside of the provider's backbone (except in the inter-AS 926 option B and C cases, as described above, when it may appear on 927 inter-AS links). The format of the object is as follows: 929 o VPN-IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = TBA 931 +-------------+-------------+-------------+-------------+ 932 | | 933 + + 934 | VPN-IPv4 SrcAddress (12 bytes) | 935 + + 936 | | 937 +-------------+-------------+-------------+-------------+ 938 | Reserved | SrcPort | 939 +-------------+-------------+-------------+-------------+ 941 o VPN-IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = TBA 943 +-------------+-------------+-------------+-------------+ 944 | | 945 + + 946 | | 947 + VPN-IPv6 SrcAddress (24 bytes) + 948 / / 949 . . 950 / / 951 | | 952 +-------------+-------------+-------------+-------------+ 953 | Reserved | SrcPort | 954 +-------------+-------------+-------------+-------------+ 956 The VPN-IPv4 SrcAddress (respectively VPN-IPv6 SrcAddress) field 957 contains an address of the VPN-IPv4 (respectively VPN-IPv6) address 958 family encoded as specified in [RFC4364] (respectively [RFC4659]). 959 The content of this field is discussed in Section 3.2 and 960 Section 3.3. 962 The SrcPort is identical to the SrcPort field in the IPv4 and IPv6 963 SENDER_TEMPLATE objects ([RFC2205]). 965 The Reserved field MUST be set to zero on transmit and ignored on 966 receipt. 968 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects 970 The usage of the VPN-IPv4 (or VPN-IPv6) FILTER_SPEC Object is 971 described in Section 3.4 and Section 3.5. The VPN-IPv4 (or VPN-IPv6) 972 FILTER_SPEC object appears in RSVP messages that ordinarily contain a 973 FILTER_SPEC object and are sent between ingress PE and egress PE in 974 either direction (such as Resv, ResvError, and ResvTear). The object 975 MUST NOT be included in any RSVP messages that are sent outside of 976 the provider's backbone (except in the inter-AS option B and C cases, 977 as described above, when it may appear on inter-AS links). 979 o VPN-IPv4 FILTER_SPEC object: Class = 10, C-Type = TBA 981 Definition same as VPN-IPv4 SENDER_TEMPLATE object. 983 o VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = TBA 985 Definition same as VPN-IPv6 SENDER_TEMPLATE object. 987 The content of the VPN-IPv4 SrcAddress (or VPN-IPv6 SrcAddress) field 988 is discussed in Section 3.4 and Section 3.5. 990 The SrcPort is identical to the SrcPort field in the IPv4 and IPv6 991 SENDER_TEMPLATE objects ([RFC2205]). 993 The Reserved field MUST be set to zero on transmit and ignored on 994 receipt. 996 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects 998 Usage of the VPN-IPv4 (or VPN-IPv6) RSVP_HOP Object is described in 999 Section 3.1 and Section 5.2.2. The VPN-IPv4 (VPN-IPv6) RSVP_HOP 1000 object is used to establish signaling reachability between RSVP 1001 neighbors separated by one or more Option-B ASBRs. This object may 1002 appear in RSVP messages that carry a RSVP_HOP object, and that travel 1003 between the Ingress and Egress PEs. It MUST NOT be included in any 1004 RSVP messages that are sent outside of the provider's backbone 1005 (except in the inter-AS option B and C cases, as described above, 1006 when it may appear on inter-AS links). The format of the object is 1007 as follows: 1009 o VPN-IPv4 RSVP_HOP object: Class = 3, C-Type = TBA 1011 +-------------+-------------+-------------+-------------+ 1012 | IPv4 Next/Previous Hop Address (4 bytes) | 1013 +-------------+-------------+-------------+-------------+ 1014 | | 1015 + + 1016 | VPN-IPv4 Next/Previous Hop Address (12 bytes) | 1017 + + 1018 | | 1019 +-------------+-------------+-------------+-------------+ 1020 | Logical Interface Handle | 1021 +-------------+-------------+-------------+-------------+ 1023 o VPN-IPv6 RSVP_HOP object: Class = 3, C-Type = TBA 1025 +-------------+-------------+-------------+-------------+ 1026 | | 1027 + + 1028 | | 1029 + IPv6 Next/Previous Hop Address (16 bytes) + 1030 | | 1031 + + 1032 | | 1033 +-------------+-------------+-------------+-------------+ 1034 | | 1035 + + 1036 | | 1037 + VPN-IPv6 Next/Previous Hop Address (24 bytes) + 1038 / / 1039 . . 1040 / / 1041 | | 1042 +-------------+-------------+-------------+-------------+ 1043 | Logical Interface Handle | 1044 +-------------+-------------+-------------+-------------+ 1046 The IPv4 Next/Previous Hop Address, IPv6 Next/Previous Hop Address 1047 and the Logical Interface Handle fields are identical to those of the 1048 RSVP_HOP object ([RFC2205]). 1050 The VPN-IPv4 Next/Previous Hop Address (respectively VPN-IPv6 Next/ 1051 Previous Hop Address) field contains an address of the VPN-IPv4 1052 (respectively VPN-IPv6) address family encoded as specified in 1053 [RFC4364] (respectively [RFC4659]). The content of this field is 1054 discussed in Section 3.1. 1056 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects 1058 The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SESSION object is 1059 described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively 1060 AGGREGATE-IPv6-VPN) SESSION object appears in RSVP messages that 1061 ordinarily contain a AGGREGATE-IPv4 (respectively AGGREGATE-IPv6) 1062 SESSION object as defined in [RFC3175] and are sent between ingress 1063 PE and egress PE in either direction. The GENERIC-AGGREGATE-VPN-IPv4 1064 (respectively AGGREGATE-VPN-IPv6) SESSION object should appear in all 1065 RSVP messages that ordinarily contain a GENERIC-AGGREGATE-IPv4 1066 (respectively GENERIC-AGGREGATE-IPv6) SESSION object as defined in 1067 [RFC4860] and are sent between ingress PE and egress PE in either 1068 direction. These objects MUST NOT be included in any RSVP messages 1069 that are sent outside of the provider's backbone (except in the 1070 inter-AS option B and C cases, as described above, when it may appear 1071 on inter-AS links). The processing rules for these objects are 1072 otherwise identical to those of the VPN-IPv4 (respectively VPN-IPv6) 1073 SESSION object defined in Section 8.1. The format of the object is 1074 as follows: 1076 o AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = TBA 1078 +-------------+-------------+-------------+-------------+ 1079 | | 1080 + + 1081 | VPN-IPv4 DestAddress (12 bytes) | 1082 + + 1083 | | 1084 +-------------+-------------+-------------+-------------+ 1085 | Reserved | Flags | Reserved | DSCP | 1086 +-------------+-------------+-------------+-------------+ 1088 o AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = TBA 1090 +-------------+-------------+-------------+-------------+ 1091 | | 1092 + + 1093 | | 1094 + VPN-IPv6 DestAddress (24 bytes) + 1095 / / 1096 . . 1097 / / 1098 | | 1099 +-------------+-------------+-------------+-------------+ 1100 | Reserved | Flags | Reserved | DSCP | 1101 +-------------+-------------+-------------+-------------+ 1103 The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field 1104 contains an address of the VPN-IPv4 (respectively VPN-IPv6) address 1105 family encoded as specified in [RFC4364] (respectively [RFC4659]). 1106 The content of this field is discussed in Section 3.2 and 1107 Section 3.3. 1109 The flags and DSCP are identical to the same fields of the AGGREGATE- 1110 IPv4 and AGGREGATE-IPv6 SESSION objects ([RFC3175]). 1112 The Reserved field MUST be set to zero on transmit and ignored on 1113 receipt. 1115 o GENERIC-AGGREGATE-VPN-IPv4 SESSION object: 1116 Class = 1, C-Type = TBA 1118 +-------------+-------------+-------------+-------------+ 1119 | | 1120 + + 1121 | VPN-IPv4 DestAddress (12 bytes) | 1122 + + 1123 | | 1124 +-------------+-------------+-------------+-------------+ 1125 | Reserved | Flags | PHB-ID | 1126 +-------------+-------------+-------------+-------------+ 1127 | Reserved | vDstPort | 1128 +-------------+-------------+-------------+-------------+ 1129 | Extended vDstPort | 1130 +-------------+-------------+-------------+-------------+ 1132 o GENERIC-AGGREGATE-VPN-IPv6 SESSION object: 1133 Class = 1, C-Type = TBA 1135 +-------------+-------------+-------------+-------------+ 1136 | | 1137 + + 1138 | | 1139 + VPN-IPv6 DestAddress (24 bytes) + 1140 / / 1141 . . 1142 / / 1143 | | 1144 +-------------+-------------+-------------+-------------+ 1145 | Reserved | Flags | PHB-ID | 1146 +-------------+-------------+-------------+-------------+ 1147 | Reserved | vDstPort | 1148 +-------------+-------------+-------------+-------------+ 1149 | Extended vDstPort | 1150 +-------------+-------------+-------------+-------------+ 1152 The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field 1153 contains an address of the VPN-IPv4 (respectively VPN-IPv6) address 1154 family encoded as specified in [RFC4364] (respectively [RFC4659]). 1155 The content of this field is discussed in Section 3.2 and 1156 Section 3.3. 1158 The flags, PHB-ID, vDstPort and Extended vDstPort are identical to 1159 the same fields of the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE- 1160 IPv6 SESSION objects ([RFC4860]). 1162 The Reserved field MUST be set to zero on transmit and ignored on 1163 receipt. 1165 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 SENDER_TEMPLATE objects 1167 The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object 1168 is described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively 1169 AGGREGATE-VPN-IPv6) SENDER_TEMPLATE object appears in RSVP messages 1170 that ordinarily contain a AGGREGATE-IPv4 (respectively AGGREGATE- 1171 IPv6) SENDER_TEMPLATE object as defined in [RFC3175] and [RFC4860], 1172 and are sent between ingress PE and egress PE in either direction. 1173 These objects MUST NOT be included in any RSVP messages that are sent 1174 outside of the provider's backbone (except in the inter-AS option B 1175 and C cases, as described above, when it may appear on inter-AS 1176 links). The processing rules for these objects are otherwise 1177 identical to those of the VPN-IPv4 (respectively VPN-IPv6) 1178 SENDER_TEMPLATE object defined in Section 8.2. The format of the 1179 object is as follows: 1181 o AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object: 1182 Class = 11, C-Type = TBA 1184 +-------------+-------------+-------------+-------------+ 1185 | | 1186 + + 1187 | VPN-IPv4 AggregatorAddress (12 bytes) | 1188 + + 1189 | | 1190 +-------------+-------------+-------------+-------------+ 1192 o AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object: 1193 Class = 11, C-Type = TBA 1195 +-------------+-------------+-------------+-------------+ 1196 | | 1197 + + 1198 | | 1199 + VPN-IPv6 AggregatorAddress (24 bytes) + 1200 / / 1201 . . 1202 / / 1203 | | 1204 +-------------+-------------+-------------+-------------+ 1206 The VPN-IPv4 AggregatorAddress (respectively VPN-IPv6 1207 AggregatorAddress) field contains an address of the VPN-IPv4 1208 (respectively VPN-IPv6) address family encoded as specified in 1209 [RFC4364] (respectively [RFC4659]). The content and processing rules 1210 for these objects are similar to those of the VPN-IPv4 1211 SENDER_TEMPLATE object defined in Section 8.2. 1213 The flags and DSCP are identical to the same fields of the AGGREGATE- 1214 IPv4 and AGGREGATE-IPv6 SESSION objects. 1216 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC objects 1218 The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in 1219 Section 7.3. The AGGREGATE-VPN-IPv4 FILTER_SPEC object appears in 1220 RSVP messages that ordinarily contain a AGGREGATE-IPv4 FILTER_SPEC 1221 object as defined in [RFC3175] and [RFC4860], and are sent between 1222 ingress PE and egress PE in either direction. These objects MUST NOT 1223 be included in any RSVP messages that are sent outside of the 1224 provider's backbone (except in the inter-AS option B and C cases, as 1225 described above, when it may appear on inter-AS links). The 1226 processing rules for these objects are otherwise identical to those 1227 of the VPN-IPv4 FILTER_SPEC object defined in Section 8.3. The 1228 format of the object is as follows: 1230 o AGGREGATE-VPN-IPv4 FILTER_SPEC object: 1231 Class = 10, C-Type = TBA 1233 Definition same as AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object. 1235 o AGGREGATE-VPN-IPv6 FILTER_SPEC object: 1236 Class = 10, C-Type = TBA 1238 Definition same as AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object. 1240 9. IANA Considerations 1242 Section 8 defines new objects. Therefore, this document requests 1243 IANA to modify the RSVP parameters registry, 'Class Names, Class 1244 Numbers, and Class Types' subregistry, and: 1246 o assign six new C-Types under the existing SESSION Class (Class 1247 number 1), as suggested below: 1249 Class 1250 Number Class Name Reference 1251 ------ ----------------------- --------- 1253 1 SESSION [RFC2205] 1255 Class Types or C-Types: 1257 .. ... ... 1258 aa VPN-IPv4 [RFCXXXX] 1259 bb VPN-IPv6 [RFCXXXX] 1260 cc AGGREGATE-VPN-IPv4 [RFCXXXX] 1261 dd AGGREGATE-VPN-IPv6 [RFCXXXX] 1262 ee GENERIC-AGGREGATE-VPN-IPv4 [RFCXXXX] 1263 ff GENERIC-AGGREGATE-VPN-IPv6 [RFCXXXX] 1265 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1266 number of this specification. Suggested values: aa-ff=19-24] 1268 o assign four new C-Types under the existing SENDER_TEMPLATE Class 1269 (Class number 11), as suggested below: 1271 Class 1272 Number Class Name Reference 1273 ------ ----------------------- --------- 1275 11 SENDER_TEMPLATE [RFC2205] 1277 Class Types or C-Types: 1279 .. ... ... 1280 aa VPN-IPv4 [RFCXXXX] 1281 bb VPN-IPv6 [RFCXXXX] 1282 cc AGGREGATE-VPN-IPv4 [RFCXXXX] 1283 dd AGGREGATE-VPN-IPv6 [RFCXXXX] 1285 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1286 number of this specification. Suggested values: aa-dd=14-17] 1288 o assign four new C-Types under the existing FILTER_SPEC Class 1289 (Class number 10), as suggested below: 1291 Class 1292 Number Class Name Reference 1293 ------ ----------------------- --------- 1295 10 FILTER_SPEC [RFC2205] 1297 Class Types or C-Types: 1299 .. ... ... 1300 aa VPN-IPv4 [RFCXXXX] 1301 bb VPN-IPv6 [RFCXXXX] 1302 cc AGGREGATE-VPN-IPv4 [RFCXXXX] 1303 dd AGGREGATE-VPN-IPv6 [RFCXXXX] 1305 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1306 number of this specification. Suggested values: aa-dd=14-17] 1308 o assign two new C-Types under the existing RSVP_HOP Class (Class 1309 number 3), as suggested below: 1311 Class 1312 Number Class Name Reference 1313 ------ ----------------------- --------- 1315 3 RSVP_HOP [RFC2205] 1317 Class Types or C-Types: 1319 .. ... ... 1320 aa VPN-IPv4 [RFCXXXX] 1321 bb VPN-IPv6 [RFCXXXX] 1323 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1324 number of this specification. Suggested values: aa-bb=5-6] 1326 In addition, a new PathError code/value is required to identify a 1327 signaling reachability failure and the need for a VPN-IPv4 or VPN- 1328 IPv6 RSVP_HOP object as described in Section 5.2.2. Therefore, this 1329 document requests IANA to modify the RSVP parameters registry, 'Error 1330 Codes and Globally-Defined Error Value Sub-Codes' subregistry, and: 1332 o assign a new Error Code and sub-code, as suggested below: 1334 aa RSVP over MPLS Problem [RFCXXXX] 1336 This Error Code has the following globally-defined Error 1337 Value sub-codes: 1339 1 = RSVP_HOP not reachable across VPN [RFCXXXX] 1341 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1342 number of this specification. Suggested values: aa=34] 1344 10. Security Considerations 1346 [RFC4364] addresses the security considerations of BGP/MPLS VPNs in 1347 general. General RSVP security considerations are discussed in 1348 [RFC2205]. To ensure the integrity of RSVP, the RSVP Authentication 1349 mechanisms defined in [RFC2747] and [RFC3097] SHOULD be supported. 1350 Those protect RSVP message integrity hop-by-hop and provide node 1351 authentication as well as replay protection, thereby protecting 1352 against corruption and spoofing of RSVP messages. 1353 [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of 1354 various keying approaches for RSVP Authentication. First, we note 1355 that the discussion about applicability of group keying to an intra- 1356 provider environment where RSVP hops are not IP hops is relevant to 1357 securing of RSVP among PEs of a given Service Provider deploying the 1358 solution specified in the present document. We note that the RSVP 1359 signaling in MPLS VPN is likely to spread over multiple 1360 administrative domains (e.g. The service provider operating the VPN 1361 service, and the customers of the service). Therefore the 1362 considerations in [I-D.ietf-tsvwg-rsvp-security-groupkeying] about 1363 inter-domain issues are likely to apply. 1365 Since RSVP messages travel through the L3VPN cloud directly addressed 1366 to PE or ASBR routers (without IP router alert option), P routers 1367 remain isolated from RSVP messages signaling customer reservations. 1368 Providers MAY choose to block PEs from sending datagrams with the 1369 router alert option to P routers as a security practice, without 1370 impacting the functionality described herein. 1372 Beyond those general issues, four specific issues are introduced by 1373 this document: resource usage on PEs, resource usage in the provider 1374 backbone, PE route advertisement outside the AS, and signaling 1375 exposure to ASBRs and PEs. We discuss these in turn. 1377 A customer who makes resource reservations on the CE-PE links for his 1378 sites is only competing for link resources with himself, as in 1379 standard RSVP, at least in the common case where each CE-PE link is 1380 dedicated to a single customer. Thus, from the perspective of the 1381 CE-PE links, the present document does not introduce any new security 1382 issues. However, because a PE typically serves multiple customers, 1383 there is also the possibility that a customer might attempt to use 1384 excessive computational resources on a PE (CPU cycles, memory etc.) 1385 by sending large numbers of RSVP messages to a PE. In the extreme 1386 this could represent a form of denial-of-service attack. In order to 1387 prevent such an attack, a PE SHOULD support mechanisms to limit the 1388 fraction of its processing resources that can be consumed by any one 1389 CE or by the set of CEs of a given customer. For example, a PE might 1390 implement a form of rate limiting on RSVP messages that it receives 1391 from each CE. We observe that these security risks and measures 1392 related to PE resource usage are very similar for any control plane 1393 protocol operating between CE and PE (e.g. RSVP, routing, 1394 multicast). 1396 The second concern arises only when the service provider chooses to 1397 offer resource reservation across the backbone, as described in 1398 Section 4. In this case, the concern may be that a single customer 1399 might attempt to reserve a large fraction of backbone capacity, 1400 perhaps with a co-ordinated effort from several different CEs, thus 1401 denying service to other customers using the same backbone. 1402 [RFC4804] provides some guidance on the security issues when RSVP 1403 reservations are aggregated onto MPLS tunnels, which are applicable 1404 to the situation described here. We note that a provider MAY use 1405 local policy to limit the amount of resources that can be reserved by 1406 a given customer from a particular PE, and that a policy server could 1407 be used to control the resource usage of a given customer across 1408 multiple PEs if desired. It is RECOMMENDED that an implementation of 1409 this specification support local policy on the PE to control the 1410 amount of resources that can be reserved by a given customer/CE. 1412 Use of the VPN-IPv4 RSVP_HOP object requires exporting a PE VPN-IPv4 1413 route to another AS, and potentially could allow unchecked access to 1414 remote PEs if those routes were indiscriminately redistributed. 1415 However, as described in Section 3.1, no route which is not within a 1416 customer's VPN should ever be advertised to (or reachable from) that 1417 customer. If a PE uses a local address already within a customer VRF 1418 (like PE-CE link address), it MUST NOT send this address in any RSVP 1419 messages in a different customer VRF. A "control plane" VPN MAY be 1420 created across PEs and ASBRs and addresses in this VPN can be used to 1421 signal RSVP sessions for any customers, but these routes MUST NOT be 1422 advertised to, or made reachable from, any customer. An 1423 implementation of the present document MAY support such operation 1424 using a "control plane" VPN. Alternatively, ASBRs MAY implement the 1425 signaling procedures described in Section 5.2.1, even if admission 1426 control is not required on the inter-AS link, as these procedures do 1427 not require any direct P/PE route advertisement out of the AS. 1429 Finally, certain operations described herein (Section 3) require an 1430 ASBR or PE to receive and locally process a signaling packet 1431 addressed to the BGP next-hop address advertised by that router. 1432 This requirement does not strictly apply to MPLS/BGP VPNs [RFC4364]. 1433 This could be viewed as opening ASBRs and PEs to being directly 1434 addressable by customer devices where they were not open before, and 1435 could be considered a security issue. If a provider wishes to 1436 mitigate this situation, the implementation MAY support the "control 1437 protocol VPN" approach described above. That is, whenever a 1438 signaling message is to be sent to a PE or ASBR, the address of the 1439 router in question would be looked up in the "control protocol VPN", 1440 and the message would then be sent on the LSP that is found as a 1441 result of that lookup. This would ensure that the router address is 1442 not reachable by customer devices. 1444 [RFC4364] mentions use of IPsec both on a CE-CE basis and PE-PE 1445 basis: "Cryptographic privacy is not provided by this architecture, 1446 nor by Frame Relay or ATM VPNs. These architectures are all 1447 compatible with the use of cryptography on a CE-CE basis, if that is 1448 desired. The use of cryptography on a PE-PE basis is for further 1449 study." 1451 The procedures specified in the present document for admission 1452 control on the PE-CE links (Section 3) are compatible with the use of 1453 IPsec on a PE-PE basis. The optional procedures specified in the 1454 present document for admission control in the Service Provider's 1455 backbone (Section 4) are not compatible with the use of IPsec on a 1456 PE-PE basis, since those procedures depend on the use of PE-PE MPLS 1457 TE Tunnels to perform aggregate reservations through the Service 1458 Provider's backbone. 1460 [RFC4923] describes a model for RSVP operation through IPsec 1461 Gateways. In a nutshell, a form of hierarchical RSVP reservation is 1462 used where an RSVP reservation is made for the IPsec tunnel and then 1463 individual RSVP reservations are admitted/aggregated over the tunnel 1464 reservation. This model applies to the case where IPsec is used on a 1465 CE-CE basis. In that situation, the procedures defined in the 1466 present document would simply apply "as is" to the reservation 1467 established for the IPsec tunnel(s). 1469 11. Acknowledgments 1471 Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric 1472 Rosen, Dan Tappan and Lou Berger for their many contributions to 1473 solving the problems described in this document. Thanks to Ferit 1474 Yegenoglu for his useful comments. We also thank Stefan Santesson 1475 Vijay Gurbani and Alexey Melnikov for their review comments. We 1476 thank Richard Woundy for his very thorough review and comments 1477 including those that resulted in additional text discussing scenarios 1478 of admission control reject in the MPLVS VPN cloud. 1480 Appendix A. Alternatives Considered 1482 At this stage a number of alternatives to the approach described 1483 above have been considered. We document some of the approaches 1484 considered here to assist future discussion. None of these has been 1485 shown to improve upon the approach described above, and the first two 1486 seem to have significant drawbacks relative to the approach described 1487 above. 1489 Appendix A.1. GMPLS UNI approach 1491 [RFC4208] defines the GMPLS UNI. In Section 7 the operation of the 1492 GMPLS UNI in a VPN context is briefly described. This is somewhat 1493 similar to the problem tackled in the current document. The main 1494 difference is that the GMPLS UNI is primarily aimed at the problem of 1495 allowing a CE device to request the establishment of an LSP across 1496 the network on the other side of the UNI. Hence the procedures in 1497 [RFC4208] would lead to the establishment of an LSP across the VPN 1498 provider's network for every RSVP request received, which is not 1499 desired in this case. 1501 To the extent possible, the approach described in this document is 1502 consistent with [RFC4208], while filling in more of the details and 1503 avoiding the problem noted above. 1505 Appendix A.2. VRF label approach 1507 Another approach to solving the problems described here involves the 1508 use of label switching to ensure that Path, Resv, and other RSVP 1509 messages are directed to the appropriate VRF. One challenge with 1510 such an approach is that [RFC4364] does not require labels to be 1511 allocated for VRFs, only for customer prefixes, and that there is no 1512 simple, existing method for advertising the fact that a label is 1513 bound to a VRF. If, for example, an ingress PE sent a Path message 1514 labelled with a VPN label that was advertised by the egress PE for 1515 the prefix that matches the destination address in the Path, there is 1516 a risk that the egress PE would simply label-switch the Path directly 1517 on to the CE without performing RSVP processing. 1519 A second challenge with this approach is that an IP address needs to 1520 be associated with a VRF and used as the PHOP address for the Path 1521 message sent from ingress PE to egress PE. That address needs to be 1522 reachable from the egress PE, and to exist in the VRF at the ingress 1523 PE. Such an address is not always available in today's deployments, 1524 so this represents at least a change to existing deployment 1525 practices. 1527 Appendix A.3. VRF label plus VRF address approach 1529 It is possible to create an approach based on that described in the 1530 previous section which addresses the main challenges of that 1531 approach. The basic approach has two parts: (a) define a new BGP 1532 Extended Community to tag a route (and its associated MPLS label) as 1533 pointing to a VRF; (b) allocate a "dummy" address to each VRF, 1534 specifically to be used for routing RSVP messages. The dummy address 1535 (which could be anything, e.g. a loopback of the associated PE) would 1536 be used as a PHOP for Path messages and would serve as the 1537 destination for Resv messages but would not be imported into VRFs of 1538 any other PE. 1540 12. References 1542 12.1. Normative References 1544 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 1545 February 1997. 1547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1548 Requirement Levels", BCP 14, RFC 2119, March 1997. 1550 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1551 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1552 Functional Specification", RFC 2205, September 1997. 1554 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1555 RFC 2711, October 1999. 1557 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 1558 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 1559 RFC 3175, September 2001. 1561 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1562 Networks (VPNs)", RFC 4364, February 2006. 1564 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1565 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1566 IPv6 VPN", RFC 4659, September 2006. 1568 [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation 1569 Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", 1570 RFC 4804, February 2007. 1572 12.2. Informative References 1574 [I-D.ietf-intarea-router-alert-considerations] 1575 Faucheur, F., "IP Router Alert Considerations and Usage", 1576 draft-ietf-intarea-router-alert-considerations-00 (work in 1577 progress), March 2010. 1579 [I-D.ietf-l3vpn-e2e-rsvp-te-reqts] 1580 Kumaki, K., Kamite, Y., and R. Zhang, "Requirements for 1581 supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP- 1582 VPN", draft-ietf-l3vpn-e2e-rsvp-te-reqts-05 (work in 1583 progress), December 2009. 1585 [I-D.ietf-mpls-ip-options] 1586 Jaeger, W., Mullooly, J., Scholl, T., and D. Smith, 1587 "Requirements for Label Edge Router Forwarding of IPv4 1588 Option Packets", draft-ietf-mpls-ip-options-03 (work in 1589 progress), January 2010. 1591 [I-D.ietf-nsis-ntlp] 1592 Schulzrinne, H. and M. Stiemerling, "GIST: General 1593 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 1594 (work in progress), June 2009. 1596 [I-D.ietf-nsis-qos-nslp] 1597 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 1598 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 1599 (work in progress), January 2010. 1601 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 1602 Behringer, M. and F. Faucheur, "Applicability of Keying 1603 Methods for RSVP Security", 1604 draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in 1605 progress), June 2009. 1607 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1608 Services in the Internet Architecture: an Overview", 1609 RFC 1633, June 1994. 1611 [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol 1612 (RSVP) -- Version 1 Message Processing Rules", RFC 2209, 1613 September 1997. 1615 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1616 Services", RFC 2210, September 1997. 1618 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1619 Authentication", RFC 2747, January 2000. 1621 [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., 1622 and A. Sastry, "The COPS (Common Open Policy Service) 1623 Protocol", RFC 2748, January 2000. 1625 [RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., 1626 and A. Sastry, "COPS usage for RSVP", RFC 2749, 1627 January 2000. 1629 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1630 and S. Molendini, "RSVP Refresh Overhead Reduction 1631 Extensions", RFC 2961, April 2001. 1633 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 1634 Authentication -- Updated Message Type Value", RFC 3097, 1635 April 2001. 1637 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1638 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1639 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1641 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1642 Hierarchy with Generalized Multi-Protocol Label Switching 1643 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 1645 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1646 "Generalized Multiprotocol Label Switching (GMPLS) User- 1647 Network Interface (UNI): Resource ReserVation Protocol- 1648 Traffic Engineering (RSVP-TE) Support for the Overlay 1649 Model", RFC 4208, October 2005. 1651 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 1652 Davenport, "Generic Aggregate Resource ReSerVation 1653 Protocol (RSVP) Reservations", RFC 4860, May 2007. 1655 [RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling 1656 in a Nested Virtual Private Network", RFC 4923, 1657 August 2007. 1659 Authors' Addresses 1661 Bruce Davie 1662 Cisco Systems, Inc. 1663 1414 Mass. Ave. 1664 Boxborough, MA 01719 1665 USA 1667 Email: bsd@cisco.com 1669 Francois le Faucheur 1670 Cisco Systems, Inc. 1671 Village d'Entreprise Green Side - Batiment T3 1672 400, Avenue de Roumanille 1673 Biot Sophia-Antipolis 06410 1674 France 1676 Email: flefauch@cisco.com 1678 Ashok Narayanan 1679 Cisco Systems, Inc. 1680 1414 Mass. Ave. 1681 Boxborough, MA 01719 1682 USA 1684 Email: ashokn@cisco.com