idnits 2.17.1 draft-ietf-tsvwg-rsvp-l3vpn-00.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 1376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1400. 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 (July 3, 2008) is 5776 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 1305, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 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: January 4, 2009 Cisco Systems, Inc. 6 July 3, 2008 8 Support for RSVP in Layer 3 VPNs 9 draft-ietf-tsvwg-rsvp-l3vpn-00 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 January 4, 2009. 36 Abstract 38 RFC 4364 and RFC 4659 define an approach to building provider- 39 provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to 40 use RSVP to perform admission control on the links between CE and PE 41 routers. This document specifies procedures by which RSVP messages 42 travelling from CE to CE across an L3VPN may be appropriately handled 43 by PE routers so that admission control can be performed on PE-CE 44 links. Optionally, admission control across the provider's backbone 45 may also be supported. 47 Requirements Language 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC 2119 [RFC2119]. 53 Change history 55 [_Note to RFC Editor: This section to be removed before publication_] 57 Changes in this version (draft-ietf-tsvwg-rsvp-l3vpn-00) relative to 58 the last (draft-davie-tsvwg-rsvp-l3vpn-02): 60 o Outlined signalling security issues and added discussion of 61 methods to control redistribution of routes among providers and 62 from providers to customers 64 o Clarification regarding support for RSVP-TE across L3VPN 66 o Minor corrections 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 73 2.1. Model of Operation . . . . . . . . . . . . . . . . . . . . 6 74 3. Admission Control on PE-CE Links . . . . . . . . . . . . . . . 7 75 3.1. Path Message Processing at Ingress PE . . . . . . . . . . 8 76 3.2. Path Message Processing at Egress PE . . . . . . . . . . . 9 77 3.3. Resv Processing at Egress PE . . . . . . . . . . . . . . . 9 78 3.4. Resv Processing at Ingress PE . . . . . . . . . . . . . . 10 79 3.5. Other RSVP Messages . . . . . . . . . . . . . . . . . . . 10 80 4. Admission Control in Provider's Backbone . . . . . . . . . . . 11 81 5. Inter-AS operation . . . . . . . . . . . . . . . . . . . . . . 12 82 5.1. Inter-AS Option A . . . . . . . . . . . . . . . . . . . . 12 83 5.2. Inter-AS Option B . . . . . . . . . . . . . . . . . . . . 12 84 5.2.1. Admission control on ASBR . . . . . . . . . . . . . . 12 85 5.2.2. No admission control on ASBR . . . . . . . . . . . . . 13 86 5.3. Inter-AS Option C . . . . . . . . . . . . . . . . . . . . 15 87 6. Operation with RSVP disabled . . . . . . . . . . . . . . . . . 15 88 7. Other RSVP procedures . . . . . . . . . . . . . . . . . . . . 15 89 7.1. Refresh overhead reduction . . . . . . . . . . . . . . . . 15 90 7.2. Cryptographic Authentication . . . . . . . . . . . . . . . 16 91 7.3. RSVP Aggregation . . . . . . . . . . . . . . . . . . . . . 16 92 7.4. Support for CE-CE RSVP-TE . . . . . . . . . . . . . . . . 17 93 8. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 17 94 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . . . . . . 17 95 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects . . . . . . 18 96 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects . . . . . . . . 19 97 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects . . . . . . . . . . 20 98 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . 21 99 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 100 SENDER_TEMPLATE objects . . . . . . . . . . . . . . . . . 23 101 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC 102 objects . . . . . . . . . . . . . . . . . . . . . . . . . 25 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 104 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 105 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 106 Appendix A. Alternatives Considered . . . . . . . . . . . . . . 27 107 Appendix A.1. GMPLS UNI approach . . . . . . . . . . . . . . . . . 28 108 Appendix A.2. VRF label approach . . . . . . . . . . . . . . . . . 28 109 Appendix A.3. VRF label plus VRF address approach . . . . . . . . 28 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 111 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 112 12.2. Informative References . . . . . . . . . . . . . . . . . . 29 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 114 Intellectual Property and Copyright Statements . . . . . . . . . . 32 116 1. Introduction 118 [RFC4364] and [RFC4659] define a Layer 3 VPN service known as BGP/ 119 MPLS VPNs for IPv4 and for IPv6 respectively. [RFC2205] defines the 120 Resource Reservation Protocol (RSVP) which may be used to perform 121 admission control as part of the Integrated Services (int-serv) 122 architecture [RFC1633][RFC2210]. 124 Customers of a layer 3 VPN service may run RSVP for the purposes of 125 admission control in their own networks. Since the links between 126 Provider Edge (PE) and Customer Edge (CE) routers in a layer 3 VPN 127 may often be resource constrained, it may be desirable to be able to 128 perform admission control over those links. In order to perform 129 admission control using RSVP in such an environment, it is necessary 130 that RSVP control messages, such as Path messages and Resv messages, 131 are appropriately handled by the PE routers. This presents a number 132 of challenges in the context of BGP/MPLS VPNs: 134 o RSVP Path message processing depends on routers recognizing the 135 router alert option in the IP header. However, packets traversing 136 the backbone of a BGP/MPLS VPN are MPLS encapsulated and thus the 137 router alert option is not normally visible to the egress PE. 139 o BGP/MPLS VPNs support non-unique addressing of customer networks. 140 Thus a PE at the ingress or egress of the provider backbone may be 141 called upon to process Path messages from different customer VPNs 142 with non-unique destination addresses. 144 o A PE at the ingress of the provider's backbone may receive Resv 145 messages corresponding to different customer VPNs from other PEs, 146 and needs to be able to associate those Resv messages with the 147 appropriate customer VPNs. 149 This document describes a set of procedures to overcome these 150 challenges and thus to enable admission control using RSVP over the 151 PE-CE links. We note that similar techniques may be applicable to 152 other protocols used for admission control such as NSIS [RFC4080]. 154 Additionally, it may be desirable to perform admission control over 155 the provider's backbone on behalf of one or more L3VPN customers. 156 Core (P) routers in a BGP/MPLS VPN do not have forwarding entries for 157 customer routes, and thus cannot natively process RSVP messages for 158 customer flows. Also the core is a shared resource that carries 159 traffic for many customers, so issues of resource allocation among 160 customers and trust (or lack thereof) must also be addressed. This 161 draft also specifies procedures for supporting such a scenario. 163 This draft deals with establishing reservations for unicast flows 164 only. Because the support of multicast traffic in BGP/MPLS VPNs is 165 still evolving, and raises additional challenges for admission 166 control, we leave the support of multicast flows for further study at 167 this point. 169 1.1. Terminology 171 This document draws freely on the terminology defined in [RFC2205] 172 and [RFC4364]. For convenience, we provide a few brief definitions 173 here: 175 o CE (Customer Edge) Router: Router at the edge of a customer site 176 that attaches to the network of the VPN provider. 178 o PE (Provider Edge) Router: Router at the edge of the service 179 provider's network that attaches to one or more customer sites. 181 o VPN Label: An MPLS label associated with a route to a customer 182 prefix in a VPN (also called a VPN route label). 184 o VRF: VPN Routing and Forwarding Table. A PE typically has 185 multiple VRFs, enabling it to be connected to CEs that are in 186 different VPNs. 188 2. Problem Statement 190 The problem space of this document is the support of admission 191 control between customer sites when the customer subscribes to a BGP/ 192 MPLS VPN. We subdivide the problem into (a) the problem of admission 193 control on the PE-CE links (in both directions), and (b) the problem 194 of admission control across the provider's backbone. 196 For the PE-CE link subproblem, the most basic challenge is that RSVP 197 control messages contain IP addresses that are drawn from the 198 customer's address space, and PEs must be able to deal with traffic 199 from many customers who may have non-unique (or overlapping) address 200 spaces. Thus, it is essential that a PE be able in all cases to 201 identify the correct VPN context in which to process an RSVP control 202 message. Much of this draft deals with this issue. 204 For the case of making reservations across the provider backbone, we 205 observe that BGP/MPLS VPNs do not create any per-customer forwarding 206 state in the P (provider core) routers. Thus, in order to make 207 reservations on behalf of customer-specified flows, it is clearly 208 necessary to make some sort of aggregated reservation from PE-PE and 209 then map individual, customer-specific reservations onto an aggregate 210 reservation. That is similar to the problem tackled in [RFC3175] and 212 [RFC4804], with the additional complications of handling customer- 213 specific addressing associated with BGP/MPLS VPNs. 215 Finally, we note that RSVP Path messages are normally addressed to 216 the destination of a session, and contain the router alert IP option. 217 Routers along the path to the destination that are configured to 218 process RSVP messages must detect the presence of the router alert 219 option to allow them to intercept Path messages. However, the egress 220 PEs of a network supporting BGP/MPLS VPNs receive packets destined 221 for customer sites as MPLS-encapsulated packets, and may forward 222 those based only on examination of the MPLS label. Hence, a Path 223 message would be forwarded without examination of the IP options and 224 would therefore not receive appropriate processing at the PE. This 225 problem of recognizing and processing Path messages is also discussed 226 below. 228 2.1. Model of Operation 230 Figure 1 illustrates the basic model of operation with which this 231 document is concerned. 233 -------------------------- 234 / Provider \ 235 |----| | Backbone | |----| 236 Sender->| CE1| |-----| |-----| |CE2 |->Receiver 237 | |--| | |---| |---| | |---| | 238 |----| | | | P | | P | | | |----| 239 | PE1 |---| |-----| |-----| PE2 | 240 | | | | | | | | 241 | | |---| |---| | | 242 |-----| |-----| 243 | | 244 \ / 245 -------------------------- 247 Figure 1. Model of Operation for RSVP-based admission control over 248 MPLS/BGP VPN 250 To establish a unidirectional reservation for a point-to-point flow 251 from Sender to Receiver that takes account of resource availability 252 on the CE-PE and PE-CE links only, the following steps must take 253 place: 255 1. Sender sends a Path message to an IP address of the Receiver. 257 2. Path message is processed by CE1 using normal RSVP procedures 258 and forwarded towards the Receiver along the link CE1-PE1. 260 3. PE1 processes Path message and forwards towards the Receiver 261 across the provider backbone. 263 4. PE2 processes Path message and forwards towards the Receiver 264 along link PE2-CE2. 266 5. CE2 processes Path message using normal RSVP procedures and 267 forwards towards Receiver. 269 6. Receiver sends Resv message to CE2. 271 7. CE2 sends Resv message to PE2. 273 8. PE2 processes Resv message (including performing admission 274 control on link PE2-CE2) and sends Resv to PE1. 276 9. PE1 processes Resv message and sends Resv to CE1. 278 10. CE1 processes Resv using normal RSVP procedures, performs 279 admission control on the link CE1-PE1 and sends Resv message to 280 Sender if successful. 282 In each of the steps involving Resv messages (6 through 10) the node 283 sending the Resv uses the previously established Path state to 284 determine the "RSVP Previous Hop (PHOP)" and sends a Resv message to 285 that address. We note that establishing that Path state correctly at 286 PEs is one of the challenges posed by the BGP/MPLS environment. 288 3. Admission Control on PE-CE Links 290 In the following sections we trace through the steps outlined in 291 Section 2.1 and expand on the details for those steps where standard 292 RSVP procedures need to be extended or modified to support the BGP/ 293 MPLS VPN environment. For all the remaining steps described in the 294 preceding section, standard RSVP processing rules apply. 296 All the procedures described below support both IPv4 and IPv6 297 addressing. In all cases where IPv4 is referenced, IPv6 can be 298 substituted with identical procedures and results. Object 299 definitions for both IPv4 and IPv6 are provided in Section 8. 301 3.1. Path Message Processing at Ingress PE 303 When a Path message arrives at the ingress PE (step 3 of Section 2.1) 304 the PE needs to establish suitable Path state and forward the Path 305 message on to the egress PE. In the following paragraphs we 306 described the steps taken by the ingress PE. 308 The Path message is addressed to the eventual destination (the 309 receiver at the remote customer site) and carries the IP Router Alert 310 option, in accordance with [RFC2205]. The ingress PE must recognize 311 the router alert, intercept these messages and process them as RSVP 312 signalling messages. 314 As noted above, there is an issue in recognizing Path messages as 315 they arrive at the egress PE (PE 2 in Figure 1). The approach 316 defined here is to address the Path messages sent by the ingress PE 317 directly to the egress PE, and send it without IP Router Alert; that 318 is, rather than using the ultimate receiver's destination address as 319 the destination address of the Path message, we use the loopback 320 address of the egress PE as the destination address of the Path 321 message. This approach has the advantage that it does not require 322 any new data plane capabilities for the egress PE beyond those of a 323 standard BGP/MPLS VPN PE. Details of the processing of this message 324 at the egress PE are described below in Section 3.2. The approach of 325 addressing a Path message directly to an RSVP next hop (that may or 326 may not be the next IP hop) is already used in other environments 327 such as those of [RFC4206] and [RFC4804]. 329 For an RSVP Path message, the existing SESSION and SENDER_TEMPLATE 330 objects can no longer uniquely identify a flow on VPN PE nodes. We 331 propose a new format of SESSION and SENDER_TEMPLATE objects which 332 contain a VPN-IPv4 format address. The ingress and egress PE nodes 333 translate between the regular IPv4 addresses for messages to and from 334 the CE, and VPN-IPv4 addresses for messages to and from PE routers. 336 The details of operation at the ingress PE are as follows. When the 337 ingress PE (PE1 in Figure 1) receives a Path message from CE1 that is 338 addressed to the receiver, the VRF that is associated with the 339 incoming interface is identified, just as for normal data path 340 operations. The Path state for the session is stored, and is 341 associated with that VRF, so that potentially overlapping addresses 342 among different VPNs do not appear to belong to the same session. 343 The destination address of the receiver is looked up in the 344 appropriate VRF, and the BGP Next-Hop for that destination is 345 identified. That next-hop is the egress PE (PE2 in Figure 1). A new 346 VPN-IPv4 SESSION object is constructed, containing the Route 347 Distinguisher (RD) that is part of the VPN-IPv4 route prefix for this 348 destination, and the IPv4 address from the SESSION. In addition, a 349 new VPN-IPv4 SENDER_TEMPLATE object is constructed, with the original 350 IPv4 address from the incoming SENDER_TEMPLATE plus the RD that is 351 used by this PE to advertise that prefix for this customer into the 352 VPN. A new Path message is constructed with a destination address 353 equal to the address of the egress PE identified above. This new 354 Path message will contain all the objects from the original Path 355 message, replacing the original SESSION and SENDER_TEMPLATE objects 356 with the new VPN-IPv4 type objects. The RSVP_HOP object in the Path 357 message contains an IP address of the ingress PE. The Path message 358 is sent without IP Router Alert. 360 3.2. Path Message Processing at Egress PE 362 When a Path message arrives at the egress PE, it is addressed to the 363 PE itself, and is handed to RSVP for processing. The router extracts 364 the RD and IPv4 address from the VPN-IPv4 SESSION object, and 365 determines the local VRF context by finding a matching VPN-IPv4 366 prefix with the specified RD that has been advertised by this router 367 into BGP. The entire incoming RSVP message, including the VRF 368 information, is stored as part of the Path state. 370 Now the RSVP module can construct a Path message which differs from 371 the Path it received in the following ways: 373 a. Its destination address is the IP address extracted from the 374 SESSION Object; 376 b. The SESSION and SENDER_TEMPLATE objects are converted back to 377 IPv4-type by discarding the attached RD 379 c. The RSVP_HOP Object contains the IP address of the outgoing 380 interface of the egress PE and an LIH, as per normal RSVP 381 processing. 383 The router then sends the Path message on towards its destination 384 over the interface identified above. This Path message carries the 385 IP Router-Alert option as required by [RFC2205]. 387 3.3. Resv Processing at Egress PE 389 When a receiver at the customer site originates a Resv message for 390 the session, normal RSVP procedures apply until the Resv, making its 391 way back towards the sender, arrives at the "egress" PE (it is 392 "egress" with respect to the direction of data flow, i.e. PE2 in 393 figure 1). On arriving at PE2, the SESSION and FILTER_SPEC objects 394 in the Resv, and the VRF in which the Resv was received, are used to 395 find the matching Path state stored previously. At this stage, 396 admission control can be performed on the PE-CE link. 398 Assuming admission control is successful, the PE constructs a Resv 399 message to send to the RSVP HOP stored in the Path state, i.e., the 400 ingress PE (PE1 in Figure 1). The IPv4 SESSION object is replaced 401 with the same VPN-IPv4 SESSION object received in the Path. The IPv4 402 FILTER_SPEC object is replaced with a VPN-IPv4 FILTER_SPEC object, 403 which copies the VPN-IPv4 address from the SENDER_TEMPLATE received 404 in the matching Path message. The RSVP_HOP in the Resv message 405 contains an IP address of the Egress PE that is reachable by the 406 ingress PE. The Resv message is sent to the IP address contained 407 within the RSVP_HOP object in the Path message. 409 If admission control is not successful on the egress PE, a ResvError 410 message is sent towards the receiver as per normal RSVP processing. 412 3.4. Resv Processing at Ingress PE 414 Upon receiving a Resv message at the ingress PE (with respect to data 415 flow, i.e. PE1 in Figure 1), the PE determines the local VRF context 416 and associated Path state for this Resv by decoding the received 417 SESSION and FILTER_SPEC objects. It is now possible to generate a 418 Resv message to send to the appropriate CE. The Resv message sent to 419 the ingress CE will contain IPv4 SESSION and FILTER_SPEC objects, 420 derived from the appropriate Path state. Since we assume in this 421 section that admission control over the Provider's backbone is not 422 needed, the ingress PE does not perform any admission control for 423 this reservation. 425 3.5. Other RSVP Messages 427 Processing of PathError, PathTear, ResvError, ResvTear and ResvConf 428 messages is generally straightforward and follows the rules of 429 [RFC2205]. These additional rules must be observed for messages 430 transmitted within the VPN (i.e. between the PEs): 432 o The SESSION, SENDER_TEMPLATE and FILTER_SPEC objects must be 433 converted from IPv4 to VPN-IPv4 form and back in the same manner 434 as described above for Path and Resv messages. 436 o The matching state & VRF must be determined by decoding the RD and 437 IPv4 addresses in the SESSION and FILTER_SPEC objects. 439 o The message must be directly addressed to the appropriate PE, 440 without using the IP Router Alert option. 442 4. Admission Control in Provider's Backbone 444 The preceding section outlines how per-customer reservations can be 445 made over the PE-CE links. This may be sufficient in many situations 446 where the backbone is well engineered with ample capacity and there 447 is no need to perform any sort of admission control in the backbone. 448 However, in some cases where excess capacity cannot be relied upon 449 (e.g., during failures or unanticipated periods of overload) it may 450 be desirable to be able to perform admission control in the backbone 451 on behalf of customer traffic. 453 Because of the fact that routes to customer addresses are not present 454 in the P routers, along with the concerns of scalability that would 455 arise if per-customer reservations were allowed in the P routers, it 456 is clearly necessary to map the per-customer reservations described 457 in the preceding section onto some sort of aggregate reservations. 458 Furthermore, customer data packets need to be tunneled across the 459 provider backbone just as in normal BGP/MPLS VPN operation. 461 Given these considerations, a feasible way to achieve the objective 462 of admission control in the backbone is to use the ideas described in 463 [RFC4804]. MPLS-TE tunnels can be established between PEs as a means 464 to perform aggregate admission control in the backbone. 466 An MPLS-TE tunnel from an ingress PE to an egress PE can be thought 467 of as a virtual link of a certain capacity. The main change to the 468 procedures described above is that when a Resv is received at the 469 ingress PE, an admission control decision can be performed by 470 checking whether sufficient capacity of that virtual link remains 471 available to admit the new customer reservation. We note also that 472 [RFC4804] uses the IF_ID RSVP_HOP object to identify the tunnel 473 across the backbone, rather than the simple RSVP_HOP object described 474 in Section 3.1. The procedures of [RFC4804] should be followed here 475 as well. 477 To achieve effective admission control in the backbone, there needs 478 to be some way to separate the data plane traffic that has a 479 reservation from that which does not. We assume that packets that 480 are subject to admission control on the core will be given a 481 particular MPLS EXP value, and that no other packets will be allowed 482 to enter the core with this value unless they have passed admission 483 control. Some fraction of link resources will be allocated to queues 484 on core links for packets bearing that EXP value, and the MPLS-TE 485 tunnels will use that resource pool to make their constraint-based 486 routing and admission control decisions. This is all consistent with 487 the principles of aggregate RSVP reservations described in [RFC3175]. 489 5. Inter-AS operation 491 [RFC4364] defines three modes of inter-AS operation for MPLS/BGP 492 VPNs, referred to as options A, B and C. In the following sections we 493 describe how the scheme described above can operate in each inter-AS 494 environment. 496 5.1. Inter-AS Option A 498 Operation of RSVP in Inter-AS Option A is quite straightforward. 499 Each ASBR operates like a PE, and the ASBR-ASBR links can be viewed 500 as PE-CE links in terms of admission control. If the procedures 501 defined in Section 3 are enabled on both ASBRs, then CAC may be 502 performed on the inter-ASBR links. In addition, the operator of each 503 AS can independently decide whether or not to perform CAC across his 504 backbone. The new objects described in this document MUST NOT be 505 sent in any RSVP message between two Option-A ASBRs. 507 5.2. Inter-AS Option B 509 To support inter-AS Option B, we require some additional processing 510 of RSVP messages on the ASBRs. Recall that, when packets are 511 forwarded from one AS to another in option B, the VPN label is 512 swapped by each ASBR as a packet goes from one AS to another. The 513 BGP next hop seen by the ingress PE will be the ASBR, and there need 514 not be IP visibility between the ingress and egress PEs. Hence when 515 the ingress PE sends the Path message to the BGP next hop of the VPN- 516 IPv4 route towards the destination, it will be received by the ASBR. 517 The ASBR determines the next hop of the route in a similar way as the 518 ingress PE - by finding a matching BGP VPN-IPv4 route with the same 519 RD and a matching prefix. 521 The provider(s) who interconnect ASes using option B may or may not 522 desire to perform admission control on the inter-AS links. This 523 choice affects the detailed operation of ASBRs. We describe the two 524 modes of operation - with and without admission control at the ASBRs 525 - in the following sections. 527 5.2.1. Admission control on ASBR 529 In this scenario, the ASBR performs full RSVP signalling and 530 admission control. The RSVP database is indexed on the ASBR using 531 the VPN-IPv4 SESSION, SENDER_TEMPLATE and FILTER_SPEC objects (which 532 uniquely identify RSVP sessions and flows as per the requirements of 533 [RFC2205]). These objects are forwarded unmodified in both 534 directions by the ASBR. All other procedures of RSVP are performed 535 as if the ASBR was a RSVP hop. In particular, the RSVP_HOP objects 536 sent in Path and Resv messages contain IP addresses of the ASBR, 537 which MUST be reachable by the neighbor to whom the message is being 538 sent. Note that since the VPN-IPv4 SESSION, SENDER_TEMPLATE and 539 FILTER_SPEC objects satisfy the uniqueness properties required for a 540 RSVP database implementation as per [RFC2209], no customer VRF 541 awareness is required on the ASBR. 543 5.2.2. No admission control on ASBR 545 If the ASBR is not doing admission control, it is desirable that per- 546 flow state not be maintained on the ASBR. This requires adjacent 547 RSVP hops (i.e. the ingress and egress PEs of the respective ASes) to 548 send RSVP messages directly between them. Not however that such 549 routers in an Option B environment are not required to have direct IP 550 reachability to each other. To mitigate this issue, we propose the 551 use of label switching to forward RSVP messages from a PE in one AS 552 to a PE in another AS. A detailed description of how this is 553 achieved follows. 555 We first define a new VPN-IPv4 RSVP_HOP object. Use of the VPN-IPv4 556 RSVP_HOP object enables RSVP control plane reachability between any 557 two adjacent RSVP hops in a MPLS VPN, regardless of whether they have 558 IP reachability. RSVP nodes sending Path or Resv messages across a 559 MPLS VPN MAY use the VPN-IPv4 PHOP object to achieve signalling 560 across Option-B ASBRs without requiring the ASBRs to install state. 561 The requirements ("SHOULD", "MUST" etc.) specified in the remainder 562 of this section only apply when the implementation supports the 563 OPTIONAL use of the VPN-IPv4 HOP object. 565 The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message 566 sender and a logical interface handle as before, but in addition 567 carries a VPN-IPv4 address which also represents the sender of the 568 message. The message sender MUST also advertise this VPN-IPv4 HOP 569 address into BGP with an associated label, and this advertisement 570 MUST be propagated by BGP throughout the VPN and to adjacent ASes in 571 order to provide reachability to this PE. Frames received by the PE 572 marked with this label MUST be given to the local control plane for 573 processing. This VPN-IPv4 address MAY be created specially for this 574 task, or MAY be any previously-advertised address representing any 575 VRF (e.g. local PE-CE link address). In the case where the address 576 is specially created for control protocols, the BGP advertisement for 577 this address SHOULD be marked such that it is not redistributed 578 outside the MPLS VPN. Two possible methods to achieve this goal are: 580 o Tag the advertisement of such routes with a route target that is 581 not imported into any customer VRFs. This requires the creation 582 of a special "control protocols" VPN which is used only for these 583 addresses. 585 o Tag the advertisement with a specially defined extended-community 586 attribute, the meaning of which is that this route is not to be 587 redistributed to customers. Definition of this attribute is 588 beyond the scope of this document. 590 When an ASBR that is not installing local RSVP state receives a Path 591 message, it looks up the next-hop of the matching BGP route as 592 described in Section 3.1, and sends the Path message to the next-hop, 593 without modifying any RSVP objects (including the RSVP_HOP). This 594 process is repeated at subsequent ASBRs until the Path message 595 arrives at a router that is installing local RSVP state (either the 596 ultimate egress PE, or an ASBR configured to perform CAC). This 597 router receives the Path and processes it as described in Section 3.2 598 if it is a PE, or Section 5.2.1 if it is an ASBR performing CAC. 599 When this router sends the Resv upstream, it queries BGP for a next- 600 hop and label for the VPN-IPv4 address in the PHOP, encapsulates the 601 Resv with that label and sends it upstream. This message will be 602 received for control processing directly on the upstream RSVP hop 603 (the hop that last updated the RSVP_HOP field in the Path message), 604 without any involvement of intermediate ASBRs. Further, the router 605 sending this Resv message MUST include in its RSVP_HOP object a VPN- 606 IPv4 address advertised by itself into BGP with a label, so that hop- 607 by-hop RSVP messages in the downstream direction (e.g. ResvError) 608 can be sent directly to it. Note that the VPN-IPv4 address is only 609 used to identify a LSP for neighbor reachability. The IPv4 address 610 in the RSVP_HOP object is used for all other purposes, including 611 neighbor matching between Path/Resv and SRefresh messages 612 ([RFC2961]), authentication ([RFC2747]), etc. 614 The ASBR is not expected to process any other RSVP messages apart 615 from the Path message as described above. The ASBR also does not 616 need to store any RSVP state. Note that any ASBR along the path that 617 wishes to do admission control or insert itself into the RSVP 618 signalling flow, may do so by writing its own RSVP_HOP object with 619 IPv4 and VPN-IPv4 address pointing to itself. 621 If an Option-B ASBR receives a RSVP Path message with an IPv4 type 622 PHOP, does not wish to perform admission control but is willing to 623 install local state for this flow, the ASBR MUST process and forward 624 RSVP signalling messages for this flow as described in section 5.2.1 625 (except admission control). If an Option-B ASBR receives a RSVP Path 626 message with an IPv4 type PHOP, but does not wish to install local 627 state or perform admission control for this flow, the ASBR MUST NOT 628 forward the Path message. In addition, the ASBR SHOULD send a 629 PathError message of Error Code [_TBD_], Error Value [_TBD_], 630 signifying to the upstream RSVP hop that the supplied PHOP object is 631 insufficient to provide reachability across this VPN. The upstream 632 node, on receipt of this PathError, SHOULD re-send the Path message 633 including a RSVP_HOP of VPN-IPv4 type. 635 5.3. Inter-AS Option C 637 Operation of RSVP in Inter-AS Option C is also quite straightforward, 638 because there exists an LSP directly from ingress PE to egress PE. 639 In this case, there is no significant difference in operation from 640 the single AS case described in Section 3. Furthermore, if it is 641 desired to provide admission control from PE to PE, it can be done by 642 building an inter-AS TE tunnel and then using the procedures 643 described in Section 4. 645 6. Operation with RSVP disabled 647 It is often the case that RSVP will not be enabled on the PE-CE 648 links. In such an environment, a customer may reasonably expect that 649 RSVP messages sent into the L3 VPN network should be forwarded just 650 like any other IP datagrams. This transparency is useful when the 651 customer wishes to use RSVP within his own sites or perhaps to 652 perform admission control on the CE-PE links (in CE->PE direction 653 only), without involvement of the PEs. For this reason, a PE SHOULD 654 NOT discard or modify RSVP messages sent towards it from a CE when 655 RSVP is not enabled on the PE-CE links. Similarly a PE SHOULD NOT 656 discard or modify RSVP messages which are destined for one of its 657 attached CEs, even when RSVP is not enabled on those links. Note 658 that the presence of the router alert option in some RSVP messages 659 may cause them to be forwarded outside of the normal forwarding path, 660 but that the guidance of this paragraph still applies in that case. 661 Note also that this guidance applies regardless of whether RSVP-TE is 662 used in some, all, or none of the L3VPN network. 664 7. Other RSVP procedures 666 This section describes modifications to other RSVP procedures 667 introduced by MPLS VPNs 669 7.1. Refresh overhead reduction 671 The following points should be noted regarding RSVP refresh overhead 672 reduction ([RFC2961]) across a MPLS VPN: 674 o The hop between the ingress and egress PE of a VPN should be 675 considered as traversing one or more non-RSVP hops. As such, the 676 procedures described in Section 5.3 of [RFC2961] relating to non- 677 RSVP hops SHOULD be followed. 679 o The source IP address of a SRefresh message MUST match the IPv4 680 address signalled in the RSVP_HOP object contained in the 681 corresponding Path or Resv message. The IPv4 address in any 682 received VPN-IPv4 RSVP_HOP object MUST be used as the source 683 address of that message for this purpose. 685 7.2. Cryptographic Authentication 687 The following points should be noted regarding RSVP cryptographic 688 authentication ([RFC2747]) across a MPLS VPN: 690 o The IPv4 address in any received VPN-IPv4 RSVP_HOP object MUST be 691 used as the source address of that message for purposes of 692 identifying the security association. 694 o Forwarding of Challenge and Response messages MUST follow the same 695 rules as described above for hop-by-hop messages. Specifically, 696 if the originator of a Challenge/Response message has received a 697 VPN-IPv4 RSVP_HOP object from the corresponding neighbor, it MUST 698 use the label associated with that VPN-IPv4 address in BGP to 699 forward the Challenge/Response message. 701 7.3. RSVP Aggregation 703 [RFC3175] and [RFC4860] describe mechanisms to aggregate multiple 704 individual RSVP reservations into a single larger reservation on the 705 basis of a common DSCP/PHB for traffic classification. The following 706 points should be noted in this regard: 708 o The procedures described in this section apply only in the case 709 where the Aggregator and Deaggregator nodes are C/CE devices, and 710 the entire MPLS VPN lies within the Aggregation Region. The case 711 where the PE is also an Aggregator/Deaggregator is more complex 712 and not considered in this document. 714 o Aggregate RSVP sessions will be treated in the same way as regular 715 IPv4 RSVP sessions. To this end, all the procedures described in 716 Section 3 and Section 4 apply to aggregate RSVP sessions. New 717 SESSION, SENDER_TEMPLATE and FILTERSPEC objects are defined in 718 Section 8. 720 o End-To-End (E2E) RSVP sessions are passed unmodified through the 721 MPLS VPN. These RSVP messages may be identified by their IP 722 protocol (RSVP-E2E-IGNORE, 134). When the ingress PE receives any 723 RSVP message with this IP protocol, it MUST process this frame as 724 if it is regular customer traffic and ignore any IP Router-Alert 725 flags. The appropriate VPN and transport labels are applied to 726 the frame and it is forwarded towards the remote CE. Note that 727 this message will not be received or processed by any other P or 728 PE node. 730 o Any SESSION-OF-INTEREST objects (defined in [RFC4860]) are to be 731 conveyed unmodified across the MPLS VPN. 733 7.4. Support for CE-CE RSVP-TE 735 [I-D.kumaki-l3vpn-e2e-rsvp-te-reqts] describes a set of requirements 736 for the establishment for CE-CE MPLS LSPs across networks offering an 737 L3VPN service. The requirements specified in that draft are similar 738 to those addressed by this document, in that both address the issue 739 of handling RSVP requests from customers in a VPN context. It is 740 possible that the solution described here could be adapted to meet 741 the requirements of [I-D.kumaki-l3vpn-e2e-rsvp-te-reqts]. To the 742 extent that this draft uses signalling extensions described in 743 [RFC3473] which have already been used for GMPLS/TE, we expect that 744 CE-CE RSVP/TE will be incremental work built on these extensions. 745 These extensions will be considered in a separate document. 747 8. Object Definitions 749 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects 751 The usage of the VPN-IPv4 SESSION Object is described in Section 3.1 752 and Section 3.2. The VPN-IPv4 SESSION object should appear in all 753 RSVP messages that ordinarily contain a SESSION object and are sent 754 between ingress PE and egress PE in either direction. The object 755 MUST NOT be included in any RSVP messages that are sent outside of 756 the provider's backbone (except in the inter-AS option B and C cases, 757 as described above, when it may appear on inter-AS links). The VPN- 758 IPv4 address in this object is built by combining the IPv4 address 759 from the incoming SESSION with the RD in the BGP advertisement from 760 the egress PE for this prefix and customer. 762 The VPN-IPv6 SESSION object is analogous to the VPN-IPv4 SESSION 763 object, using VPN-IPv6 addresses[RFC4659]. 765 The formats of the objects are as follows: 767 o VPN-IPv4 SESSION object: Class = 1, C-Type = TBA 769 +-------------+-------------+-------------+-------------+ 770 | | 771 + + 772 | VPN-IPv4 DestAddress (12 bytes) | 773 + + 774 | | 775 +-------------+-------------+-------------+-------------+ 776 | Protocol Id | Flags | DstPort | 777 +-------------+-------------+-------------+-------------+ 779 o VPN-IPv6 SESSION object: Class = 1, C-Type = TBA 781 +-------------+-------------+-------------+-------------+ 782 | | 783 + + 784 | | 785 + VPN-IPv6 DestAddress (24 bytes) + 786 / / 787 . . 788 / / 789 | | 790 +-------------+-------------+-------------+-------------+ 791 | Protocol Id | Flags | DstPort | 792 +-------------+-------------+-------------+-------------+ 794 The protocol ID, flags, and DstPort are identical to the IPv4 and 795 IPv6 SESSION objects. 797 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects 799 The usage of the VPN-IPv4 SENDER_TEMPLATE Object is described in 800 Section 3.1 and Section 3.2. The VPN-IPv4 SENDER_TEMPLATE object 801 should appear in all RSVP messages that ordinarily contain a 802 SENDER_TEMPLATE object and are sent between ingress PE and egress PE 803 in either direction (such as Path, PathError, and PathTear). The 804 object MUST NOT be included in any RSVP messages that are sent 805 outside of the provider's backbone (except in the inter-AS option B 806 and C cases, as described above, when it may appear on inter-AS 807 links). The VPN-IPv4 address in this object is built by combining 808 the IPv4 address from the incoming SENDER_TEMPLATE with the RD in the 809 BGP advertisement from the ingress PE for this prefix and customer. 810 The format of the object is as follows: 812 o VPN-IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = TBA 814 +-------------+-------------+-------------+-------------+ 815 | | 816 + + 817 | VPN-IPv4 SrcAddress (12 bytes) | 818 + + 819 | | 820 +-------------+-------------+-------------+-------------+ 821 | Reserved | SrcPort | 822 +-------------+-------------+-------------+-------------+ 824 o VPN-IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = TBA 826 +-------------+-------------+-------------+-------------+ 827 | | 828 + + 829 | | 830 + VPN-IPv6 SrcAddress (24 bytes) + 831 / / 832 . . 833 / / 834 | | 835 +-------------+-------------+-------------+-------------+ 836 | Reserved | SrcPort | 837 +-------------+-------------+-------------+-------------+ 839 The SrcPort is identical to the IPv4 and IPv6 SENDER_TEMPLATE 840 objects. The Reserved field must be set to zero on transmit and 841 ignored on receipt. 843 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects 845 The usage of the VPN-IPv4 FILTER_SPEC Object is described in 846 Section 3.3 and Section 3.4. The VPN-IPv4 FILTER_SPEC object should 847 appear in all RSVP messages that ordinarily contain a FILTER_SPEC 848 object and are sent between ingress PE and egress PE in either 849 direction (such as Resv, ResvError, and ResvTear). The object MUST 850 NOT be included in any RSVP messages that are sent outside of the 851 provider's backbone (except in the inter-AS option B and C cases, as 852 described above, when it may appear on inter-AS links). The VPN-IPv4 853 address in this object is built by combining the IPv4 address from 854 the incoming FILTER_SPEC with the RD in the BGP advertisement from 855 the ingress PE for this prefix and customer. 857 o VPN-IPv4 FILTER_SPEC object: Class = 10, C-Type = TBA 859 Definition same as VPN-IPv4 SENDER_TEMPLATE object. 861 o VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = TBA 863 Definition same as VPN-IPv6 SENDER_TEMPLATE object. 865 The protocol ID, flags, and DstPort are identical to the IPv4 and 866 IPv6 SESSION objects. 868 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects 870 Usage of the VPN-IPv4 RSVP_HOP Object is described in Section 5.2.2. 871 The VPN-IPv4 RSVP_HOP object is used to establish signalling 872 reachability between RSVP neighbors separated by one or more Option-B 873 ASBRs. This object may appear in all RSVP messages that carry a 874 RSVP_HOP object, and that travel between the Ingress and Egress PEs. 875 It MUST NOT be included in any RSVP messages that are sent outside of 876 the provider's backbone (except in the inter-AS option B and C cases, 877 as described above, when it may appear on inter-AS links). The 878 format of the object is as follows: 880 o VPN-IPv4 RSVP_HOP object: Class = 3, C-Type = TBA 882 +-------------+-------------+-------------+-------------+ 883 | IPv4 Next/Previous Hop Address (4 bytes) | 884 +-------------+-------------+-------------+-------------+ 885 | | 886 + + 887 | VPN-IPv4 Next/Previous Hop Address (12 bytes) | 888 + 889 + 890 | | 891 +-------------+-------------+-------------+-------------+ 892 | Logical Interface Handle | 893 +-------------+-------------+-------------+-------------+ 895 o VPN-IPv6 RSVP_HOP object: Class = 3, C-Type = TBA 897 +-------------+-------------+-------------+-------------+ 898 | | 899 + + 900 | | 901 + IPv6 Next/Previous Hop Address (16 bytes) + 902 | | 903 + + 904 | | 905 +-------------+-------------+-------------+-------------+ 906 | | 907 + + 908 | | 909 + VPN-IPv6 Next/Previous Hop Address (24 bytes) + 910 / / 911 . . 912 / / 913 | | 914 +-------------+-------------+-------------+-------------+ 915 | Logical Interface Handle | 916 +-------------+-------------+-------------+-------------+ 918 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects 920 The usage of Aggregated VPN-IPv4 SESSION object is described in 921 Section 7.3. The AGGREGATE-VPN-IPv4 SESSION object should appear in 922 all RSVP messages that ordinarily contain a AGGREGATE-IPv4 SESSION 923 object as defined in [RFC3175] and are sent between ingress PE and 924 egress PE in either direction. The GENERIC-AGGREGATE-VPN-IPv4 925 SESSION object should appear in all RSVP messages that ordinarily 926 contain a GENERIC-AGGREGATE-IPv4 SESSION object as defined in 927 [RFC4860] and are sent between ingress PE and egress PE in either 928 direction. These objects MUST NOT be included in any RSVP messages 929 that are sent outside of the provider's backbone (except in the 930 inter-AS option B and C cases, as described above, when it may appear 931 on inter-AS links). The processing rules for these objects are 932 otherwise identical to those of the VPN-IPv4 SESSION object defined 933 in Section 8.1. The VPN-IPv4 address in this object is built by 934 combining the IPv4 address from the incoming SESSION with the RD in 935 the BGP advertisement from the egress PE for this prefix and 936 customer. The format of the object is as follows: 938 o AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = TBA 940 +-------------+-------------+-------------+-------------+ 941 | | 942 + + 943 | VPN-IPv4 DestAddress (12 bytes) | 944 + + 945 | | 946 +-------------+-------------+-------------+-------------+ 947 | /////// | Flags | /////// | DSCP | 948 +-------------+-------------+-------------+-------------+ 950 o AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = TBA 952 +-------------+-------------+-------------+-------------+ 953 | | 954 + + 955 | | 956 + VPN-IPv6 DestAddress (24 bytes) + 957 / / 958 . . 959 / / 960 | | 961 +-------------+-------------+-------------+-------------+ 962 | Reserved | Flags | Reserved | DSCP | 963 +-------------+-------------+-------------+-------------+ 965 The flags and DSCP are identical to the AGGREGATE-IPv4 and AGGREGATE- 966 IPv6 SESSION objects. 968 o GENERIC-AGGREGATE-VPN-IPv4 SESSION object: 969 Class = 1, C-Type = TBA 971 +-------------+-------------+-------------+-------------+ 972 | | 973 + + 974 | VPN-IPv4 DestAddress (12 bytes) | 975 + + 976 | | 977 +-------------+-------------+-------------+-------------+ 978 | Reserved | Flags | PHB-ID | 979 +-------------+-------------+-------------+-------------+ 980 | Reserved | vDstPort | 981 +-------------+-------------+-------------+-------------+ 982 | Extended vDstPort | 983 +-------------+-------------+-------------+-------------+ 985 o GENERIC-AGGREGATE-VPN-IPv6 SESSION object: 986 Class = 1, C-Type = TBA 988 +-------------+-------------+-------------+-------------+ 989 | | 990 + + 991 | | 992 + VPN-IPv6 DestAddress (24 bytes) + 993 / / 994 . . 995 / / 996 | | 997 +-------------+-------------+-------------+-------------+ 998 | Reserved | Flags | PHB-ID | 999 +-------------+-------------+-------------+-------------+ 1000 | Reserved | vDstPort | 1001 +-------------+-------------+-------------+-------------+ 1002 | Extended vDstPort | 1003 +-------------+-------------+-------------+-------------+ 1005 The flags, PHB-ID, vDstPort and Extended vDstPort are identical to 1006 the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE-IPv6 SESSION 1007 objects. 1009 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 SENDER_TEMPLATE objects 1011 The usage of Aggregated VPN-IPv4 SENDER_TEMPLATE object is described 1012 in Section 7.3. The AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object should 1013 appear in all RSVP messages that ordinarily contain a AGGREGATE-IPv4 1014 SENDER_TEMPLATE object as defined in [RFC3175] and [RFC4860], and are 1015 sent between ingress PE and egress PE in either direction. These 1016 objects MUST NOT be included in any RSVP messages that are sent 1017 outside of the provider's backbone (except in the inter-AS option B 1018 and C cases, as described above, when it may appear on inter-AS 1019 links). The processing rules for these objects are otherwise 1020 identical to those of the VPN-IPv4 SENDER_TEMPLATE object defined in 1021 Section 8.2. The VPN-IPv4 address in this object is built by 1022 combining the IPv4 address from the incoming SENDER_TEMPLATE with the 1023 RD in the BGP advertisement from the ingress PE for this prefix and 1024 customer. The format of the object is as follows: 1026 o AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object: 1027 Class = 11, C-Type = TBA 1029 +-------------+-------------+-------------+-------------+ 1030 | | 1031 + + 1032 | VPN-IPv4 AggregatorAddress (12 bytes) | 1033 + + 1034 | | 1035 +-------------+-------------+-------------+-------------+ 1037 o AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object: 1038 Class = 11, C-Type = TBA 1040 +-------------+-------------+-------------+-------------+ 1041 | | 1042 + + 1043 | | 1044 + VPN-IPv6 AggregatorAddress (24 bytes) + 1045 / / 1046 . . 1047 / / 1048 | | 1049 +-------------+-------------+-------------+-------------+ 1051 The flags and DSCP are identical to the AGGREGATE-IPv4 and AGGREGATE- 1052 IPv6 SESSION objects. 1054 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC objects 1056 The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in 1057 Section 7.3. The AGGREGATE-VPN-IPv4 FILTER_SPEC object should appear 1058 in all RSVP messages that ordinarily contain a AGGREGATE-IPv4 1059 FILTER_SPEC object as defined in [RFC3175] and [RFC4860], and are 1060 sent between ingress PE and egress PE in either direction. These 1061 objects MUST NOT be included in any RSVP messages that are sent 1062 outside of the provider's backbone (except in the inter-AS option B 1063 and C cases, as described above, when it may appear on inter-AS 1064 links). The processing rules for these objects are otherwise 1065 identical to those of the VPN-IPv4 FILTER_SPEC object defined in 1066 Section 8.3. The VPN-IPv4 address in this object is built by 1067 combining the IPv4 address from the incoming FILTER_SPEC with the RD 1068 in the BGP advertisement from the ingress PE for this prefix and 1069 customer. The format of the object is as follows: 1071 o AGGREGATE-VPN-IPv4 FILTER_SPEC object: 1072 Class = 10, C-Type = TBA 1074 Definition same as AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object. 1076 o AGGREGATE-VPN-IPv6 FILTER_SPEC object: 1077 Class = 10, C-Type = TBA 1079 Definition same as AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object. 1081 9. IANA Considerations 1083 This document requires IANA assignment of new RSVP C-Types to 1084 accommodate the new objects described in Section 8. In addition, a 1085 new PathError code/value is required to identify a signalling 1086 reachability failure and the need for a VPN-IPv4 or VPN-IPv6 RSVP_HOP 1087 object as described in Section 5.2.2. 1089 10. Security Considerations 1091 [RFC4364] addresses the security considerations of BGP/MPLS VPNs in 1092 general. General RSVP security considerations are addressed in 1093 [RFC2205]. To ensure the integrity of RSVP, the RSVP Authentication 1094 mechanisms defined in [RFC2747] and [RFC3097]may be used. These 1095 protect RSVP message integrity hop-by-hop and provide node 1096 authentication as well as replay protection, thereby protecting 1097 against corruption and spoofing of RSVP messages. 1098 [I-D.behringer-tsvwg-rsvp-security-groupkeying] discusses 1099 applicability of various keying approaches for RSVP Authentication. 1100 We note that the RSVP signaling in MPLS VPN is likely to spread over 1101 multiple administrative domains (e.g. the service provider operating 1102 the VPN service, and the customers of the service). Therefore the 1103 considerations in [I-D.behringer-tsvwg-rsvp-security-groupkeying] 1104 about inter-domain issues are likely to apply. Since RSVP messages 1105 travel through the L3VPN cloud directly addressed to PE or ASBR 1106 routers (without IP Router-Alert), P routers remain isolated from 1107 RSVP messages signalling customer reservations. Providers MAY choose 1108 to block PEs from sending IP Router-Alert datagrams to P routers as a 1109 security practice, without impacting the functionality described 1110 herein. 1112 Beyond those general issues, four specific issues are introduced by 1113 this document: resource usage on PEs, resource usage in the provider 1114 backbone, PE route advertisement outside the AS, and signalling 1115 exposure to ASBRs and PEs. We discuss these in turn. 1117 A customer who makes resource reservations on the CE-PE links for his 1118 sites is only competing for link resources with himself, as in 1119 standard RSVP, at least in the common case where each CE-PE link is 1120 dedicated to a single customer. Thus, from the perspective of the 1121 CE-PE links, this draft does not introduce any new security issues. 1122 However, because a PE typically serves multiple customers, there is 1123 also the possibility that a customer might attempt to use excessive 1124 computational resources on a PE (CPU cycles, memory etc.) by sending 1125 large numbers of RSVP messages to a PE. In the extreme this could 1126 represent a form of denial-of-service attack. In order to prevent 1127 such an attack, a PE should have mechanisms to limit the fraction of 1128 its processing resources that can be consumed by any one CE or by the 1129 set of CEs of a given customer. For example, a PE might implement a 1130 form of rate limiting on RSVP messages that it receives from each CE. 1131 We observe that these security risks and measures related to PE 1132 resource usage are very similar for any control plane protocol 1133 operating between CE and PE (e.g. RSVP, routing, multicast) 1135 The second concern arises only when the service provider chooses to 1136 offer resource reservation across the backbone, as described in 1137 Section 4. In this case, the concern may be that a single customer 1138 might attempt to reserve a large fraction of backbone capacity, 1139 perhaps with a co-ordinated effort from several different CEs, thus 1140 denying service to other customers using the same backbone. 1141 [RFC4804] provides some guidance on the security issues when RSVP 1142 reservations are aggregated onto MPLS tunnels, which are applicable 1143 to the situation described here. We note that a provider may use 1144 local policy to limit the amount of resources that can be reserved by 1145 a given customer from a particular PE, and that a policy server could 1146 be used to control the resource usage of a given customer across 1147 multiple PEs if desired. 1149 A third issue may arise when Inter-AS Option B is used and admission 1150 control is not required on the inter-AS link (Section 5.2.2). In 1151 this case, the VPN PE includes a VPN-IPv4 address in the PHOP/NHOP 1152 objects it generates, which is used by the peer to determine a VPN 1153 label to communicate back with this PE. This results in a direct 1154 VPN-IPv4 route to a PE being exported to another AS, and potentially 1155 could allow customers to direct RSVP messages to remote PEs if those 1156 routes were advertised to the customers. However, as described in 1157 Section 5.2.2, a variety of techniques may be used to prevent such 1158 routes from being advertised to customers. Alternatively, ASBRs may 1159 implement the signalling procedures described in Section 5.2.1, even 1160 if admission control is not required on the inter-AS link, as these 1161 procedures do not require any direct P/PE route advertisement out of 1162 the AS. 1164 Finally, certain operations described herein (Section 3) require an 1165 ASBR or PE to receive and locally process a signalling packet 1166 addressed to the BGP next-hop address advertised by that router. 1167 This requirement does not strictly apply to MPLS/BGP VPNs [RFC4364]. 1168 This could be viewed as opening ASBRs and PEs to being directly 1169 addressable by customer devices where they were not open before, and 1170 could be considered a security issue. If a provider wishes to 1171 mitigate this situation, it would be possible to use one of the 1172 approaches described in Section 5.2.2 to prevent such routers from 1173 being reachable by customers. That is, whenever a signalling message 1174 is to be sent to a PE or ASBR, the address of the router in question 1175 would be looked up in the "control protocol" VPN, and the message 1176 would then be sent on the LSP that is found as a result of that 1177 lookup. This would allow the provider to restrict advertisement of 1178 PE and ASBR addresses so that these addresses are not reachable by 1179 customer devices. 1181 11. Acknowledgments 1183 Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric 1184 Rosen for their many contributions to solving the problems described 1185 in this draft. Thanks to Ferit Yegenoglu and Dan Tappan for their 1186 useful comments. 1188 Appendix A. Alternatives Considered 1190 At this stage a number of alternatives to the approach described 1191 above have been considered. We document some of the approaches 1192 considered here to assist future discussion. None of these has been 1193 shown to improve upon the approach described above, and the first two 1194 seem to have significant drawbacks relative to the approach described 1195 above. 1197 Appendix A.1. GMPLS UNI approach 1199 [RFC4208] defines the GMPLS UNI. In Section 7 the operation of the 1200 GMPLS UNI in a VPN context is briefly described. This is somewhat 1201 similar to the problem tackled in the current document. The main 1202 difference is that the GMPLS UNI is primarily aimed at the problem of 1203 allowing a CE device to request the establishment of an LSP across 1204 the network on the other side of the UNI. Hence the procedures in 1205 [RFC4208] would lead to the establishment of an LSP across the VPN 1206 provider's network for every RSVP request received, which is not 1207 desired in this case. 1209 To the extent possible, the approach described in this document is 1210 consistent with [RFC4208], while filling in more of the details and 1211 avoiding the problem noted above. 1213 Appendix A.2. VRF label approach 1215 Another approach to solving the problems described here involves the 1216 use of label switching to ensure that Path, Resv, and other RSVP 1217 messages are directed to the appropriate VRF. One challenge with 1218 such an approach is that [RFC4364] does not require labels to be 1219 allocated for VRFs, only for customer prefixes, and that there is no 1220 simple, existing method for advertising the fact that a label is 1221 bound to a VRF. If, for example, an ingress PE sent a Path message 1222 labelled with a VPN label that was advertised by the egress PE for 1223 the prefix that matches the destination address in the Path, there is 1224 a risk that the egress PE would simply label-switch the Path directly 1225 on to the CE without performing RSVP processing. 1227 A second challenge with this approach is that an IP address needs to 1228 be associated with a VRF and used as the PHOP address for the Path 1229 message sent from ingress PE to egress PE. That address must be 1230 reachable from the egress PE, and exist in the VRF at the ingress PE. 1231 Such an address is not always available in today's deployments, so 1232 this represents at least a change to existing deployment practices. 1234 Appendix A.3. VRF label plus VRF address approach 1236 It is possible to create an approach based on that described in the 1237 previous section which addresses the main challenges of that 1238 approach. The basic approach has two parts: (a) define a new BGP 1239 Extended Community to tag a route (and its associated MPLS label) as 1240 pointing to a VRF; (b) allocate a "dummy" address to each VRF, 1241 specifically to be used for routing RSVP messages. The dummy address 1242 (which could be anything, e.g. a loopback of the associated PE) would 1243 be used as a PHOP for Path messages and would serve as the 1244 destination for Resv messages but would not be imported into VRFs of 1245 any other PE. 1247 12. References 1249 12.1. Normative References 1251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1252 Requirement Levels", BCP 14, RFC 2119, March 1997. 1254 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1255 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1256 Functional Specification", RFC 2205, September 1997. 1258 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 1259 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 1260 RFC 3175, September 2001. 1262 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1263 Networks (VPNs)", RFC 4364, February 2006. 1265 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1266 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1267 IPv6 VPN", RFC 4659, September 2006. 1269 [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation 1270 Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", 1271 RFC 4804, February 2007. 1273 12.2. Informative References 1275 [I-D.behringer-tsvwg-rsvp-security-groupkeying] 1276 Behringer, M. and F. Faucheur, "Applicability of Keying 1277 Methods for RSVP Security", 1278 draft-behringer-tsvwg-rsvp-security-groupkeying-01 (work 1279 in progress), November 2007. 1281 [I-D.kumaki-l3vpn-e2e-rsvp-te-reqts] 1282 Kumaki, K., "Requirements for supporting Customer RSVP and 1283 RSVP-TE Over a BGP/MPLS IP-VPN", 1284 draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06 (work in 1285 progress), February 2008. 1287 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1288 Services in the Internet Architecture: an Overview", 1289 RFC 1633, June 1994. 1291 [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol 1292 (RSVP) -- Version 1 Message Processing Rules", RFC 2209, 1293 September 1997. 1295 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1296 Services", RFC 2210, September 1997. 1298 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1299 Authentication", RFC 2747, January 2000. 1301 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1302 and S. Molendini, "RSVP Refresh Overhead Reduction 1303 Extensions", RFC 2961, April 2001. 1305 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1306 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1307 Encoding", RFC 3032, January 2001. 1309 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 1310 Authentication -- Updated Message Type Value", RFC 3097, 1311 April 2001. 1313 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1314 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1315 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1317 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1318 Bosch, "Next Steps in Signaling (NSIS): Framework", 1319 RFC 4080, June 2005. 1321 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1322 Hierarchy with Generalized Multi-Protocol Label Switching 1323 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 1325 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1326 "Generalized Multiprotocol Label Switching (GMPLS) User- 1327 Network Interface (UNI): Resource ReserVation Protocol- 1328 Traffic Engineering (RSVP-TE) Support for the Overlay 1329 Model", RFC 4208, October 2005. 1331 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 1332 Davenport, "Generic Aggregate Resource ReSerVation 1333 Protocol (RSVP) Reservations", RFC 4860, May 2007. 1335 Authors' Addresses 1337 Bruce Davie 1338 Cisco Systems, Inc. 1339 1414 Mass. Ave. 1340 Boxborough, MA 01719 1341 USA 1343 Email: bsd@cisco.com 1345 Francois le Faucheur 1346 Cisco Systems, Inc. 1347 Village d'Entreprise Green Side - Batiment T3 1348 400, Avenue de Roumanille 1349 Biot Sophia-Antipolis 06410 1350 France 1352 Email: flefauch@cisco.com 1354 Ashok Narayanan 1355 Cisco Systems, Inc. 1356 1414 Mass. Ave. 1357 Boxborough, MA 01719 1358 USA 1360 Email: ashokn@cisco.com 1362 Full Copyright Statement 1364 Copyright (C) The IETF Trust (2008). 1366 This document is subject to the rights, licenses and restrictions 1367 contained in BCP 78, and except as set forth therein, the authors 1368 retain all their rights. 1370 This document and the information contained herein are provided on an 1371 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1372 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1373 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1374 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1375 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1376 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1378 Intellectual Property 1380 The IETF takes no position regarding the validity or scope of any 1381 Intellectual Property Rights or other rights that might be claimed to 1382 pertain to the implementation or use of the technology described in 1383 this document or the extent to which any license under such rights 1384 might or might not be available; nor does it represent that it has 1385 made any independent effort to identify any such rights. Information 1386 on the procedures with respect to rights in RFC documents can be 1387 found in BCP 78 and BCP 79. 1389 Copies of IPR disclosures made to the IETF Secretariat and any 1390 assurances of licenses to be made available, or the result of an 1391 attempt made to obtain a general license or permission for the use of 1392 such proprietary rights by implementers or users of this 1393 specification can be obtained from the IETF on-line IPR repository at 1394 http://www.ietf.org/ipr. 1396 The IETF invites any interested party to bring to its attention any 1397 copyrights, patents or patent applications, or other proprietary 1398 rights that may cover technology that may be required to implement 1399 this standard. Please address the information to the IETF at 1400 ietf-ipr@ietf.org.