idnits 2.17.1 draft-davie-tsvwg-rsvp-l3vpn-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1345. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2008) is 5904 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) == Unused Reference: 'RFC3032' is defined on line 1250, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 1258, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 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: August 28, 2008 Cisco Systems, Inc. 6 February 25, 2008 8 Support for RSVP in Layer 3 VPNs 9 draft-davie-tsvwg-rsvp-l3vpn-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 28, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 RFC 4364 and RFC 4659 define an approach to building provider- 43 provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to 44 use RSVP to perform admission control on the links between CE and PE 45 routers. This document specifies procedures by which RSVP messages 46 travelling from CE to CE across an L3VPN may be appropriately handled 47 by PE routers so that admission control can be performed on PE-CE 48 links. Optionally, admission control across the provider's backbone 49 may also be supported. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [RFC2119]. 57 Change history 59 [_Note to RFC Editor: This section to be removed before publication_] 61 Changes in this version (draft-davie-tsvwg-rsvp-l3vpn-02) relative to 62 the last (draft-davie-tsvwg-rsvp-l3vpn-01): 64 o The SESSION, SENDER_TEMPLATE and FILTER_SPEC objects have been 65 modified to carry VPN-IPv4 (or VPN-IPv6) addresses instead of IPv4 66 (or IPv6) addresses within the MPLS VPN. 68 o The VRF_ID and VPN_LABEL objects have been removed. The VPN-IPv4 69 addresses in the objects listed in the previous bullet have 70 replaced the VRF_ID and VPN_LABEL for the purposes of state 71 disambiguation and message forwarding. 73 o The requirement for Option-B ASBRs to do CAC has been lifted. A 74 new VPN-IPv4 HOP object has been proposed to optionally provide 75 RSVP signalling reachability across Option-B ASBRs. 77 o Mechanisms for supporting aggregate RSVP sessions across MPLS VPNs 78 have been added. 80 o Explicit support for IPv6 VPNs has been added. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 86 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 87 2.1. Model of Operation . . . . . . . . . . . . . . . . . . . . 6 88 3. Admission Control on PE-CE Links . . . . . . . . . . . . . . . 7 89 3.1. Path Message Processing at Ingress PE . . . . . . . . . . 8 90 3.2. Path Message Processing at Egress PE . . . . . . . . . . . 9 91 3.3. Resv Processing at Egress PE . . . . . . . . . . . . . . . 9 92 3.4. Resv Processing at Ingress PE . . . . . . . . . . . . . . 10 93 3.5. Other RSVP Messages . . . . . . . . . . . . . . . . . . . 10 94 4. Admission Control in Provider's Backbone . . . . . . . . . . . 11 95 5. Inter-AS operation . . . . . . . . . . . . . . . . . . . . . . 12 96 5.1. Inter-AS Option A . . . . . . . . . . . . . . . . . . . . 12 97 5.2. Inter-AS Option B . . . . . . . . . . . . . . . . . . . . 12 98 5.2.1. Admission control on ASBR . . . . . . . . . . . . . . 12 99 5.2.2. No admission control on ASBR . . . . . . . . . . . . . 13 100 5.3. Inter-AS Option C . . . . . . . . . . . . . . . . . . . . 14 101 6. Operation with RSVP disabled . . . . . . . . . . . . . . . . . 14 102 7. Other RSVP procedures . . . . . . . . . . . . . . . . . . . . 15 103 7.1. Refresh overhead reduction . . . . . . . . . . . . . . . . 15 104 7.2. Cryptographic Authentication . . . . . . . . . . . . . . . 15 105 7.3. RSVP Aggregation . . . . . . . . . . . . . . . . . . . . . 16 106 7.4. Support for CE-CE RSVP-TE . . . . . . . . . . . . . . . . 16 107 8. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 16 108 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . . . . . . 17 109 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects . . . . . . 18 110 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects . . . . . . . . 19 111 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects . . . . . . . . . . 20 112 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . 21 113 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 114 SENDER_TEMPLATE objects . . . . . . . . . . . . . . . . . 23 115 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC 116 objects . . . . . . . . . . . . . . . . . . . . . . . . . 25 117 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 118 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 119 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 120 Appendix A. Alternatives Considered . . . . . . . . . . . . . . 27 121 Appendix A.1. GMPLS UNI approach . . . . . . . . . . . . . . . . . 27 122 Appendix A.2. VRF label approach . . . . . . . . . . . . . . . . . 27 123 Appendix A.3. VRF label plus VRF address approach . . . . . . . . 28 124 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 125 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 126 12.2. Informative References . . . . . . . . . . . . . . . . . . 28 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 128 Intellectual Property and Copyright Statements . . . . . . . . . . 31 130 1. Introduction 132 [RFC4364] and [RFC4659] define a Layer 3 VPN service known as BGP/ 133 MPLS VPNs for IPv4 and for IPv6 respectively. [RFC2205] defines the 134 Resource Reservation Protocol (RSVP) which may be used to perform 135 admission control as part of the Integrated Services (int-serv) 136 architecture [RFC1633][RFC2210]. 138 Customers of a layer 3 VPN service may run RSVP for the purposes of 139 admission control in their own networks. Since the links between 140 Provider Edge (PE) and Customer Edge (CE) routers in a layer 3 VPN 141 may often be resource constrained, it may be desirable to be able to 142 perform admission control over those links. In order to perform 143 admission control using RSVP in such an environment, it is necessary 144 that RSVP control messages, such as Path messages and Resv messages, 145 are appropriately handled by the PE routers. This presents a number 146 of challenges in the context of BGP/MPLS VPNs: 148 o RSVP Path message processing depends on routers recognizing the 149 router alert option in the IP header. However, packets traversing 150 the backbone of a BGP/MPLS VPN are MPLS encapsulated and thus the 151 router alert option is not normally visible to the egress PE. 153 o BGP/MPLS VPNs support non-unique addressing of customer networks. 154 Thus a PE at the ingress or egress of the provider backbone may be 155 called upon to process Path messages from different customer VPNs 156 with non-unique destination addresses. 158 o A PE at the ingress of the provider's backbone may receive Resv 159 messages corresponding to different customer VPNs from other PEs, 160 and needs to be able to associate those Resv messages with the 161 appropriate customer VPNs. 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 NSIS [RFC4080]. 168 Additionally, it may be desirable to perform admission control over 169 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) must also be addressed. This 175 draft also specifies procedures for supporting such a scenario. 177 This draft 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 For the PE-CE link subproblem, the most basic challenge is that RSVP 211 control messages contain IP addresses that are drawn from the 212 customer's address space, and PEs must be able to deal with traffic 213 from many customers who may have non-unique (or overlapping) address 214 spaces. Thus, it is essential that a PE be able in all cases to 215 identify the correct VPN context in which to process an RSVP control 216 message. Much of this draft deals with this issue. 218 For the case of making reservations across the provider backbone, we 219 observe that BGP/MPLS VPNs do not create any per-customer forwarding 220 state in the P (provider core) routers. Thus, in order to make 221 reservations on behalf of customer-specified flows, it is clearly 222 necessary to make some sort of aggregated reservation from PE-PE and 223 then map individual, customer-specific reservations onto an aggregate 224 reservation. That is similar to the problem tackled in [RFC3175] and 226 [RFC4804], with the additional complications of handling customer- 227 specific addressing associated with BGP/MPLS VPNs. 229 Finally, we note that RSVP Path messages are normally addressed to 230 the destination of a session, and contain the router alert IP option. 231 Routers along the path to the destination that are configured to 232 process RSVP messages must detect the presence of the router alert 233 option to allow them to intercept Path messages. However, the egress 234 PEs of a network supporting BGP/MPLS VPNs receive packets destined 235 for customer sites as MPLS-encapsulated packets, and may forward 236 those based only on examination of the MPLS label. Hence, a Path 237 message would be forwarded without examination of the IP options and 238 would therefore not receive appropriate processing at the PE. This 239 problem of recognizing and processing Path messages is also discussed 240 below. 242 2.1. Model of Operation 244 Figure 1 illustrates the basic model of operation with which this 245 document is concerned. 247 -------------------------- 248 / Provider \ 249 |----| | Backbone | |----| 250 Sender->| CE1| |-----| |-----| |CE2 |->Receiver 251 | |--| | |---| |---| | |---| | 252 |----| | | | P | | P | | | |----| 253 | PE1 |---| |-----| |-----| PE2 | 254 | | | | | | | | 255 | | |---| |---| | | 256 |-----| |-----| 257 | | 258 \ / 259 -------------------------- 261 Figure 1. Model of Operation for RSVP-based admission control over 262 MPLS/BGP VPN 264 To establish a unidirectional reservation for a point-to-point flow 265 from Sender to Receiver that takes account of resource availability 266 on the CE-PE and PE-CE links only, the following steps must take 267 place: 269 1. Sender sends a Path message to an IP address of the Receiver. 271 2. Path message is processed by CE1 using normal RSVP procedures 272 and forwarded towards the Receiver along the link CE1-PE1. 274 3. PE1 processes Path message and forwards towards the Receiver 275 across the provider backbone. 277 4. PE2 processes Path message and forwards towards the Receiver 278 along link PE2-CE2. 280 5. CE2 processes Path message using normal RSVP procedures and 281 forwards towards Receiver. 283 6. Receiver sends Resv message to CE2. 285 7. CE2 sends Resv message to PE2. 287 8. PE2 processes Resv message (including performing admission 288 control on link PE2-CE2) and sends Resv to PE1. 290 9. PE1 processes Resv message and sends Resv to CE1. 292 10. CE1 processes Resv using normal RSVP procedures, performs 293 admission control on the link CE1-PE1 and sends Resv message to 294 Sender if successful. 296 In each of the steps involving Resv messages (6 through 10) the node 297 sending the Resv uses the previously established Path state to 298 determine the "RSVP Previous Hop (PHOP)" and sends a Resv message to 299 that address. We note that establishing that Path state correctly at 300 PEs is one of the challenges posed by the BGP/MPLS environment. 302 3. Admission Control on PE-CE Links 304 In the following sections we trace through the steps outlined in 305 Section 2.1 and expand on the details for those steps where standard 306 RSVP procedures need to be extended or modified to support the BGP/ 307 MPLS VPN environment. For all the remaining steps described in the 308 preceding section, standard RSVP processing rules apply. 310 All the procedures described below support both IPv4 and IPv6 311 addressing. In all cases where IPv4 is referenced, IPv6 can be 312 substituted with identical procedures and results. Object 313 definitions for both IPv4 and IPv6 are provided in Section 8. 315 3.1. Path Message Processing at Ingress PE 317 When a Path message arrives at the ingress PE (step 3 of Section 2.1) 318 the PE needs to establish suitable Path state and forward the Path 319 message on to the egress PE. In the following paragraphs we 320 described the steps taken by the ingress PE. 322 The Path message is addressed to the eventual destination (the 323 receiver at the remote customer site) and carries the IP Router Alert 324 option, in accordance with [RFC2205]. The ingress PE must recognize 325 the router alert, intercept these messages and process them as RSVP 326 signalling messages. 328 As noted above, there is an issue in recognizing Path messages as 329 they arrive at the egress PE (PE 2 in Figure 1). The approach 330 defined here is to address the Path messages sent by the ingress PE 331 directly to the egress PE; that is, rather than using the ultimate 332 receiver's destination address as the destination address of the Path 333 message, we use the loopback address of the egress PE as the 334 destination address of the Path message. This approach has the 335 advantage that it does not require any new data plane capabilities 336 for the egress PE beyond those of a standard BGP/MPLS VPN PE. 337 Details of the processing of this message at the egress PE are 338 described below in Section 3.2. The approach of addressing a Path 339 message directly to an RSVP next hop that is not the next IP hop is 340 already used in other environments such as those of [RFC4206] and 341 [RFC4804]. 343 For an RSVP Path message, the existing SESSION and SENDER_TEMPLATE 344 objects can no longer uniquely identify a flow on VPN PE nodes. We 345 propose a new format of SESSION and SENDER_TEMPLATE objects which 346 contain a VPN-IPv4 format address. The ingress and egress PE nodes 347 translate between the regular IPv4 addresses for messages to and from 348 the CE, and VPN-IPv4 addresses for messages to and from PE routers. 350 The details of operation at the ingress PE are as follows. When the 351 ingress PE (PE1 in Figure 1) receives a Path message from CE1 that is 352 addressed to the receiver, the VRF that is associated with the 353 incoming interface is identified, just as for normal data path 354 operations. The Path state for the session is stored, and is 355 associated with that VRF, so that potentially overlapping addresses 356 among different VPNs do not appear to belong to the same session. 357 The destination address of the receiver is looked up in the 358 appropriate VRF, and the BGP Next-Hop for that destination is 359 identified. That next-hop is the egress PE (PE2 in Figure 1). A new 360 VPN-IPv4 SESSION object is constructed, containing the Route 361 Distinguisher (RD) that is part of the VPN-IPv4 route prefix for this 362 destination, and the IPv4 address from the SESSION. In addition, a 363 new VPN-IPv4 SENDER_TEMPLATE object is constructed, with the original 364 IPv4 address from the incoming SENDER_TEMPLATE plus the RD that is 365 used by this PE to advertise that prefix for this customer into the 366 VPN. A new Path message is constructed with a destination address 367 equal to the address of the egress PE identified above. This new 368 Path message will contain all the objects from the original Path 369 message, replacing the original SESSION and SENDER_TEMPLATE objects 370 with the new VPN-IPv4 type objects. The RSVP_HOP object in the Path 371 message contains an IP address of the ingress PE. 373 3.2. Path Message Processing at Egress PE 375 When a Path message arrives at the egress PE, it is addressed to the 376 PE itself, and is handed to RSVP for processing. The router extracts 377 the RD and IPv4 address from the VPN-IPv4 SESSION object, and 378 determines the local VRF context by finding a matching VPN-IPv4 379 prefix with the specified RD that has been advertised by this router 380 into BGP. The entire incoming RSVP message, including the VRF 381 information, is stored as part of the Path state. 383 Now the RSVP module can construct a Path message which differs from 384 the Path it received in the following ways: 386 a. Its destination address is the IP address extracted from the 387 SESSION Object; 389 b. The SESSION and SENDER_TEMPLATE objects are converted back to 390 IPv4-type by discarding the attached RD 392 c. The RSVP_HOP Object contains the IP address of the outgoing 393 interface of the egress PE and an LIH, as per normal RSVP 394 processing. 396 The router then sends the Path message on towards its destination 397 over the interface identified above. This Path message carries the 398 IP Router-Alert option as required by [RFC2205]. 400 3.3. Resv Processing at Egress PE 402 When a receiver at the customer site originates a Resv message for 403 the session, normal RSVP procedures apply until the Resv, making its 404 way back towards the sender, arrives at the "egress" PE (it is 405 "egress" with respect to the direction of data flow, i.e. PE2 in 406 figure 1). On arriving at PE2, the SESSION and FILTER_SPEC objects 407 in the Resv, and the VRF in which the Resv was received, are used to 408 find the matching Path state stored previously. At this stage, 409 admission control can be performed on the PE-CE link. 411 Assuming admission control is successful, the PE constructs a Resv 412 message to send to the RSVP HOP stored in the Path state, i.e., the 413 ingress PE (PE1 in Figure 1). The IPv4 SESSION object is replaced 414 with the same VPN-IPv4 SESSION object received in the Path. The IPv4 415 FILTER_SPEC object is replaced with a VPN-IPv4 FILTER_SPEC object, 416 which copies the VPN-IPv4 address from the SENDER_TEMPLATE received 417 in the matching Path message. The RSVP_HOP in the Resv message 418 contains an IP address of the Egress PE that is reachable by the 419 ingress PE. The Resv message is sent to the IP address contained 420 within the RSVP_HOP object in the Path message. 422 If admission control is not successful, a ResvError message is sent 423 towards the receiver as per normal RSVP processing. 425 3.4. Resv Processing at Ingress PE 427 Upon receiving a Resv message at the ingress PE (with respect to data 428 flow, i.e. PE1 in Figure 1), the PE determines which VRF the session 429 is associated with by decoding the RD and IPv4 address in the 430 received FILTER_SPEC. It is now possible to locate the appropriate 431 Path state for the reservation, and generate a Resv message to send 432 to the appropriate CE. The Resv message sent to the ingress CE will 433 contain IPv4 SESSION and FILTER_SPEC objects, derived from the 434 appropriate Path state. Since we assume in this section that 435 admission control over the Provider's backbone is not needed, the 436 ingress PE does not perform any admission control for this 437 reservation. 439 3.5. Other RSVP Messages 441 Processing of PathError, PathTear, ResvError, ResvTear and ResvConf 442 messages is generally straightforward and follows the rules of 443 [RFC2205]. These additional rules must be observed for messages 444 transmitted within the VPN (i.e. between the PEs): 446 o The SESSION, SENDER_TEMPLATE and FILTER_SPEC objects must be 447 converted from IPv4 to VPN-IPv4 form and back in the same manner 448 as described above for Path and Resv messages. 450 o The matching state & VRF must be determined by decoding the RD and 451 IPv4 addresses in the SESSION and FILTER_SPEC objects. 453 o The message must be directly addressed to the appropriate PE, 454 without using the IP Router Alert option. 456 4. Admission Control in Provider's Backbone 458 The preceding section outlines how per-customer reservations can be 459 made over the PE-CE links. This may be sufficient in many situations 460 where the backbone is well engineered with ample capacity and there 461 is no need to perform any sort of admission control in the backbone. 462 However, in some cases where excess capacity cannot be relied upon 463 (e.g., during failures or unanticipated periods of overload) it may 464 be desirable to be able to perform admission control in the backbone 465 on behalf of customer traffic. 467 Because of the fact that routes to customer addresses are not present 468 in the P routers, along with the concerns of scalability that would 469 arise if per-customer reservations were allowed in the P routers, it 470 is clearly necessary to map the per-customer reservations described 471 in the preceding section onto some sort of aggregate reservations. 472 Furthermore, customer data packets need to be tunneled across the 473 provider backbone just as in normal BGP/MPLS VPN operation. 475 Given these considerations, a feasible way to achieve the objective 476 of admission control in the backbone is to use the ideas described in 477 [RFC4804]. MPLS-TE tunnels can be established between PEs as a means 478 to perform aggregate admission control in the backbone. 480 An MPLS-TE tunnel from an ingress PE to an egress PE can be thought 481 of as a virtual link of a certain capacity. The main change to the 482 procedures described above is that when a Resv is received at the 483 ingress PE, an admission control decision can be performed by 484 checking whether sufficient capacity of that virtual link remains 485 available to admit the new customer reservation. We note also that 486 [RFC4804] uses the IF_ID RSVP_HOP object to identify the tunnel 487 across the backbone, rather than the simple RSVP_HOP object described 488 in Section 3.1. The procedures of [RFC4804] should be followed here 489 as well. 491 To achieve effective admission control in the backbone, there needs 492 to be some way to separate the data plane traffic that has a 493 reservation from that which does not. We assume that packets that 494 are subject to admission control on the core will be given a 495 particular MPLS EXP value, and that no other packets will be allowed 496 to enter the core with this value unless they have passed admission 497 control. Some fraction of link resources will be allocated to queues 498 on core links for packets bearing that EXP value, and the MPLS-TE 499 tunnels will use that resource pool to make their constraint-based 500 routing and admission control decisions. This is all consistent with 501 the principles of aggregate RSVP reservations described in [RFC3175]. 503 5. Inter-AS operation 505 [RFC4364] defines three modes of inter-AS operation for MPLS/BGP 506 VPNs, referred to as options A, B and C. In the following sections we 507 describe how the scheme described above can operate in each inter-AS 508 environment. 510 5.1. Inter-AS Option A 512 Option A is quite straightforward. Each ASBR operates like a PE, and 513 the ASBR-ASBR links can be viewed as PE-CE links in terms of 514 admission control. If the procedures defined in Section 3 are 515 enabled on both ASBRs, then CAC may be performed on the inter-ASBR 516 links. In addition, the operator of each AS can independently decide 517 whether or not to perform CAC across his backbone. The new objects 518 described in this document MUST NOT be sent in any RSVP message 519 between two Option-A ASBRs. 521 5.2. Inter-AS Option B 523 To support inter-AS Option B, we require some additional processing 524 of RSVP messages on the ASBRs. Recall that, when packets are forward 525 from one AS to another in option B, the VPN label is swapped by each 526 ASBR as a packet goes from one AS to another. The BGP next hop seen 527 by the ingress PE will be the ASBR, and there need not be IP 528 visibility between the ingress and egress PEs. Hence when the 529 ingress PE sends the Path message to the BGP next hop of the VPN-IPv4 530 route towards the destination, it will be received by the ASBR. The 531 ASBR determines the next hop of the route in a similar way as the 532 ingress PE - by finding a matching BGP VPN-IPv4 route with the same 533 RD and a matching prefix. 535 The provider(s) who interconnect ASes using option B may or may not 536 desire to perform admission control on the inter-AS links. This 537 choice affects the detailed operation of ASBRs. We describe the two 538 modes of operation - with and without admission control at the ASBRs 539 - in the following sections. 541 5.2.1. Admission control on ASBR 543 In this scenario, the ASBR performs full RSVP signalling and 544 admission control. The RSVP database is indexed on the ASBR using 545 the VPN-IPv4 SESSION, SENDER_TEMPLATE and FILTER_SPEC objects (which 546 uniquely identify RSVP sessions and flows as per the requirements of 547 [RFC2205]). These objects are forwarded unmodified in both 548 directions by the ASBR. All other procedures of RSVP are performed 549 as if the ASBR was a RSVP hop. In particular, the RSVP_HOP objects 550 sent in Path and Resv messages contain IP addresses of the ASBR, 551 which MUST be reachable by the neighbor to whom the message is being 552 sent. Note that since the VPN-IPv4 SESSION, SENDER_TEMPLATE and 553 FILTER_SPEC objects satisfy the uniqueness properties required for a 554 RSVP database implementation as per [RFC2209], no customer VRF 555 awareness is required on the ASBR. 557 5.2.2. No admission control on ASBR 559 If the ASBR is not doing admission control, it is desirable that per- 560 flow state not be maintained on the ASBR. This requires adjacent 561 RSVP hops (i.e. the ingress and egress PEs of the respective ASes) to 562 send RSVP messages directly between them. Not however that such 563 routers in an Option B environment are not required to have direct IP 564 reachability to each other. To mitigate this issue, we propose the 565 use of label switching to forward RSVP messages from a PE in one AS 566 to a PE in another AS. A detailed description of how this is 567 achieved follows. 569 We first define a new VPN-IPv4 RSVP_HOP object. Use of the VPN-IPv4 570 RSVP_HOP object enables RSVP control plane reachability between any 571 two adjacent RSVP hops in a MPLS VPN, regardless of whether they have 572 IP reachability. RSVP nodes sending Path or Resv messages across a 573 MPLS VPN MAY use the VPN-IPv4 PHOP object to achieve signalling 574 across Option-B ASBRs without requiring the ASBRs to install state. 576 The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message 577 sender and a logical interface handle as before, but in addition 578 carries a VPN-IPv4 address which also represents the sender of the 579 message. The message sender MUST also advertise this VPN-IPv4 HOP 580 address into BGP with an associated label, and this advertisement 581 MUST be propagated by BGP throughout the VPN and to adjacent ASes in 582 order to provide reachability to this PE. Frames received by the PE 583 marked with this label MUST be given to the local control plane for 584 processing. This VPN-IPv4 address may be created specially for this 585 task, or may represent any VRF, or may be any previously-advertised 586 address (e.g. local PE-CE link address). In the case where the 587 address is specially created for control protocols, the BGP 588 advertisement SHOULD be marked such that this address is not 589 redistributed outside the MPLS VPN (e.g. by using a special route 590 target not imported into customer VRFs). 592 When the upstream RSVP hop sends a Path message to the ASBR, the ASBR 593 looks up the next-hop of a matching BGP route as described 594 inSection 3.1, and sends the Path message to the next-hop, without 595 modifying any RSVP objects (including the RSVP_HOP). The downstream 596 RSVP hop receives the Path and processes it as described in 597 Section 3.2. When sending the Resv upstream, the downstream RSVP hop 598 queries BGP for a next-hop+label for the VPN-IPv4 address in the 599 PHOP, encapsulates the Resv with that label and sends it upstream. 600 This message will be received for control processing directly on the 601 RSVP hop upstream of the ASBR. Further, in the RSVP_HOP object 602 contained in the Resv, the downstream hop MUST include a VPN-IPv4 603 address advertised by itself into BGP with a label, so that hop-by- 604 hop messages in the downstream direction (e.g. ResvError) can be 605 sent directly to it. Note that the VPN-IPv4 address is only used to 606 identify a LSP for neighbor reachability. The IPv4 address in the 607 RSVP_HOP object is used for all other purposes, including neighbor 608 matching between Path/Resv and SRefresh messages ([RFC2961]), 609 authentication ([RFC2747]), etc. 611 The ASBR is not expected to process any other RSVP messages apart 612 from the Path message as described above. The ASBR also does not 613 need to store any RSVP state. Note that any ASBR along the path that 614 wishes to do admission control or insert itself into the RSVP 615 signalling flow, may do so by writing its own RSVP_HOP object with 616 IPv4 and VPN-IPv4 address pointing to itself. 618 If an Option-B ASBR receives a RSVP Path message with an IPv4 type 619 PHOP, but does not wish to install local state or perform admission 620 control for this flow, the ASBR MUST NOT forward the Path message. 621 In addition, the ASBR SHOULD send a PathError message of Error Code 622 [_TBD_], Error Value [_TBD_], signifying to the upstream RSVP hop 623 that the supplied PHOP object is insufficient to provide reachability 624 across this VPN. The upstream node, on receipt of this PathError, 625 SHOULD re-send the Path message including a RSVP_HOP of VPN-IPv4 626 type. 628 5.3. Inter-AS Option C 630 Option C is also quite straightforward, because there exists an LSP 631 directly from ingress PE to egress PE. In this case, there is no 632 significant difference in operation from the single AS case described 633 in Section 3. Furthermore, if it is desired to provide admission 634 control from PE to PE, it can be done by building an inter-AS TE 635 tunnel and then using the procedures described in Section 4. 637 6. Operation with RSVP disabled 639 It is often the case that RSVP will not be enabled on the PE-CE 640 links. In such an environment, a customer may reasonably expect that 641 RSVP messages sent into the L3 VPN network should be forwarded just 642 like any other IP datagrams. This transparency is useful when the 643 customer wishes to use RSVP within his own sites or perhaps to 644 perform admission control on the CE-PE links (in CE->PE direction 645 only), without involvement of the PEs. For this reason, a PE SHOULD 646 NOT discard or modify RSVP messages sent towards it from a CE when 647 RSVP is not enabled on the PE-CE links. Similarly a PE SHOULD NOT 648 discard or modify RSVP messages which are destined for one of its 649 attached CEs, even when RSVP is not enabled on those links. Note 650 that the presence of the router alert option in some RSVP messages 651 may cause them to be forwarded outside of the normal forwarding path, 652 but that the guidance of this paragraph still applies in that case. 653 Note also that this guidance applies regardless of whether RSVP-TE is 654 used in some, all, or none of the L3VPN network. 656 7. Other RSVP procedures 658 This section describes modifications to other RSVP procedures 659 introduced by MPLS VPNs 661 7.1. Refresh overhead reduction 663 The following points should be noted regarding RSVP refresh overhead 664 reduction ([RFC2961]) across a MPLS VPN: 666 o The hop between the ingress and egress PE of a VPN should be 667 considered as traversing one or more non-RSVP hops. As such, the 668 procedures described in Section 5.3 of [RFC2961] relating to non- 669 RSVP hops SHOULD be followed. 671 o The source IP address of a SRefresh message MUST match the IPv4 672 address signalled in the RSVP_HOP object contained in the 673 corresponding Path or Resv message. The IPv4 address in any 674 received VPN-IPv4 RSVP_HOP object MUST be used as the source 675 address of that message for this purpose. 677 7.2. Cryptographic Authentication 679 The following points should be noted regarding RSVP cryptographic 680 authentication ([RFC2747]) across a MPLS VPN: 682 o The IPv4 address in any received VPN-IPv4 RSVP_HOP object MUST be 683 used as the source address of that message for purposes of 684 identifying the security association. 686 o Forwarding of Challenge and Response messages MUST follow the same 687 rules as described in for hop-by-hop messages. Specifically, if 688 the originator of a Challenge/Response message has received a VPN- 689 IPv4 RSVP_HOP object from the corresponding neighbor, it MUST use 690 the label associated with that VPN-IPv4 address in BGP to forward 691 the Challenge/Response message. 693 7.3. RSVP Aggregation 695 [RFC3175] and [RFC4860] describe mechanisms to aggregate multiple 696 individual RSVP reservations into a single larger reservation on the 697 basis of a common DHCP/PHB for traffic classification. The following 698 points should be noted in this regard: 700 o These procedures apply only in the case where the Aggregator and 701 Deaggregator nodes are C/CE devices, and the entire MPLS VPN lies 702 within the Aggregation Region. The case where the PE is also an 703 Aggregator/Deaggregator is more complex and not considered in this 704 document. 706 o Aggregate RSVP sessions will be treated in the same way as regular 707 IPv4 RSVP sessions. To this end, all the procedures described in 708 Section 3 and Section 4 apply to aggregate RSVP sessions. New 709 SESSION, SENDER_TEMPLATE and FILTERSPEC objects are defined in 710 [objects]. 712 o End-To-End (E2E) RSVP sessions are passed unmodified through the 713 MPLS VPN. These RSVP messages may be identified by their IP 714 protocol (RSVP-E2E-IGNORE, 134). When the ingress PE receives any 715 RSVP message with this IP protocol, it MUST process this frame as 716 if it is regular customer traffic and ignore any IP Router-Alert 717 flags. The appropriate VPN and transport labels are applied to 718 the frame and it is forwarded towards the remote CE. Note that 719 this message will not be received or processed by any other P or 720 PE node. 722 o Any SESSION-OF-INTEREST objects (defined in [RFC4860]) are to be 723 conveyed unmodified across the MPLS VPN. 725 7.4. Support for CE-CE RSVP-TE 727 [I-D.kumaki-l3vpn-e2e-rsvp-te-reqts] describes a set of requirements 728 for the establishment for CE-CE MPLS LSPs across networks offering an 729 L3VPN service. The requirements specified in that draft are similar 730 to those addressed by this document, in that both address the issue 731 of handling RSVP requests from customers in a VPN context. It is 732 possible that the solution described here could be adapted to meet 733 the requirements of [I-D.kumaki-l3vpn-e2e-rsvp-te-reqts]. This will 734 be considered in a separate document. 736 8. Object Definitions 737 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects 739 The usage of the VPN-IPv4 SESSION Object is described in Section 3.1 740 and Section 3.2. The VPN-IPv4 SESSION object should appear in all 741 RSVP messages that ordinarily contain a SESSION object and are sent 742 between ingress PE and egress PE in either direction. The object 743 MUST NOT be included in any RSVP messages that are sent outside of 744 the provider's backbone (except in the inter-AS option B and C cases, 745 as described above, when it may appear on inter-AS links). The VPN- 746 IPv4 address in this object is built by combining the IPv4 address 747 from the incoming SESSION with the RD in the BGP advertisement from 748 the egress PE for this prefix and customer. 750 The VPN-IPv6 SESSION object is analogous to the VPN-IPv4 SESSION 751 object, using VPN-IPv6 addresses[RFC4659]. 753 The formats of the objects are as follows: 755 o VPN-IPv4 SESSION object: Class = 1, C-Type = TBA 757 +-------------+-------------+-------------+-------------+ 758 | | 759 + + 760 | VPN-IPv4 DestAddress (12 bytes) | 761 + + 762 | | 763 +-------------+-------------+-------------+-------------+ 764 | Protocol Id | Flags | DstPort | 765 +-------------+-------------+-------------+-------------+ 767 o VPN-IPv6 SESSION object: Class = 1, C-Type = TBA 769 +-------------+-------------+-------------+-------------+ 770 | | 771 + + 772 | | 773 + VPN-IPv6 DestAddress (24 bytes) + 774 / / 775 . . 776 / / 777 | | 778 +-------------+-------------+-------------+-------------+ 779 | Protocol Id | Flags | DstPort | 780 +-------------+-------------+-------------+-------------+ 782 The protocol ID, flags, and DstPort are identical to the IPv4 and 783 IPv6 SESSION objects. 785 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects 787 The usage of the VPN-IPv4 SENDER_TEMPLATE Object is described in 788 Section 3.1 and Section 3.2. The VPN-IPv4 SENDER_TEMPLATE object 789 should appear in all RSVP messages that ordinarily contain a 790 SENDER_TEMPLATE object and are sent between ingress PE and egress PE 791 in either direction (such as Path, PathError, and PathTear). The 792 object MUST NOT be included in any RSVP messages that are sent 793 outside of the provider's backbone (except in the inter-AS option B 794 and C cases, as described above, when it may appear on inter-AS 795 links). The VPN-IPv4 address in this object is built by combining 796 the IPv4 address from the incoming SENDER_TEMPLATE with the RD in the 797 BGP advertisement from the ingress PE for this prefix and customer. 798 The format of the object is as follows: 800 o VPN-IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = TBA 802 +-------------+-------------+-------------+-------------+ 803 | | 804 + + 805 | VPN-IPv4 SrcAddress (12 bytes) | 806 + + 807 | | 808 +-------------+-------------+-------------+-------------+ 809 | Reserved | SrcPort | 810 +-------------+-------------+-------------+-------------+ 812 o VPN-IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = TBA 814 +-------------+-------------+-------------+-------------+ 815 | | 816 + + 817 | | 818 + VPN-IPv6 SrcAddress (24 bytes) + 819 / / 820 . . 821 / / 822 | | 823 +-------------+-------------+-------------+-------------+ 824 | Reserved | SrcPort | 825 +-------------+-------------+-------------+-------------+ 827 The SrcPort is identical to the IPv4 and IPv6 SENDER_TEMPLATE 828 objects. The Reserved field must be set to zero on transmit and 829 ignored on receipt. 831 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects 833 The usage of the VPN-IPv4 FILTER_SPEC Object is described in 834 Section 3.3 and Section 3.4. The VPN-IPv4 FILTER_SPEC object should 835 appear in all RSVP messages that ordinarily contain a FILTER_SPEC 836 object and are sent between ingress PE and egress PE in either 837 direction (such as Resv, ResvError, and ResvTear). The object MUST 838 NOT be included in any RSVP messages that are sent outside of the 839 provider's backbone (except in the inter-AS option B and C cases, as 840 described above, when it may appear on inter-AS links). The VPN-IPv4 841 address in this object is built by combining the IPv4 address from 842 the incoming FILTER_SPEC with the RD in the BGP advertisement from 843 the ingress PE for this prefix and customer. 845 o VPN-IPv4 FILTER_SPEC object: Class = 10, C-Type = TBA 847 Definition same as VPN-IPv4 SENDER_TEMPLATE object. 849 o VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = TBA 851 Definition same as VPN-IPv6 SENDER_TEMPLATE object. 853 The protocol ID, flags, and DstPort are identical to the IPv4 and 854 IPv6 SESSION objects. 856 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects 858 Usage of the VPN-IPv4 RSVP_HOP Object is described in Section 5.2.2. 859 The VPN-IPv4 RSVP_HOP object is used to establish signalling 860 reachability between RSVP neighbors separated by one or more Option-B 861 ASBRs. This object may appear in all RSVP messages that carry a 862 RSVP_HOP object, and that travel between the Ingress and Egress PEs. 863 It MUST NOT be included in any RSVP messages that are sent outside of 864 the provider's backbone (except in the inter-AS option B and C cases, 865 as described above, when it may appear on inter-AS links). The 866 format of the object is as follows: 868 o VPN-IPv4 RSVP_HOP object: Class = 3, C-Type = TBA 870 +-------------+-------------+-------------+-------------+ 871 | IPv4 Next/Previous Hop Address (4 bytes) | 872 +-------------+-------------+-------------+-------------+ 873 | | 874 + + 875 | VPN-IPv4 Next/Previous Hop Address (12 bytes) | 876 + 877 + 878 | | 879 +-------------+-------------+-------------+-------------+ 880 | Logical Interface Handle | 881 +-------------+-------------+-------------+-------------+ 883 o VPN-IPv6 RSVP_HOP object: Class = 3, C-Type = TBA 885 +-------------+-------------+-------------+-------------+ 886 | | 887 + + 888 | | 889 + IPv6 Next/Previous Hop Address (16 bytes) + 890 | | 891 + + 892 | | 893 +-------------+-------------+-------------+-------------+ 894 | | 895 + + 896 | | 897 + VPN-IPv6 Next/Previous Hop Address (24 bytes) + 898 / / 899 . . 900 / / 901 | | 902 +-------------+-------------+-------------+-------------+ 903 | Logical Interface Handle | 904 +-------------+-------------+-------------+-------------+ 906 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects 908 The usage of Aggregated VPN-IPv4 SESSION object is described in 909 Section 7.3. The AGGREGATE-VPN-IPv4 SESSION object should appear in 910 all RSVP messages that ordinarily contain a AGGREGATE-IPv4 SESSION 911 object as defined in [RFC3175] and are sent between ingress PE and 912 egress PE in either direction. The GENERIC-AGGREGATE-VPN-IPv4 913 SESSION object should appear in all RSVP messages that ordinarily 914 contain a GENERIC-AGGREGATE-IPv4 SESSION object as defined in 915 [RFC4860] and are sent between ingress PE and egress PE in either 916 direction. These objects MUST NOT be included in any RSVP messages 917 that are sent outside of the provider's backbone (except in the 918 inter-AS option B and C cases, as described above, when it may appear 919 on inter-AS links). The processing rules for these objects are 920 otherwise identical to those of the VPN-IPv4 SESSION object defined 921 in Section 8.1. The VPN-IPv4 address in this object is built by 922 combining the IPv4 address from the incoming SESSION with the RD in 923 the BGP advertisement from the egress PE for this prefix and 924 customer. The format of the object is as follows: 926 o AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = TBA 928 +-------------+-------------+-------------+-------------+ 929 | | 930 + + 931 | VPN-IPv4 DestAddress (12 bytes) | 932 + + 933 | | 934 +-------------+-------------+-------------+-------------+ 935 | /////// | Flags | /////// | DSCP | 936 +-------------+-------------+-------------+-------------+ 938 o AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = TBA 940 +-------------+-------------+-------------+-------------+ 941 | | 942 + + 943 | | 944 + VPN-IPv6 DestAddress (24 bytes) + 945 / / 946 . . 947 / / 948 | | 949 +-------------+-------------+-------------+-------------+ 950 | Reserved | Flags | Reserved | DSCP | 951 +-------------+-------------+-------------+-------------+ 953 The flags and DSCP are identical to the AGGREGATE-IPv4 and AGGREGATE- 954 IPv6 SESSION objects. 956 o GENERIC-AGGREGATE-VPN-IPv4 SESSION object: 957 Class = 1, C-Type = TBA 959 +-------------+-------------+-------------+-------------+ 960 | | 961 + + 962 | VPN-IPv4 DestAddress (12 bytes) | 963 + + 964 | | 965 +-------------+-------------+-------------+-------------+ 966 | Reserved | Flags | PHB-ID | 967 +-------------+-------------+-------------+-------------+ 968 | Reserved | vDstPort | 969 +-------------+-------------+-------------+-------------+ 970 | Extended vDstPort | 971 +-------------+-------------+-------------+-------------+ 973 o GENERIC-AGGREGATE-VPN-IPv6 SESSION object: 974 Class = 1, C-Type = TBA 976 +-------------+-------------+-------------+-------------+ 977 | | 978 + + 979 | | 980 + VPN-IPv6 DestAddress (24 bytes) + 981 / / 982 . . 983 / / 984 | | 985 +-------------+-------------+-------------+-------------+ 986 | Reserved | Flags | PHB-ID | 987 +-------------+-------------+-------------+-------------+ 988 | Reserved | vDstPort | 989 +-------------+-------------+-------------+-------------+ 990 | Extended vDstPort | 991 +-------------+-------------+-------------+-------------+ 993 The flags, PHB-ID, vDstPort and Extended vDstPort are identical to 994 the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE-IPv6 SESSION 995 objects. 997 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 SENDER_TEMPLATE objects 999 The usage of Aggregated VPN-IPv4 SENDER_TEMPLATE object is described 1000 in Section 7.3. The AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object should 1001 appear in all RSVP messages that ordinarily contain a AGGREGATE-IPv4 1002 SENDER_TEMPLATE object as defined in [RFC3175] and [RFC4860], and are 1003 sent between ingress PE and egress PE in either direction. These 1004 objects MUST NOT be included in any RSVP messages that are sent 1005 outside of the provider's backbone (except in the inter-AS option B 1006 and C cases, as described above, when it may appear on inter-AS 1007 links). The processing rules for these objects are otherwise 1008 identical to those of the VPN-IPv4 SENDER_TEMPLATE object defined in 1009 Section 8.2. The VPN-IPv4 address in this object is built by 1010 combining the IPv4 address from the incoming SENDER_TEMPLATE with the 1011 RD in the BGP advertisement from the ingress PE for this prefix and 1012 customer. The format of the object is as follows: 1014 o AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object: 1015 Class = 11, C-Type = TBA 1017 +-------------+-------------+-------------+-------------+ 1018 | | 1019 + + 1020 | VPN-IPv4 DestAddress (12 bytes) | 1021 + + 1022 | | 1023 +-------------+-------------+-------------+-------------+ 1025 o AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object: 1026 Class = 11, C-Type = TBA 1028 +-------------+-------------+-------------+-------------+ 1029 | | 1030 + + 1031 | | 1032 + VPN-IPv6 DestAddress (24 bytes) + 1033 / / 1034 . . 1035 / / 1036 | | 1037 +-------------+-------------+-------------+-------------+ 1039 The flags and DSCP are identical to the AGGREGATE-IPv4 and AGGREGATE- 1040 IPv6 SESSION objects. 1042 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC objects 1044 The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in 1045 Section 7.3. The AGGREGATE-VPN-IPv4 FILTER_SPEC object should appear 1046 in all RSVP messages that ordinarily contain a AGGREGATE-IPv4 1047 FILTER_SPEC object as defined in [RFC3175] and [RFC4860], and are 1048 sent between ingress PE and egress PE in either direction. These 1049 objects MUST NOT be included in any RSVP messages that are sent 1050 outside of the provider's backbone (except in the inter-AS option B 1051 and C cases, as described above, when it may appear on inter-AS 1052 links). The processing rules for these objects are otherwise 1053 identical to those of the VPN-IPv4 FILTER_SPEC object defined in 1054 Section 8.3. The VPN-IPv4 address in this object is built by 1055 combining the IPv4 address from the incoming FILTER_SPEC with the RD 1056 in the BGP advertisement from the ingress PE for this prefix and 1057 customer. The format of the object is as follows: 1059 o AGGREGATE-VPN-IPv4 FILTER_SPEC object: 1060 Class = 10, C-Type = TBA 1062 Definition same as AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object. 1064 o AGGREGATE-VPN-IPv6 FILTER_SPEC object: 1065 Class = 10, C-Type = TBA 1067 Definition same as AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object. 1069 9. IANA Considerations 1071 This document requires IANA assignment of new RSVP C-Types to 1072 accommodate the new objects described in Section 8. In addition, a 1073 new PathError code/value is required to identify a signalling 1074 reachability failure and the need for a VPN-IPv4 or VPN-IPv6 RSVP_HOP 1075 object as described in Section 5.2.2. 1077 10. Security Considerations 1079 [RFC4364] addresses the security considerations of BGP/MPLS VPNs in 1080 general. General RSVP security considerations are addressed in 1081 [RFC2205]. To ensure the integrity of RSVP, the RSVP Authentication 1082 mechanisms defined in [RFC2747] and [RFC3097]may be used. These 1083 protect RSVP message integrity hop-by-hop and provide node 1084 authentication as well as replay protection, thereby protecting 1085 against corruption and spoofing of RSVP messages. 1086 [I-D.behringer-tsvwg-rsvp-security-groupkeying] discusses 1087 applicability of various keying approaches for RSVP Authentication. 1088 We note that the RSVP signaling in MPLS VPN is likely to spread over 1089 multiple administrative domains (e.g. the service provider operating 1090 the VPN service, and the customers of the service). Therefore the 1091 considerations in [I-D.behringer-tsvwg-rsvp-security-groupkeying] 1092 about inter-domain issues are likely to apply. 1094 Beyond those general issues, two specific issues are introduced by 1095 this document: resource usage on PEs, and resource usage in the 1096 provider backbone. We discuss these in turn. 1098 A customer who makes resource reservations on the CE-PE links for his 1099 sites is only competing for link resources with himself, as in 1100 standard RSVP, at least in the common case where each CE-PE link is 1101 dedicated to a single customer. Thus, from the perspective of the 1102 CE-PE links, this draft does not introduce any new security issues. 1103 However, because a PE typically serves multiple customers, there is 1104 also the possibility that a customer might attempt to use excessive 1105 computational resources on a PE (CPU cycles, memory etc.) by sending 1106 large numbers of RSVP messages to a PE. In the extreme this could 1107 represent a form of denial-of-service attack. In order to prevent 1108 such an attack, a PE should have mechanisms to limit the fraction of 1109 its processing resources that can be consumed by any one CE or by the 1110 set of CEs of a given customer. For example, a PE might implement a 1111 form of rate limiting on RSVP messages that it receives from each CE. 1113 The second concern arises only when the service provider chooses to 1114 offer resource reservation across the backbone, as described in 1115 Section 4. In this case, the concern may be that a single customer 1116 might attempt to reserve a large fraction of backbone capacity, 1117 perhaps with a co-ordinated effort from several different CEs, thus 1118 denying service to other customers using the same backbone. 1119 [RFC4804] provides some guidance on the security issues when RSVP 1120 reservations are aggregated onto MPLS tunnels, which are applicable 1121 to the situation described here. We note that a provider may use 1122 local policy to limit the amount of resources that can be reserved by 1123 a given customer from a particular PE, and that a policy server could 1124 be used to control the resource usage of a given customer across 1125 multiple PEs if desired. 1127 11. Acknowledgments 1129 Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter and Eric 1130 Rosen for their many contributions to solving the problems described 1131 in this draft. 1133 Appendix A. Alternatives Considered 1135 At this stage a number of alternatives to the approach described 1136 above have been considered. We document some of the approaches 1137 considered here to assist future discussion. None of these has been 1138 shown to improve upon the approach described above, and the first two 1139 seem to have significant drawbacks relative to the approach described 1140 above. 1142 Appendix A.1. GMPLS UNI approach 1144 [RFC4208] defines the GMPLS UNI. In Section 7 the operation of the 1145 GMPLS UNI in a VPN context is briefly described. This is somewhat 1146 similar to the problem tackled in the current document. The main 1147 difference is that the GMPLS UNI is primarily aimed at the problem of 1148 allowing a CE device to request the establishment of an LSP across 1149 the network on the other side of the UNI. Hence the procedures in 1150 [RFC4208] would lead to the establishment of an LSP across the VPN 1151 provider's network for every RSVP request received, which is not 1152 desired in this case. 1154 To the extent possible, the approach described in this document is 1155 consistent with [RFC4208], while filling in more of the details and 1156 avoiding the problem noted above. 1158 Appendix A.2. VRF label approach 1160 Another approach to solving the problems described here involves the 1161 use of label switching to ensure that Path, Resv, and other RSVP 1162 messages are directed to the appropriate VRF. One challenge with 1163 such an approach is that [RFC4364] does not require labels to be 1164 allocated for VRFs, only for customer prefixes, and that there is no 1165 simple, existing method for advertising the fact that a label is 1166 bound to a VRF. If, for example, an ingress PE sent a Path message 1167 labelled with a VPN label that was advertised by the egress PE for 1168 the prefix that matches the destination address in the Path, there is 1169 a risk that the egress PE would simply label-switch the Path directly 1170 on to the CE without performing RSVP processing. 1172 A second challenge with this approach is that an IP address needs to 1173 be associated with a VRF and used as the PHOP address for the Path 1174 message sent from ingress PE to egress PE. That address must be 1175 reachable from the egress PE, and exist in the VRF at the ingress PE. 1176 Such an address is not always available in today's deployments, so 1177 this represents at least a change to existing deployment practices. 1179 Appendix A.3. VRF label plus VRF address approach 1181 It is possible to create an approach based on that described in the 1182 previous section which addresses the main challenges of that 1183 approach. The basic approach has two parts: (a) define a new BGP 1184 Extended Community to tag a route (and its associated MPLS label) as 1185 pointing to a VRF; (b) allocate a "dummy" address to each VRF, 1186 specifically to be used for routing RSVP messages. The dummy address 1187 (which could be anything, e.g. a loopback of the associated PE) would 1188 be used as a PHOP for Path messages and would serve as the 1189 destination for Resv messages but would not be imported into VRFs of 1190 any other PE. 1192 12. References 1194 12.1. Normative References 1196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1197 Requirement Levels", BCP 14, RFC 2119, March 1997. 1199 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1200 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1201 Functional Specification", RFC 2205, September 1997. 1203 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 1204 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 1205 RFC 3175, September 2001. 1207 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1208 Networks (VPNs)", RFC 4364, February 2006. 1210 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1211 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1212 IPv6 VPN", RFC 4659, September 2006. 1214 [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation 1215 Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", 1216 RFC 4804, February 2007. 1218 12.2. Informative References 1220 [I-D.behringer-tsvwg-rsvp-security-groupkeying] 1221 Behringer, M. and F. Faucheur, "Applicability of Keying 1222 Methods for RSVP Security", 1223 draft-behringer-tsvwg-rsvp-security-groupkeying-01 (work 1224 in progress), November 2007. 1226 [I-D.kumaki-l3vpn-e2e-rsvp-te-reqts] 1227 Kumaki, K., "Requirements for supporting Customer RSVP and 1228 RSVP-TE Over a BGP/MPLS IP-VPN", 1229 draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06 (work in 1230 progress), February 2008. 1232 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1233 Services in the Internet Architecture: an Overview", 1234 RFC 1633, June 1994. 1236 [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol 1237 (RSVP) -- Version 1 Message Processing Rules", RFC 2209, 1238 September 1997. 1240 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1241 Services", RFC 2210, September 1997. 1243 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1244 Authentication", RFC 2747, January 2000. 1246 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1247 and S. Molendini, "RSVP Refresh Overhead Reduction 1248 Extensions", RFC 2961, April 2001. 1250 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1251 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1252 Encoding", RFC 3032, January 2001. 1254 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 1255 Authentication -- Updated Message Type Value", RFC 3097, 1256 April 2001. 1258 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1259 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1260 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1262 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1263 Bosch, "Next Steps in Signaling (NSIS): Framework", 1264 RFC 4080, June 2005. 1266 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1267 Hierarchy with Generalized Multi-Protocol Label Switching 1268 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 1270 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1271 "Generalized Multiprotocol Label Switching (GMPLS) User- 1272 Network Interface (UNI): Resource ReserVation Protocol- 1273 Traffic Engineering (RSVP-TE) Support for the Overlay 1274 Model", RFC 4208, October 2005. 1276 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 1277 Davenport, "Generic Aggregate Resource ReSerVation 1278 Protocol (RSVP) Reservations", RFC 4860, May 2007. 1280 Authors' Addresses 1282 Bruce Davie 1283 Cisco Systems, Inc. 1284 1414 Mass. Ave. 1285 Boxborough, MA 01719 1286 USA 1288 Email: bsd@cisco.com 1290 Francois le Faucheur 1291 Cisco Systems, Inc. 1292 Village d'Entreprise Green Side - Batiment T3 1293 400, Avenue de Roumanille 1294 Biot Sophia-Antipolis 06410 1295 France 1297 Email: flefauch@cisco.com 1299 Ashok Narayanan 1300 Cisco Systems, Inc. 1301 1414 Mass. Ave. 1302 Boxborough, MA 01719 1303 USA 1305 Email: ashokn@cisco.com 1307 Full Copyright Statement 1309 Copyright (C) The IETF Trust (2008). 1311 This document is subject to the rights, licenses and restrictions 1312 contained in BCP 78, and except as set forth therein, the authors 1313 retain all their rights. 1315 This document and the information contained herein are provided on an 1316 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1317 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1318 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1319 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1320 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1321 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1323 Intellectual Property 1325 The IETF takes no position regarding the validity or scope of any 1326 Intellectual Property Rights or other rights that might be claimed to 1327 pertain to the implementation or use of the technology described in 1328 this document or the extent to which any license under such rights 1329 might or might not be available; nor does it represent that it has 1330 made any independent effort to identify any such rights. Information 1331 on the procedures with respect to rights in RFC documents can be 1332 found in BCP 78 and BCP 79. 1334 Copies of IPR disclosures made to the IETF Secretariat and any 1335 assurances of licenses to be made available, or the result of an 1336 attempt made to obtain a general license or permission for the use of 1337 such proprietary rights by implementers or users of this 1338 specification can be obtained from the IETF on-line IPR repository at 1339 http://www.ietf.org/ipr. 1341 The IETF invites any interested party to bring to its attention any 1342 copyrights, patents or patent applications, or other proprietary 1343 rights that may cover technology that may be required to implement 1344 this standard. Please address the information to the IETF at 1345 ietf-ipr@ietf.org. 1347 Acknowledgment 1349 Funding for the RFC Editor function is provided by the IETF 1350 Administrative Support Activity (IASA).