idnits 2.17.1 draft-ietf-tsvwg-rsvp-l3vpn-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to 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 (May 28, 2009) is 5440 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1252, but not defined == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-19 == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-16 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Davie 3 Internet-Draft F. le Faucheur 4 Intended status: Standards Track A. Narayanan 5 Expires: November 29, 2009 Cisco Systems, Inc. 6 May 28, 2009 8 Support for RSVP in Layer 3 VPNs 9 draft-ietf-tsvwg-rsvp-l3vpn-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 29, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 RFC 4364 and RFC 4659 define an approach to building provider- 48 provisioned Layer 3 VPNs for IPv4 and IPv6. It may be desirable to 49 use RSVP to perform admission control on the links between CE and PE 50 routers. This document specifies procedures by which RSVP messages 51 travelling from CE to CE across an L3VPN may be appropriately handled 52 by PE routers so that admission control can be performed on PE-CE 53 links. Optionally, admission control across the provider's backbone 54 may also be supported. 56 Requirements Language 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [RFC2119]. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 67 2.1. Model of Operation . . . . . . . . . . . . . . . . . . . . 6 68 3. Admission Control on PE-CE Links . . . . . . . . . . . . . . . 7 69 3.1. New Objects of Type VPN-IPv4 . . . . . . . . . . . . . . . 8 70 3.2. Path Message Processing at Ingress PE . . . . . . . . . . 9 71 3.3. Path Message Processing at Egress PE . . . . . . . . . . . 10 72 3.4. Resv Processing at Egress PE . . . . . . . . . . . . . . . 11 73 3.5. Resv Processing at Ingress PE . . . . . . . . . . . . . . 11 74 3.6. Other RSVP Messages . . . . . . . . . . . . . . . . . . . 12 75 4. Admission Control in Provider's Backbone . . . . . . . . . . . 12 76 5. Inter-AS operation . . . . . . . . . . . . . . . . . . . . . . 13 77 5.1. Inter-AS Option A . . . . . . . . . . . . . . . . . . . . 13 78 5.2. Inter-AS Option B . . . . . . . . . . . . . . . . . . . . 14 79 5.2.1. Admission control on ASBR . . . . . . . . . . . . . . 14 80 5.2.2. No admission control on ASBR . . . . . . . . . . . . . 14 81 5.3. Inter-AS Option C . . . . . . . . . . . . . . . . . . . . 15 82 6. Operation with RSVP disabled . . . . . . . . . . . . . . . . . 16 83 7. Other RSVP procedures . . . . . . . . . . . . . . . . . . . . 16 84 7.1. Refresh overhead reduction . . . . . . . . . . . . . . . . 16 85 7.2. Cryptographic Authentication . . . . . . . . . . . . . . . 16 86 7.3. RSVP Aggregation . . . . . . . . . . . . . . . . . . . . . 17 87 7.4. Support for CE-CE RSVP-TE . . . . . . . . . . . . . . . . 17 88 8. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 18 89 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . . . . . . 18 90 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects . . . . . . 19 91 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects . . . . . . . . 20 92 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects . . . . . . . . . . 21 93 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . 23 94 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 95 SENDER_TEMPLATE objects . . . . . . . . . . . . . . . . . 25 96 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC 97 objects . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 100 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 101 Appendix A. Alternatives Considered . . . . . . . . . . . . . . 32 102 Appendix A.1. GMPLS UNI approach . . . . . . . . . . . . . . . . . 32 103 Appendix A.2. VRF label approach . . . . . . . . . . . . . . . . . 33 104 Appendix A.3. VRF label plus VRF address approach . . . . . . . . 33 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 106 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 107 12.2. Informative References . . . . . . . . . . . . . . . . . . 34 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 110 1. Introduction 112 [RFC4364] and [RFC4659] define a Layer 3 VPN service known as BGP/ 113 MPLS VPNs for IPv4 and for IPv6 respectively. [RFC2205] defines the 114 Resource Reservation Protocol (RSVP) which may be used to perform 115 admission control as part of the Integrated Services (Int-Serv) 116 architecture [RFC1633][RFC2210]. 118 Customers of a layer 3 VPN service may run RSVP for the purposes of 119 admission control (and associated resource reservation) in their own 120 networks. Since the links between Provider Edge (PE) and Customer 121 Edge (CE) routers in a layer 3 VPN may often be resource constrained, 122 it may be desirable to be able to perform admission control over 123 those links. In order to perform admission control using RSVP in 124 such an environment, it is necessary that RSVP control messages, such 125 as Path messages and Resv messages, are appropriately handled by the 126 PE routers. This presents a number of challenges in the context of 127 BGP/MPLS VPNs: 129 o RSVP Path message processing depends on routers recognizing the 130 router alert option in the IP header. However, packets traversing 131 the backbone of a BGP/MPLS VPN are MPLS encapsulated and thus the 132 router alert option is not normally visible to the egress PE. 134 o BGP/MPLS VPNs support non-unique addressing of customer networks. 135 Thus a PE at the ingress or egress of the provider backbone may be 136 called upon to process Path messages from different customer VPNs 137 with non-unique destination addresses. 139 o A PE at the ingress of the provider's backbone may receive Resv 140 messages corresponding to different customer VPNs from other PEs, 141 and needs to be able to associate those Resv messages with the 142 appropriate customer VPNs. 144 This document describes a set of procedures to overcome these 145 challenges and thus to enable admission control using RSVP over the 146 PE-CE links. We note that similar techniques may be applicable to 147 other protocols used for admission control such as the combination of 148 the NSIS Signaling Layer Protocol (NSLP) for QoS Signaling 149 ([I-D.ietf-nsis-qos-nslp]) and General Internet Signaling Transport 150 (GIST) protocol ([I-D.ietf-nsis-ntlp]). 152 Additionally, it may be desirable to perform admission control over 153 the provider's backbone on behalf of one or more L3VPN customers. 154 Core (P) routers in a BGP/MPLS VPN do not have forwarding entries for 155 customer routes, and thus cannot natively process RSVP messages for 156 customer flows. Also the core is a shared resource that carries 157 traffic for many customers, so issues of resource allocation among 158 customers and trust (or lack thereof) must also be addressed. This 159 draft also specifies procedures for supporting such a scenario. 161 This draft deals with establishing reservations for unicast flows 162 only. Because the support of multicast traffic in BGP/MPLS VPNs is 163 still evolving, and raises additional challenges for admission 164 control, we leave the support of multicast flows for further study at 165 this point. 167 1.1. Terminology 169 This document draws freely on the terminology defined in [RFC2205] 170 and [RFC4364]. For convenience, we provide a few brief definitions 171 here: 173 o CE (Customer Edge) Router: Router at the edge of a customer site 174 that attaches to the network of the VPN provider. 176 o PE (Provider Edge) Router: Router at the edge of the service 177 provider's network that attaches to one or more customer sites. 179 o VPN Label: An MPLS label associated with a route to a customer 180 prefix in a VPN (also called a VPN route label). 182 o VRF: VPN Routing and Forwarding Table. A PE typically has 183 multiple VRFs, enabling it to be connected to CEs that are in 184 different VPNs. 186 2. Problem Statement 188 The problem space of this document is the support of admission 189 control between customer sites when the customer subscribes to a BGP/ 190 MPLS VPN. We subdivide the problem into (a) the problem of admission 191 control on the PE-CE links (in both directions), and (b) the problem 192 of admission control across the provider's backbone. 194 For the PE-CE link subproblem, the most basic challenge is that RSVP 195 control messages contain IP addresses that are drawn from the 196 customer's address space, and PEs must be able to deal with traffic 197 from many customers who may have non-unique (or overlapping) address 198 spaces. Thus, it is essential that a PE be able in all cases to 199 identify the correct VPN context in which to process an RSVP control 200 message. Much of this draft deals with this issue. 202 For the case of making reservations across the provider backbone, we 203 observe that BGP/MPLS VPNs do not create any per-customer forwarding 204 state in the P (provider core) routers. Thus, in order to make 205 reservations on behalf of customer-specified flows, it is clearly 206 necessary to make some sort of aggregated reservation from PE-PE and 207 then map individual, customer-specific reservations onto an aggregate 208 reservation. That is similar to the problem tackled in [RFC3175] and 209 [RFC4804], with the additional complications of handling customer- 210 specific addressing associated with BGP/MPLS VPNs. 212 Finally, we note that RSVP Path messages are normally addressed to 213 the destination of a session, and contain the router alert IP option. 214 Routers along the path to the destination that are configured to 215 process RSVP messages must detect the presence of the router alert 216 option to allow them to intercept Path messages. However, the egress 217 PEs of a network supporting BGP/MPLS VPNs receive packets destined 218 for customer sites as MPLS-encapsulated packets, and may forward 219 those based only on examination of the MPLS label. Hence, a Path 220 message would be forwarded without examination of the IP options and 221 would therefore not receive appropriate processing at the PE. This 222 problem of recognizing and processing Path messages is also discussed 223 below. 225 2.1. Model of Operation 227 Figure 1 illustrates the basic model of operation with which this 228 document is concerned. 230 -------------------------- 231 / Provider \ 232 |----| | Backbone | |----| 233 Sender->| CE1| |-----| |-----| |CE2 |->Receiver 234 | |--| | |---| |---| | |---| | 235 |----| | | | P | | P | | | |----| 236 | PE1 |---| |-----| |-----| PE2 | 237 | | | | | | | | 238 | | |---| |---| | | 239 |-----| |-----| 240 | | 241 \ / 242 -------------------------- 244 Figure 1. Model of Operation for RSVP-based admission control over 245 MPLS/BGP VPN 247 To establish a unidirectional reservation for a point-to-point flow 248 from Sender to Receiver that takes account of resource availability 249 on the CE-PE and PE-CE links only, the following steps must take 250 place: 252 1. Sender sends a Path message to an IP address of the Receiver. 254 2. Path message is processed by CE1 using normal RSVP procedures 255 and forwarded towards the Receiver along the link CE1-PE1. 257 3. PE1 processes Path message and forwards towards the Receiver 258 across the provider backbone. 260 4. PE2 processes Path message and forwards towards the Receiver 261 along link PE2-CE2. 263 5. CE2 processes Path message using normal RSVP procedures and 264 forwards towards Receiver. 266 6. Receiver sends Resv message to CE2. 268 7. CE2 sends Resv message to PE2. 270 8. PE2 processes Resv message (including performing admission 271 control on link PE2-CE2) and sends Resv to PE1. 273 9. PE1 processes Resv message and sends Resv to CE1. 275 10. CE1 processes Resv using normal RSVP procedures, performs 276 admission control on the link CE1-PE1 and sends Resv message to 277 Sender if successful. 279 In each of the steps involving Resv messages (6 through 10) the node 280 sending the Resv uses the previously established Path state to 281 determine the "RSVP Previous Hop (PHOP)" and sends a Resv message to 282 that address. We note that establishing that Path state correctly at 283 PEs is one of the challenges posed by the BGP/MPLS environment. 285 3. Admission Control on PE-CE Links 287 In the following sections we trace through the steps outlined in 288 Section 2.1 and expand on the details for those steps where standard 289 RSVP procedures need to be extended or modified to support the BGP/ 290 MPLS VPN environment. For all the remaining steps described in the 291 preceding section, standard RSVP processing rules apply. 293 All the procedures described below support both IPv4 and IPv6 294 addressing. In all cases where IPv4 is referenced, IPv6 can be 295 substituted with identical procedures and results. Object 296 definitions for both IPv4 and IPv6 are provided in Section 8. 298 3.1. New Objects of Type VPN-IPv4 300 For RSVP signalling within a VPN, certain RSVP objects need to be 301 extended. Since customer IP addresses need not be unique, the 302 current types of SESSION, SENDER_TEMPLATE and FILTERSPEC objects are 303 no longer sufficient to globally identify RSVP states in P/PE 304 routers, since those are currently based on IP addresses. We propose 305 new types of SESSION, SENDER_TEMPLATE and FILTERSPEC objects, which 306 contain globally unique VPN-IPv4 format addresses. The ingress and 307 egress PE nodes translate between the regular IPv4 addresses for 308 messages to and from the CE, and VPN-IPv4 addresses for messages to 309 and from PE routers. The rules for this translation are described in 310 later sections. 312 The RSVP_HOP object in a RSVP message currently specifies an IP 313 address to be used by the neighboring RSVP hop to reply to the 314 message sender. However, MPLS VPN PE routers (especially those 315 separated by Option-B Autonomous System Border Routers -ASBRs) are 316 not required to have direct IP reachability to each other. To solve 317 this issue, we propose the use of label switching to forward RSVP 318 messages between nodes within a MPLS VPN. This is achieved by 319 defining a new VPN-IPv4 RSVP_HOP object. Use of the VPN-IPv4 320 RSVP_HOP object enables RSVP control plane reachability between any 321 two adjacent RSVP hops in a MPLS VPN (e.g. a PE in AS 1 and a PE in 322 AS2), regardless of whether they have IP reachability to each other. 324 The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message 325 sender and a logical interface handle as before, but in addition 326 carries a VPN-IPv4 address which also represents the sender of the 327 message. The message sender MUST also advertise this VPN-IPv4 HOP 328 address into BGP, associated with a locally allocated label, and this 329 advertisement MUST be propagated by BGP throughout the VPN and to 330 adjacent ASes if required to provide reachability to this PE. Frames 331 received by the PE marked with this label MUST be given to the local 332 control plane for processing. When a neighboring RSVP hop wishes to 333 reply to a message carrying a VPN-IPv4 RSVP_HOP, it looks for a BGP 334 advertisement of the VPN-IPv4 address contained in that RSVP_HOP. If 335 this address is found and carries an associated label, the 336 neighboring RSVP node MUST encapsulate the RSVP message with this 337 label and send it via MPLS encapsulation to the BGP next-hop 338 associated with the route. The destination IP address of the message 339 is taken from the IP address field of the RSVP_HOP object, as 340 described in [RFC2205]. Additionally, the IPv4 address in the 341 RSVP_HOP object continues to be used for all other existing purposes, 342 including neighbor matching between Path/Resv and SRefresh messages 343 ([RFC2961]), authentication ([RFC2747]), etc. 345 The VPN-IPv4 address used in the VPN-IPv4 RSVP_HOP object MAY 346 represent an existing address in the VRF that corresponds to the flow 347 (e.g. a local loopback or PE-CE link address within the VRF for this 348 customer), or MAY be created specially for this purpose. In the case 349 where the address is specially created for RSVP signaling (and 350 possibly other control protocols), the BGP advertisement MUST NOT be 351 redistributed to, or reachable by, any CEs outside the MPLS VPN. One 352 way to achieve this is by creating a special "control protocols VPN" 353 with VRF state on every PE/ASBR, carrying route targets not imported 354 into customer VRFs. In the case where a customer VRF address is used 355 as the VPN-IPv4 address, a VPN-IPv4 address in one customer VRF MUST 356 NOT be used to signal RSVP messages for a flow in a different VRF. 358 If a PE/ASBR is sending a Path message to another PE/ASBR within the 359 VPN, and it has any appropriate VPN-IPv4 address for signalling that 360 satisfies the requirements outlined above, it MUST use a VPN-IPv4 HOP 361 object with this address for all RSVP messages within the VPN. If a 362 PE/ASBR does not have any appropriate VPN-IPv4 address to use for 363 signalling, it MAY send the Path message with a regular IPv4 RSVP_HOP 364 object. In this case, the reply will be IP encapsulated. This 365 option is not preferred because there is no guarantee that the 366 neighboring RSVP hop has IP reachability to the sending node. If a 367 PE/ASBR receives or originates a Path message with a VPN-IPv4 368 RSVP_HOP object, any RSVP_HOP object in corresponding upstream 369 messages for this flow (e.g. Resv, ResvTear) or downstream messages 370 (e.g. ResvError, PathTear) sent by this node within the VPN MUST be 371 a VPN-IPv4 RSVP_HOP. 373 3.2. Path Message Processing at Ingress PE 375 When a Path message arrives at the ingress PE (step 3 of Section 2.1) 376 the PE needs to establish suitable Path state and forward the Path 377 message on to the egress PE. In the following paragraphs we 378 described the steps taken by the ingress PE. 380 The Path message is addressed to the eventual destination (the 381 receiver at the remote customer site) and carries the IP Router Alert 382 option, in accordance with [RFC2205]. The ingress PE must recognize 383 the router alert, intercept these messages and process them as RSVP 384 signalling messages. 386 As noted above, there is an issue in recognizing Path messages as 387 they arrive at the egress PE (PE 2 in Figure 1). The approach 388 defined here is to address the Path messages sent by the ingress PE 389 directly to the egress PE, and send it without IP Router Alert; that 390 is, rather than using the ultimate receiver's destination address as 391 the destination address of the Path message, we use the loopback 392 address of the egress PE as the destination address of the Path 393 message. This approach has the advantage that it does not require 394 any new data plane capabilities for the egress PE beyond those of a 395 standard BGP/MPLS VPN PE. Details of the processing of this message 396 at the egress PE are described below in Section 3.3. The approach of 397 addressing a Path message directly to an RSVP next hop (that may or 398 may not be the next IP hop) is already used in other environments 399 such as those of [RFC4206] and [RFC4804]. 401 The details of operation at the ingress PE are as follows. When the 402 ingress PE (PE1 in Figure 1) receives a Path message from CE1 that is 403 addressed to the receiver, the VRF that is associated with the 404 incoming interface is identified, just as for normal data path 405 operations. The Path state for the session is stored, and is 406 associated with that VRF, so that potentially overlapping addresses 407 among different VPNs do not appear to belong to the same session. 408 The destination address of the receiver is looked up in the 409 appropriate VRF, and the BGP Next-Hop for that destination is 410 identified. That next-hop is the egress PE (PE2 in Figure 1). A new 411 VPN-IPv4 SESSION object is constructed, containing the Route 412 Distinguisher (RD) that is part of the VPN-IPv4 route prefix for this 413 destination, and the IPv4 address from the SESSION. In addition, a 414 new VPN-IPv4 SENDER_TEMPLATE object is constructed, with the original 415 IPv4 address from the incoming SENDER_TEMPLATE plus the RD that is 416 used by this PE to advertise that prefix for this customer into the 417 VPN. A new Path message is constructed with a destination address 418 equal to the address of the egress PE identified above. This new 419 Path message will contain all the objects from the original Path 420 message, replacing the original SESSION and SENDER_TEMPLATE objects 421 with the new VPN-IPv4 type objects. The Path message is sent without 422 IP Router Alert and contains a RSVP_HOP object constructed as 423 specified in Section 3.1. 425 3.3. Path Message Processing at Egress PE 427 When a Path message arrives at the egress PE, it is addressed to the 428 PE itself, and is handed to RSVP for processing. The router extracts 429 the RD and IPv4 address from the VPN-IPv4 SESSION object, and 430 determines the local VRF context by finding a matching VPN-IPv4 431 prefix with the specified RD that has been advertised by this router 432 into BGP. The entire incoming RSVP message, including the VRF 433 information, is stored as part of the Path state. 435 Now the RSVP module can construct a Path message which differs from 436 the Path it received in the following ways: 438 a. Its destination address is the IP address extracted from the 439 SESSION Object; 441 b. The SESSION and SENDER_TEMPLATE objects are converted back to 442 IPv4-type by discarding the attached RD 444 c. The RSVP_HOP Object contains the IP address of the outgoing 445 interface of the egress PE and an LIH, as per normal RSVP 446 processing. 448 The router then sends the Path message on towards its destination 449 over the interface identified above. This Path message carries the 450 IP Router-Alert option as required by [RFC2205]. 452 3.4. Resv Processing at Egress PE 454 When a receiver at the customer site originates a Resv message for 455 the session, normal RSVP procedures apply until the Resv, making its 456 way back towards the sender, arrives at the "egress" PE (it is 457 "egress" with respect to the direction of data flow, i.e. PE2 in 458 figure 1). On arriving at PE2, the SESSION and FILTER_SPEC objects 459 in the Resv, and the VRF in which the Resv was received, are used to 460 find the matching Path state stored previously. At this stage, 461 admission control can be performed on the PE-CE link. 463 Assuming admission control is successful, the PE constructs a Resv 464 message to send to the RSVP HOP stored in the Path state, i.e., the 465 ingress PE (PE1 in Figure 1). The IPv4 SESSION object is replaced 466 with the same VPN-IPv4 SESSION object received in the Path. The IPv4 467 FILTER_SPEC object is replaced with a VPN-IPv4 FILTER_SPEC object, 468 which copies the VPN-IPv4 address from the SENDER_TEMPLATE received 469 in the matching Path message. The RSVP_HOP in the Resv message MUST 470 be constructed as specified in Section 3.1. The Resv message MUST be 471 addressed to the IP address contained within the RSVP_HOP object in 472 the Path message. If the Path message contained a VPN-IPv4 RSVP_HOP 473 object, the Resv MUST be MPLS-encapsulated using the label associated 474 with that VPN-IPv4 address in BGP, as described in Section 3.1. If 475 the Path message contained an IPv4 RSVP_HOP object, the Resv is 476 simply IP-encapsulated and addressed directly to the IP address in 477 the RSVP_HOP object. 479 If admission control is not successful on the egress PE, a ResvError 480 message is sent towards the receiver as per normal RSVP processing. 482 3.5. Resv Processing at Ingress PE 484 Upon receiving a Resv message at the ingress PE (with respect to data 485 flow, i.e. PE1 in Figure 1), the PE determines the local VRF context 486 and associated Path state for this Resv by decoding the received 487 SESSION and FILTER_SPEC objects. It is now possible to generate a 488 Resv message to send to the appropriate CE. The Resv message sent to 489 the ingress CE will contain IPv4 SESSION and FILTER_SPEC objects, 490 derived from the appropriate Path state. Since we assume in this 491 section that admission control over the Provider's backbone is not 492 needed, the ingress PE does not perform any admission control for 493 this reservation. 495 3.6. Other RSVP Messages 497 Processing of PathError, PathTear, ResvError, ResvTear and ResvConf 498 messages is generally straightforward and follows the rules of 499 [RFC2205]. These additional rules must be observed for messages 500 transmitted within the VPN (i.e. between the PEs): 502 o The SESSION, SENDER_TEMPLATE and FILTER_SPEC objects must be 503 converted from IPv4 to VPN-IPv4 form and back in the same manner 504 as described above for Path and Resv messages. 506 o The appropriate type of RSVP_HOP object (VPN-IPv4 or IPv4) must be 507 used as described above 509 o Depending on the type of RSVP HOP received from the neighbor, the 510 message must be MPLS-encapsulated or IP-encapsulated as described 511 above 513 o The matching state & VRF must be determined by decoding the RD and 514 IPv4 addresses in the SESSION and FILTER_SPEC objects. 516 o The message must be directly addressed to the appropriate PE, 517 without using the IP Router Alert option. 519 4. Admission Control in Provider's Backbone 521 The preceding section outlines how per-customer reservations can be 522 made over the PE-CE links. This may be sufficient in many situations 523 where the backbone is well engineered with ample capacity and there 524 is no need to perform any sort of admission control in the backbone. 525 However, in some cases where excess capacity cannot be relied upon 526 (e.g., during failures or unanticipated periods of overload) it may 527 be desirable to be able to perform admission control in the backbone 528 on behalf of customer traffic. 530 Because of the fact that routes to customer addresses are not present 531 in the P routers, along with the concerns of scalability that would 532 arise if per-customer reservations were allowed in the P routers, it 533 is clearly necessary to map the per-customer reservations described 534 in the preceding section onto some sort of aggregate reservations. 535 Furthermore, customer data packets need to be tunneled across the 536 provider backbone just as in normal BGP/MPLS VPN operation. 538 Given these considerations, a feasible way to achieve the objective 539 of admission control in the backbone is to use the ideas described in 540 [RFC4804]. MPLS-TE tunnels can be established between PEs as a means 541 to perform aggregate admission control in the backbone. 543 An MPLS-TE tunnel from an ingress PE to an egress PE can be thought 544 of as a virtual link of a certain capacity. The main change to the 545 procedures described above is that when a Resv is received at the 546 ingress PE, an admission control decision can be performed by 547 checking whether sufficient capacity of that virtual link remains 548 available to admit the new customer reservation. We note also that 549 [RFC4804] uses the IF_ID RSVP_HOP object to identify the tunnel 550 across the backbone, rather than the simple RSVP_HOP object described 551 in Section 3.2. The procedures of [RFC4804] should be followed here 552 as well. 554 To achieve effective admission control in the backbone, there needs 555 to be some way to separate the data plane traffic that has a 556 reservation from that which does not. We assume that packets that 557 are subject to admission control on the core will be given a 558 particular MPLS EXP value, and that no other packets will be allowed 559 to enter the core with this value unless they have passed admission 560 control. Some fraction of link resources will be allocated to queues 561 on core links for packets bearing that EXP value, and the MPLS-TE 562 tunnels will use that resource pool to make their constraint-based 563 routing and admission control decisions. This is all consistent with 564 the principles of aggregate RSVP reservations described in [RFC3175]. 566 5. Inter-AS operation 568 [RFC4364] defines three modes of inter-AS operation for MPLS/BGP 569 VPNs, referred to as options A, B and C. In the following sections we 570 describe how the scheme described above can operate in each inter-AS 571 environment. 573 5.1. Inter-AS Option A 575 Operation of RSVP in Inter-AS Option A is quite straightforward. 576 Each ASBR operates like a PE, and the ASBR-ASBR links can be viewed 577 as PE-CE links in terms of admission control. If the procedures 578 defined in Section 3 are enabled on both ASBRs, then admission 579 control may be performed on the inter-ASBR links. In addition, the 580 operator of each AS can independently decide whether or not to 581 perform admission control across his backbone. The new objects 582 described in this document MUST NOT be sent in any RSVP message 583 between two Option-A ASBRs. 585 5.2. Inter-AS Option B 587 To support inter-AS Option B, we require some additional processing 588 of RSVP messages on the ASBRs. Recall that, when packets are 589 forwarded from one AS to another in option B, the VPN label is 590 swapped by each ASBR as a packet goes from one AS to another. The 591 BGP next hop seen by the ingress PE will be the ASBR, and there need 592 not be IP visibility between the ingress and egress PEs. Hence when 593 the ingress PE sends the Path message to the BGP next hop of the VPN- 594 IPv4 route towards the destination, it will be received by the ASBR. 595 The ASBR determines the next hop of the route in a similar way as the 596 ingress PE - by finding a matching BGP VPN-IPv4 route with the same 597 RD and a matching prefix. 599 The provider(s) who interconnect ASes using option B may or may not 600 desire to perform admission control on the inter-AS links. This 601 choice affects the detailed operation of ASBRs. We describe the two 602 modes of operation - with and without admission control at the ASBRs 603 - in the following sections. 605 5.2.1. Admission control on ASBR 607 In this scenario, the ASBR performs full RSVP signalling and 608 admission control. The RSVP database is indexed on the ASBR using 609 the VPN-IPv4 SESSION, SENDER_TEMPLATE and FILTER_SPEC objects (which 610 uniquely identify RSVP sessions and flows as per the requirements of 611 [RFC2205]). These objects are forwarded unmodified in both 612 directions by the ASBR. All other procedures of RSVP are performed 613 as if the ASBR was a RSVP hop. In particular, the RSVP_HOP objects 614 sent in Path and Resv messages contain IP addresses of the ASBR, 615 which MUST be reachable by the neighbor to whom the message is being 616 sent. Note that since the VPN-IPv4 SESSION, SENDER_TEMPLATE and 617 FILTER_SPEC objects satisfy the uniqueness properties required for a 618 RSVP database implementation as per [RFC2209], no customer VRF 619 awareness is required on the ASBR. 621 5.2.2. No admission control on ASBR 623 If the ASBR is not doing admission control, it is desirable that per- 624 flow state not be maintained on the ASBR. This requires adjacent 625 RSVP hops (i.e. the ingress and egress PEs of the respective ASes) to 626 send RSVP messages directly between them. This is only possible if 627 they are MPLS-encapsulated. The use of the VPN-IPv4 HOP object 628 described in Section 3.1 is REQUIRED in this case. 630 When an ASBR that is not installing local RSVP state receives a Path 631 message, it looks up the next-hop of the matching BGP route as 632 described in Section 3.2, and sends the Path message to the next-hop, 633 without modifying any RSVP objects (including the RSVP_HOP). This 634 process is repeated at subsequent ASBRs until the Path message 635 arrives at a router that is installing local RSVP state (either the 636 ultimate egress PE, or an ASBR configured to perform admission 637 control). This router receives the Path and processes it as 638 described in Section 3.3 if it is a PE, or Section 5.2.1 if it is an 639 ASBR performing admission control. When this router sends the Resv 640 upstream, it looks up the routing table for a next-hop+label for the 641 VPN-IPv4 address in the PHOP, encapsulates the Resv with that label 642 and sends it upstream. This message will be received for control 643 processing directly on the upstream RSVP hop (that last updated the 644 RSVP_HOP field in the Path message), without any involvement of 645 intermediate ASBRs. 647 The ASBR is not expected to process any other RSVP messages apart 648 from the Path message as described above. The ASBR also does not 649 need to store any RSVP state. Note that any ASBR along the path that 650 wishes to do admission control or insert itself into the RSVP 651 signalling flow, may do so by writing its own RSVP_HOP object with 652 IPv4 and VPN-IPv4 address pointing to itself. 654 If an Option-B ASBR receives a RSVP Path message with an IPv4 655 RSVP_HOP, does not wish to perform admission control but is willing 656 to install local state for this flow, the ASBR MUST process and 657 forward RSVP signalling messages for this flow as described in 658 Section 5.2.1 (with the exception that it does not perform admission 659 control). If an Option-B ASBR receives a RSVP Path message with an 660 IPv4 RSVP_HOP, but does not wish to install local state or perform 661 admission control for this flow, the ASBR MUST NOT forward the Path 662 message. In addition, the ASBR SHOULD send a PathError message of 663 Error Code "RSVP over MPLS Problem"_, _Error Value "RSVP_HOP not 664 reachable across VPN" (see Section 9) signifying to the upstream RSVP 665 hop that the supplied RSVP_HOP object is insufficient to provide 666 reachability across this VPN. This failure condition is not expected 667 to be recoverable. 669 5.3. Inter-AS Option C 671 Operation of RSVP in Inter-AS Option C is also quite straightforward, 672 because there exists an LSP directly from ingress PE to egress PE. 673 In this case, there is no significant difference in operation from 674 the single AS case described in Section 3. Furthermore, if it is 675 desired to provide admission control from PE to PE, it can be done by 676 building an inter-AS TE tunnel and then using the procedures 677 described in Section 4. 679 6. Operation with RSVP disabled 681 It is often the case that RSVP will not be enabled on the PE-CE 682 links. In such an environment, a customer may reasonably expect that 683 RSVP messages sent into the L3 VPN network should be forwarded just 684 like any other IP datagrams. This transparency is useful when the 685 customer wishes to use RSVP within his own sites or perhaps to 686 perform admission control on the CE-PE links (in CE->PE direction 687 only), without involvement of the PEs. For this reason, a PE SHOULD 688 NOT discard or modify RSVP messages sent towards it from a CE when 689 RSVP is not enabled on the PE-CE links. Similarly a PE SHOULD NOT 690 discard or modify RSVP messages which are destined for one of its 691 attached CEs, even when RSVP is not enabled on those links. Note 692 that the presence of the router alert option in some RSVP messages 693 may cause them to be forwarded outside of the normal forwarding path, 694 but that the guidance of this paragraph still applies in that case. 695 Note also that this guidance applies regardless of whether RSVP-TE is 696 used in some, all, or none of the L3VPN network. 698 7. Other RSVP procedures 700 This section describes modifications to other RSVP procedures 701 introduced by MPLS VPNs 703 7.1. Refresh overhead reduction 705 The following points should be noted regarding RSVP refresh overhead 706 reduction ([RFC2961]) across a MPLS VPN: 708 o The hop between the ingress and egress PE of a VPN should be 709 considered as traversing one or more non-RSVP hops. As such, the 710 procedures described in Section 5.3 of [RFC2961] relating to non- 711 RSVP hops SHOULD be followed. 713 o The source IP address of a SRefresh message MUST match the IPv4 714 address signalled in the RSVP_HOP object contained in the 715 corresponding Path or Resv message. The IPv4 address in any 716 received VPN-IPv4 RSVP_HOP object MUST be used as the source 717 address of that message for this purpose. 719 7.2. Cryptographic Authentication 721 The following points should be noted regarding RSVP cryptographic 722 authentication ([RFC2747]) across a MPLS VPN: 724 o The IPv4 address in any received VPN-IPv4 RSVP_HOP object MUST be 725 used as the source address of that message for purposes of 726 identifying the security association. 728 o Forwarding of Challenge and Response messages MUST follow the same 729 rules as described above for hop-by-hop messages. Specifically, 730 if the originator of a Challenge/Response message has received a 731 VPN-IPv4 RSVP_HOP object from the corresponding neighbor, it MUST 732 use the label associated with that VPN-IPv4 address in BGP to 733 forward the Challenge/Response message. 735 7.3. RSVP Aggregation 737 [RFC3175] and [RFC4860] describe mechanisms to aggregate multiple 738 individual RSVP reservations into a single larger reservation on the 739 basis of a common DSCP/PHB for traffic classification. The following 740 points should be noted in this regard: 742 o The procedures described in this section apply only in the case 743 where the Aggregator and Deaggregator nodes are C/CE devices, and 744 the entire MPLS VPN lies within the Aggregation Region. The case 745 where the PE is also an Aggregator/Deaggregator is more complex 746 and not considered in this document. 748 o Aggregate RSVP sessions will be treated in the same way as regular 749 IPv4 RSVP sessions. To this end, all the procedures described in 750 Section 3 and Section 4 apply to aggregate RSVP sessions. New 751 SESSION, SENDER_TEMPLATE and FILTERSPEC objects are defined in 752 Section 8. 754 o End-To-End (E2E) RSVP sessions are passed unmodified through the 755 MPLS VPN. These RSVP messages may be identified by their IP 756 protocol (RSVP-E2E-IGNORE, 134). When the ingress PE receives any 757 RSVP message with this IP protocol, it MUST process this frame as 758 if it is regular customer traffic and ignore any IP Router-Alert 759 flags. The appropriate VPN and transport labels are applied to 760 the frame and it is forwarded towards the remote CE. Note that 761 this message will not be received or processed by any other P or 762 PE node. 764 o Any SESSION-OF-INTEREST objects (defined in [RFC4860]) are to be 765 conveyed unmodified across the MPLS VPN. 767 7.4. Support for CE-CE RSVP-TE 769 [I-D.kumaki-l3vpn-e2e-rsvp-te-reqts] describes a set of requirements 770 for the establishment for CE-CE MPLS LSPs across networks offering an 771 L3VPN service. The requirements specified in that draft are similar 772 to those addressed by this document, in that both address the issue 773 of handling RSVP requests from customers in a VPN context. It is 774 possible that the solution described here could be adapted to meet 775 the requirements of [I-D.kumaki-l3vpn-e2e-rsvp-te-reqts]. To the 776 extent that this draft uses signalling extensions described in 777 [RFC3473] which have already been used for GMPLS/TE, we expect that 778 CE-CE RSVP/TE will be incremental work built on these extensions. 779 These extensions will be considered in a separate document. 781 8. Object Definitions 783 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects 785 The usage of the VPN-IPv4 (or VPN-IPv6) SESSION Object is described 786 in Section 3.2 to Section 3.6. The VPN-IPv4 (or VPN-IPv6) SESSION 787 object appears in RSVP messages that ordinarily contain a SESSION 788 object and are sent between ingress PE and egress PE in either 789 direction. The object MUST NOT be included in any RSVP messages that 790 are sent outside of the provider's backbone (except in the inter-AS 791 option B and C cases, as described above, when it may appear on 792 inter-AS links). 794 The VPN-IPv6 SESSION object is analogous to the VPN-IPv4 SESSION 795 object, using an VPN-IPv6 address ([RFC4659]) instead of an VPN-IPv4 796 address ([RFC4364]). 798 The formats of the objects are as follows: 800 o VPN-IPv4 SESSION object: Class = 1, C-Type = TBA 802 +-------------+-------------+-------------+-------------+ 803 | | 804 + + 805 | VPN-IPv4 DestAddress (12 bytes) | 806 + + 807 | | 808 +-------------+-------------+-------------+-------------+ 809 | Protocol Id | Flags | DstPort | 810 +-------------+-------------+-------------+-------------+ 812 o VPN-IPv6 SESSION object: Class = 1, C-Type = TBA 814 +-------------+-------------+-------------+-------------+ 815 | | 816 + + 817 | | 818 + VPN-IPv6 DestAddress (24 bytes) + 819 / / 820 . . 821 / / 822 | | 823 +-------------+-------------+-------------+-------------+ 824 | Protocol Id | Flags | DstPort | 825 +-------------+-------------+-------------+-------------+ 827 The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field 828 contains an address of the VPN-IPv4 (respectively VPN-IPv6) address 829 family encoded as specified in [RFC4364] (respectively [RFC4659]). 830 The content of this field is discussed in Section 3.2 and 831 Section 3.3. 833 The protocol ID, flags, and DstPort are identical to the same fields 834 in the IPv4 and IPv6 SESSION objects ([RFC2205]). 836 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects 838 The usage of the VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE Object is 839 described in Section 3.2 and Section 3.3. The VPN-IPv4 (or VPN-IPv6) 840 SENDER_TEMPLATE object appears in RSVP messages that ordinarily 841 contain a SENDER_TEMPLATE object and are sent between ingress PE and 842 egress PE in either direction (such as Path, PathError, and 843 PathTear). The object MUST NOT be included in any RSVP messages that 844 are sent outside of the provider's backbone (except in the inter-AS 845 option B and C cases, as described above, when it may appear on 846 inter-AS links). The format of the object is as follows: 848 o VPN-IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = TBA 850 +-------------+-------------+-------------+-------------+ 851 | | 852 + + 853 | VPN-IPv4 SrcAddress (12 bytes) | 854 + + 855 | | 856 +-------------+-------------+-------------+-------------+ 857 | Reserved | SrcPort | 858 +-------------+-------------+-------------+-------------+ 860 o VPN-IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = TBA 862 +-------------+-------------+-------------+-------------+ 863 | | 864 + + 865 | | 866 + VPN-IPv6 SrcAddress (24 bytes) + 867 / / 868 . . 869 / / 870 | | 871 +-------------+-------------+-------------+-------------+ 872 | Reserved | SrcPort | 873 +-------------+-------------+-------------+-------------+ 875 The VPN-IPv4 SrcAddress (respectively VPN-IPv6 SrcAddress) field 876 contains an address of the VPN-IPv4 (respectively VPN-IPv6) address 877 family encoded as specified in [RFC4364] (respectively [RFC4659]). 878 The content of this field is discussed in Section 3.2 and 879 Section 3.3. 881 The SrcPort is identical to the SrcPort field in the IPv4 and IPv6 882 SENDER_TEMPLATE objects ([RFC2205]). 884 The Reserved field must be set to zero on transmit and ignored on 885 receipt. 887 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects 889 The usage of the VPN-IPv4 (or VPN-IPv6) FILTER_SPEC Object is 890 described in Section 3.4 and Section 3.5. The VPN-IPv4 (or VPN-IPv6) 891 FILTER_SPEC object appears in RSVP messages that ordinarily contain a 892 FILTER_SPEC object and are sent between ingress PE and egress PE in 893 either direction (such as Resv, ResvError, and ResvTear). The object 894 MUST NOT be included in any RSVP messages that are sent outside of 895 the provider's backbone (except in the inter-AS option B and C cases, 896 as described above, when it may appear on inter-AS links). 898 o VPN-IPv4 FILTER_SPEC object: Class = 10, C-Type = TBA 900 Definition same as VPN-IPv4 SENDER_TEMPLATE object. 902 o VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = TBA 904 Definition same as VPN-IPv6 SENDER_TEMPLATE object. 906 The content of the VPN-IPv4 SrcAddress (or VPN-IPv6 SrcAddress) field 907 is discussed in Section 3.4 and Section 3.5. 909 The SrcPort is identical to the SrcPort field in the IPv4 and IPv6 910 SENDER_TEMPLATE objects ([RFC2205]). 912 The Reserved field must be set to zero on transmit and ignored on 913 receipt. 915 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects 917 Usage of the VPN-IPv4 (or VPN-IPv6) RSVP_HOP Object is described in 918 Section 3.1 and Section 5.2.2. The VPN-IPv4 (VPN-IPv6) RSVP_HOP 919 object is used to establish signalling reachability between RSVP 920 neighbors separated by one or more Option-B ASBRs. This object may 921 appear in RSVP messages that carry a RSVP_HOP object, and that travel 922 between the Ingress and Egress PEs. It MUST NOT be included in any 923 RSVP messages that are sent outside of the provider's backbone 924 (except in the inter-AS option B and C cases, as described above, 925 when it may appear on inter-AS links). The format of the object is 926 as follows: 928 o VPN-IPv4 RSVP_HOP object: Class = 3, C-Type = TBA 930 +-------------+-------------+-------------+-------------+ 931 | IPv4 Next/Previous Hop Address (4 bytes) | 932 +-------------+-------------+-------------+-------------+ 933 | | 934 + + 935 | VPN-IPv4 Next/Previous Hop Address (12 bytes) | 936 + + 937 | | 938 +-------------+-------------+-------------+-------------+ 939 | Logical Interface Handle | 940 +-------------+-------------+-------------+-------------+ 942 o VPN-IPv6 RSVP_HOP object: Class = 3, C-Type = TBA 944 +-------------+-------------+-------------+-------------+ 945 | | 946 + + 947 | | 948 + IPv6 Next/Previous Hop Address (16 bytes) + 949 | | 950 + + 951 | | 952 +-------------+-------------+-------------+-------------+ 953 | | 954 + + 955 | | 956 + VPN-IPv6 Next/Previous Hop Address (24 bytes) + 957 / / 958 . . 959 / / 960 | | 961 +-------------+-------------+-------------+-------------+ 962 | Logical Interface Handle | 963 +-------------+-------------+-------------+-------------+ 965 The IPv4 Next/Previous Hop Address, IPv6 Next/Previous Hop Address 966 and the Logical Interface Handle fields are identical to those of the 967 RSVP_HOP object ([RFC2205]). 969 The VPN-IPv4 Next/Previous Hop Address (respectively VPN-IPv6 Next/ 970 Previous Hop Address) field contains an address of the VPN-IPv4 971 (respectively VPN-IPv6) address family encoded as specified in 972 [RFC4364] (respectively [RFC4659]). The content of this field is 973 discussed in Section 3.1. 975 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects 977 The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SESSION object is 978 described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively 979 AGGREGATE-IPv6-VPN) SESSION object appears in RSVP messages that 980 ordinarily contain a AGGREGATE-IPv4 (respectively AGGREGATE-IPv6) 981 SESSION object as defined in [RFC3175] and are sent between ingress 982 PE and egress PE in either direction. The GENERIC-AGGREGATE-VPN-IPv4 983 (respectively AGGREGATE-VPN-IPv6) SESSION object should appear in all 984 RSVP messages that ordinarily contain a GENERIC-AGGREGATE-IPv4 985 (respectively GENERIC-AGGREGATE-IPv6) SESSION object as defined in 986 [RFC4860] and are sent between ingress PE and egress PE in either 987 direction. These objects MUST NOT be included in any RSVP messages 988 that are sent outside of the provider's backbone (except in the 989 inter-AS option B and C cases, as described above, when it may appear 990 on inter-AS links). The processing rules for these objects are 991 otherwise identical to those of the VPN-IPv4 (respectively VPN-IPv6) 992 SESSION object defined in Section 8.1. The format of the object is 993 as follows: 995 o AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = TBA 997 +-------------+-------------+-------------+-------------+ 998 | | 999 + + 1000 | VPN-IPv4 DestAddress (12 bytes) | 1001 + + 1002 | | 1003 +-------------+-------------+-------------+-------------+ 1004 | /////// | Flags | /////// | DSCP | 1005 +-------------+-------------+-------------+-------------+ 1007 o AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = TBA 1009 +-------------+-------------+-------------+-------------+ 1010 | | 1011 + + 1012 | | 1013 + VPN-IPv6 DestAddress (24 bytes) + 1014 / / 1015 . . 1016 / / 1017 | | 1018 +-------------+-------------+-------------+-------------+ 1019 | Reserved | Flags | Reserved | DSCP | 1020 +-------------+-------------+-------------+-------------+ 1022 The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field 1023 contains an address of the VPN-IPv4 (respectively VPN-IPv6) address 1024 family encoded as specified in [RFC4364] (respectively [RFC4659]). 1025 The content of this field is discussed in Section 3.2 and 1026 Section 3.3. 1028 The flags and DSCP are identical to the same fields of the AGGREGATE- 1029 IPv4 and AGGREGATE-IPv6 SESSION objects ([RFC3175],). 1031 o GENERIC-AGGREGATE-VPN-IPv4 SESSION object: 1032 Class = 1, C-Type = TBA 1034 +-------------+-------------+-------------+-------------+ 1035 | | 1036 + + 1037 | VPN-IPv4 DestAddress (12 bytes) | 1038 + + 1039 | | 1040 +-------------+-------------+-------------+-------------+ 1041 | Reserved | Flags | PHB-ID | 1042 +-------------+-------------+-------------+-------------+ 1043 | Reserved | vDstPort | 1044 +-------------+-------------+-------------+-------------+ 1045 | Extended vDstPort | 1046 +-------------+-------------+-------------+-------------+ 1048 o GENERIC-AGGREGATE-VPN-IPv6 SESSION object: 1049 Class = 1, C-Type = TBA 1051 +-------------+-------------+-------------+-------------+ 1052 | | 1053 + + 1054 | | 1055 + VPN-IPv6 DestAddress (24 bytes) + 1056 / / 1057 . . 1058 / / 1059 | | 1060 +-------------+-------------+-------------+-------------+ 1061 | Reserved | Flags | PHB-ID | 1062 +-------------+-------------+-------------+-------------+ 1063 | Reserved | vDstPort | 1064 +-------------+-------------+-------------+-------------+ 1065 | Extended vDstPort | 1066 +-------------+-------------+-------------+-------------+ 1068 The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field 1069 contains an address of the VPN-IPv4 (respectively VPN-IPv6) address 1070 family encoded as specified in [RFC4364] (respectively [RFC4659]). 1071 The content of this field is discussed in Section 3.2 and 1072 Section 3.3. 1074 The flags, PHB-ID, vDstPort and Extended vDstPort are identical to 1075 the same fields of the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE- 1076 IPv6 SESSION objects ([RFC4860]). 1078 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 SENDER_TEMPLATE objects 1080 The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object 1081 is described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively 1082 AGGREGATE-VPN-IPv6) SENDER_TEMPLATE object appears in RSVP messages 1083 that ordinarily contain a AGGREGATE-IPv4 (respectively AGGREGATE- 1084 IPv6) SENDER_TEMPLATE object as defined in [RFC3175] and [RFC4860], 1085 and are sent between ingress PE and egress PE in either direction. 1086 These objects MUST NOT be included in any RSVP messages that are sent 1087 outside of the provider's backbone (except in the inter-AS option B 1088 and C cases, as described above, when it may appear on inter-AS 1089 links). The processing rules for these objects are otherwise 1090 identical to those of the VPN-IPv4 (respectively VPN-IPv6) 1091 SENDER_TEMPLATE object defined in Section 8.2. The format of the 1092 object is as follows: 1094 o AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object: 1095 Class = 11, C-Type = TBA 1097 +-------------+-------------+-------------+-------------+ 1098 | | 1099 + + 1100 | VPN-IPv4 AggregatorAddress (12 bytes) | 1101 + + 1102 | | 1103 +-------------+-------------+-------------+-------------+ 1105 o AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object: 1106 Class = 11, C-Type = TBA 1108 +-------------+-------------+-------------+-------------+ 1109 | | 1110 + + 1111 | | 1112 + VPN-IPv6 AggregatorAddress (24 bytes) + 1113 / / 1114 . . 1115 / / 1116 | | 1117 +-------------+-------------+-------------+-------------+ 1119 The VPN-IPv4 AggregatorAddress (respectively VPN-IPv6 1120 AggregatorAddress) field contains an address of the VPN-IPv4 1121 (respectively VPN-IPv6) address family encoded as specified in 1122 [RFC4364] (respectively [RFC4659]). The content and processing rules 1123 for these objects are similar to those of the VPN-IPv4 1124 SENDER_TEMPLATE object defined in Section 8.2. 1126 The flags and DSCP are identical to the same fields of the AGGREGATE- 1127 IPv4 and AGGREGATE-IPv6 SESSION objects. 1129 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC objects 1131 The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in 1132 Section 7.3. The AGGREGATE-VPN-IPv4 FILTER_SPEC object appears in 1133 RSVP messages that ordinarily contain a AGGREGATE-IPv4 FILTER_SPEC 1134 object as defined in [RFC3175] and [RFC4860], and are sent between 1135 ingress PE and egress PE in either direction. These objects MUST NOT 1136 be included in any RSVP messages that are sent outside of the 1137 provider's backbone (except in the inter-AS option B and C cases, as 1138 described above, when it may appear on inter-AS links). The 1139 processing rules for these objects are otherwise identical to those 1140 of the VPN-IPv4 FILTER_SPEC object defined in Section 8.3. The 1141 format of the object is as follows: 1143 o AGGREGATE-VPN-IPv4 FILTER_SPEC object: 1144 Class = 10, C-Type = TBA 1146 Definition same as AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object. 1148 o AGGREGATE-VPN-IPv6 FILTER_SPEC object: 1149 Class = 10, C-Type = TBA 1151 Definition same as AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object. 1153 9. IANA Considerations 1155 Section 8 defines new objects. Therefore, this document requests 1156 IANA to modify the RSVP parameters registry, 'Class Names, Class 1157 Numbers, and Class Types' subregistry, and: 1159 o assign six new C-Types under the existing SESSION Class (Class 1160 number 1), as suggested below: 1162 Class 1163 Number Class Name Reference 1164 ------ ----------------------- --------- 1166 1 SESSION [RFC2205] 1168 Class Types or C-Types: 1170 .. ... ... 1171 aa VPN-IPv4 [RFCXXXX] 1172 bb VPN-IPv6 [RFCXXXX] 1173 cc AGGREGATE-VPN-IPv4 [RFCXXXX] 1174 dd AGGREGATE-VPN-IPv6 [RFCXXXX] 1175 ee GENERIC-AGGREGATE-VPN-IPv4 [RFCXXXX] 1176 ff GENERIC-AGGREGATE-VPN-IPv6 [RFCXXXX] 1178 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1179 number of this specification. Suggested values: aa-ff=19-24] 1181 o assign four new C-Types under the existing SENDER_TEMPLATE Class 1182 (Class number 11), as suggested below: 1184 Class 1185 Number Class Name Reference 1186 ------ ----------------------- --------- 1188 11 SENDER_TEMPLATE [RFC2205] 1190 Class Types or C-Types: 1192 .. ... ... 1193 aa VPN-IPv4 [RFCXXXX] 1194 bb VPN-IPv6 [RFCXXXX] 1195 cc AGGREGATE-VPN-IPv4 [RFCXXXX] 1196 dd AGGREGATE-VPN-IPv6 [RFCXXXX] 1198 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1199 number of this specification. Suggested values: aa-dd=14-17] 1201 o assign four new C-Types under the existing FILTER_SPEC Class 1202 (Class number 10), as suggested below: 1204 Class 1205 Number Class Name Reference 1206 ------ ----------------------- --------- 1208 10 FILTER_SPEC [RFC2205] 1210 Class Types or C-Types: 1212 .. ... ... 1213 aa VPN-IPv4 [RFCXXXX] 1214 bb VPN-IPv6 [RFCXXXX] 1215 cc AGGREGATE-VPN-IPv4 [RFCXXXX] 1216 dd AGGREGATE-VPN-IPv6 [RFCXXXX] 1218 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1219 number of this specification. Suggested values: aa-dd=14-17] 1221 o assign two new C-Types under the existing RSVP_HOP Class (Class 1222 number 3), as suggested below: 1224 Class 1225 Number Class Name Reference 1226 ------ ----------------------- --------- 1228 3 RSVP_HOP [RFC2205] 1230 Class Types or C-Types: 1232 .. ... ... 1233 aa VPN-IPv4 [RFCXXXX] 1234 bb VPN-IPv6 [RFCXXXX] 1236 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1237 number of this specification. Suggested values: aa-bb=5-6] 1239 In addition, a new PathError code/value is required to identify a 1240 signalling reachability failure and the need for a VPN-IPv4 or VPN- 1241 IPv6 RSVP_HOP object as described in Section 5.2.2. Therefore, this 1242 document requests IANA to modify the RSVP parameters registry, 'Error 1243 Codes and Globally-Defined Error Value Sub-Codes' subregistry, and: 1245 o assign a new Error Code and sub-code, as suggested below: 1247 aa RSVP over MPLS Problem [RFCXXXX] 1249 This Error Code has the following globally-defined Error 1250 Value sub-codes: 1252 1 = RSVP_HOP not reachable across VPN [RFCXXXX] 1254 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1255 number of this specification. Suggested values: aa=34] 1257 10. Security Considerations 1259 [RFC4364] addresses the security considerations of BGP/MPLS VPNs in 1260 general. General RSVP security considerations are discussed in 1261 [RFC2205]. To ensure the integrity of RSVP, the RSVP Authentication 1262 mechanisms defined in [RFC2747] and [RFC3097] SHOULD be supported. 1263 Those protect RSVP message integrity hop-by-hop and provide node 1264 authentication as well as replay protection, thereby protecting 1265 against corruption and spoofing of RSVP messages. 1266 [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of 1267 various keying approaches for RSVP Authentication. First, we note 1268 that the discussion about applicability of group keying to an intra- 1269 provider environment where RSVP hops are not IP hops is relevant to 1270 securing of RSVP among PEs of a given Service Provider deploying the 1271 solution specified in the present document. We note that the RSVP 1272 signaling in MPLS VPN is likely to spread over multiple 1273 administrative domains (e.g. the service provider operating the VPN 1274 service, and the customers of the service). Therefore the 1275 considerations in [I-D.ietf-tsvwg-rsvp-security-groupkeying] about 1276 inter-domain issues are likely to apply. 1278 Since RSVP messages travel through the L3VPN cloud directly addressed 1279 to PE or ASBR routers (without IP Router-Alert), P routers remain 1280 isolated from RSVP messages signalling customer reservations. 1281 Providers MAY choose to block PEs from sending IP Router-Alert 1282 datagrams to P routers as a security practice, without impacting the 1283 functionality described herein. 1285 Beyond those general issues, four specific issues are introduced by 1286 this document: resource usage on PEs, resource usage in the provider 1287 backbone, PE route advertisement outside the AS, and signalling 1288 exposure to ASBRs and PEs. We discuss these in turn. 1290 A customer who makes resource reservations on the CE-PE links for his 1291 sites is only competing for link resources with himself, as in 1292 standard RSVP, at least in the common case where each CE-PE link is 1293 dedicated to a single customer. Thus, from the perspective of the 1294 CE-PE links, this draft does not introduce any new security issues. 1295 However, because a PE typically serves multiple customers, there is 1296 also the possibility that a customer might attempt to use excessive 1297 computational resources on a PE (CPU cycles, memory etc.) by sending 1298 large numbers of RSVP messages to a PE. In the extreme this could 1299 represent a form of denial-of-service attack. In order to prevent 1300 such an attack, a PE SHOULD support mechanisms to limit the fraction 1301 of its processing resources that can be consumed by any one CE or by 1302 the set of CEs of a given customer. For example, a PE might 1303 implement a form of rate limiting on RSVP messages that it receives 1304 from each CE. We observe that these security risks and measures 1305 related to PE resource usage are very similar for any control plane 1306 protocol operating between CE and PE (e.g. RSVP, routing, multicast) 1308 The second concern arises only when the service provider chooses to 1309 offer resource reservation across the backbone, as described in 1310 Section 4. In this case, the concern may be that a single customer 1311 might attempt to reserve a large fraction of backbone capacity, 1312 perhaps with a co-ordinated effort from several different CEs, thus 1313 denying service to other customers using the same backbone. 1314 [RFC4804] provides some guidance on the security issues when RSVP 1315 reservations are aggregated onto MPLS tunnels, which are applicable 1316 to the situation described here. We note that a provider MAY use 1317 local policy to limit the amount of resources that can be reserved by 1318 a given customer from a particular PE, and that a policy server could 1319 be used to control the resource usage of a given customer across 1320 multiple PEs if desired. It is RECOMMENDED that an implementation of 1321 this specification support local policy on the PE to control the 1322 amount of resources that can be reserved by a given customer/CE. 1324 Use of the VPN-IPv4 HOP object requires exporting a PE VPN-IPv4 route 1325 to another AS, and potentially could allow unchecked access to remote 1326 PEs if those routes were indiscriminately redistributed. However, as 1327 described in Section 3.1, no route which is not within a customer's 1328 VPN should ever be advertised to (or reachable from) that customer. 1329 If a PE uses a local address already within a customer VRF (like 1330 PE-CE link address), it MUST NOT send this address in any RSVP 1331 messages in a different customer VRF. A "control plane" VPN MAY be 1332 created across PEs and ASBRs and addresses in this VPN can be used to 1333 signal RSVP sessions for any customers, but these routes MUST NOT be 1334 advertised to, or made reachable from, any customer. An 1335 implementation of the present document MAY support such operation 1336 using a "control plane" VPN. Alternatively, ASBRs MAY implement the 1337 signalling procedures described in Section 5.2.1, even if admission 1338 control is not required on the inter-AS link, as these procedures do 1339 not require any direct P/PE route advertisement out of the AS. 1341 Finally, certain operations described herein (Section 3) require an 1342 ASBR or PE to receive and locally process a signalling packet 1343 addressed to the BGP next-hop address advertised by that router. 1344 This requirement does not strictly apply to MPLS/BGP VPNs [RFC4364]. 1345 This could be viewed as opening ASBRs and PEs to being directly 1346 addressable by customer devices where they were not open before, and 1347 could be considered a security issue. If a provider wishes to 1348 mitigate this situation, the implementation MAY support the "control 1349 protocol VPN" approach described above. That is, whenever a 1350 signalling message is to be sent to a PE or ASBR, the address of the 1351 router in question would be looked up in the "control protocol VPN", 1352 and the message would then be sent on the LSP that is found as a 1353 result of that lookup. This would ensure that the router address is 1354 not reachable by customer devices 1356 11. Acknowledgments 1358 Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric 1359 Rosen, Dan Tappan and Lou Berger for their many contributions to 1360 solving the problems described in this draft. Thanks to Ferit 1361 Yegenoglu for his useful comments. 1363 Appendix A. Alternatives Considered 1365 At this stage a number of alternatives to the approach described 1366 above have been considered. We document some of the approaches 1367 considered here to assist future discussion. None of these has been 1368 shown to improve upon the approach described above, and the first two 1369 seem to have significant drawbacks relative to the approach described 1370 above. 1372 Appendix A.1. GMPLS UNI approach 1374 [RFC4208] defines the GMPLS UNI. In Section 7 the operation of the 1375 GMPLS UNI in a VPN context is briefly described. This is somewhat 1376 similar to the problem tackled in the current document. The main 1377 difference is that the GMPLS UNI is primarily aimed at the problem of 1378 allowing a CE device to request the establishment of an LSP across 1379 the network on the other side of the UNI. Hence the procedures in 1380 [RFC4208] would lead to the establishment of an LSP across the VPN 1381 provider's network for every RSVP request received, which is not 1382 desired in this case. 1384 To the extent possible, the approach described in this document is 1385 consistent with [RFC4208], while filling in more of the details and 1386 avoiding the problem noted above. 1388 Appendix A.2. VRF label approach 1390 Another approach to solving the problems described here involves the 1391 use of label switching to ensure that Path, Resv, and other RSVP 1392 messages are directed to the appropriate VRF. One challenge with 1393 such an approach is that [RFC4364] does not require labels to be 1394 allocated for VRFs, only for customer prefixes, and that there is no 1395 simple, existing method for advertising the fact that a label is 1396 bound to a VRF. If, for example, an ingress PE sent a Path message 1397 labelled with a VPN label that was advertised by the egress PE for 1398 the prefix that matches the destination address in the Path, there is 1399 a risk that the egress PE would simply label-switch the Path directly 1400 on to the CE without performing RSVP processing. 1402 A second challenge with this approach is that an IP address needs to 1403 be associated with a VRF and used as the PHOP address for the Path 1404 message sent from ingress PE to egress PE. That address must be 1405 reachable from the egress PE, and exist in the VRF at the ingress PE. 1406 Such an address is not always available in today's deployments, so 1407 this represents at least a change to existing deployment practices. 1409 Appendix A.3. VRF label plus VRF address approach 1411 It is possible to create an approach based on that described in the 1412 previous section which addresses the main challenges of that 1413 approach. The basic approach has two parts: (a) define a new BGP 1414 Extended Community to tag a route (and its associated MPLS label) as 1415 pointing to a VRF; (b) allocate a "dummy" address to each VRF, 1416 specifically to be used for routing RSVP messages. The dummy address 1417 (which could be anything, e.g. a loopback of the associated PE) would 1418 be used as a PHOP for Path messages and would serve as the 1419 destination for Resv messages but would not be imported into VRFs of 1420 any other PE. 1422 12. References 1424 12.1. Normative References 1426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1427 Requirement Levels", BCP 14, RFC 2119, March 1997. 1429 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1430 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1431 Functional Specification", RFC 2205, September 1997. 1433 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 1434 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 1435 RFC 3175, September 2001. 1437 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1438 Networks (VPNs)", RFC 4364, February 2006. 1440 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1441 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1442 IPv6 VPN", RFC 4659, September 2006. 1444 [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation 1445 Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", 1446 RFC 4804, February 2007. 1448 12.2. Informative References 1450 [I-D.ietf-nsis-ntlp] 1451 Schulzrinne, H. and M. Stiemerling, "GIST: General 1452 Internet Signalling Transport", draft-ietf-nsis-ntlp-19 1453 (work in progress), March 2009. 1455 [I-D.ietf-nsis-qos-nslp] 1456 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 1457 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 1458 (work in progress), February 2008. 1460 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 1461 Behringer, M. and F. Faucheur, "Applicability of Keying 1462 Methods for RSVP Security", 1463 draft-ietf-tsvwg-rsvp-security-groupkeying-04 (work in 1464 progress), March 2009. 1466 [I-D.kumaki-l3vpn-e2e-rsvp-te-reqts] 1467 Kumaki, K., "Requirements for supporting Customer RSVP and 1468 RSVP-TE Over a BGP/MPLS IP-VPN", 1469 draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06 (work in 1470 progress), February 2008. 1472 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1473 Services in the Internet Architecture: an Overview", 1474 RFC 1633, June 1994. 1476 [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol 1477 (RSVP) -- Version 1 Message Processing Rules", RFC 2209, 1478 September 1997. 1480 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1481 Services", RFC 2210, September 1997. 1483 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1484 Authentication", RFC 2747, January 2000. 1486 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1487 and S. Molendini, "RSVP Refresh Overhead Reduction 1488 Extensions", RFC 2961, April 2001. 1490 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 1491 Authentication -- Updated Message Type Value", RFC 3097, 1492 April 2001. 1494 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1495 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1496 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1498 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1499 Hierarchy with Generalized Multi-Protocol Label Switching 1500 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 1502 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1503 "Generalized Multiprotocol Label Switching (GMPLS) User- 1504 Network Interface (UNI): Resource ReserVation Protocol- 1505 Traffic Engineering (RSVP-TE) Support for the Overlay 1506 Model", RFC 4208, October 2005. 1508 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 1509 Davenport, "Generic Aggregate Resource ReSerVation 1510 Protocol (RSVP) Reservations", RFC 4860, May 2007. 1512 Authors' Addresses 1514 Bruce Davie 1515 Cisco Systems, Inc. 1516 1414 Mass. Ave. 1517 Boxborough, MA 01719 1518 USA 1520 Email: bsd@cisco.com 1521 Francois le Faucheur 1522 Cisco Systems, Inc. 1523 Village d'Entreprise Green Side - Batiment T3 1524 400, Avenue de Roumanille 1525 Biot Sophia-Antipolis 06410 1526 France 1528 Email: flefauch@cisco.com 1530 Ashok Narayanan 1531 Cisco Systems, Inc. 1532 1414 Mass. Ave. 1533 Boxborough, MA 01719 1534 USA 1536 Email: ashokn@cisco.com