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