idnits 2.17.1 draft-ietf-tsvwg-rsvp-l3vpn-03.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 (October 26, 2009) is 5289 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 1253, 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-16 == 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: April 29, 2010 Cisco Systems, Inc. 6 October 26, 2009 8 Support for RSVP in Layer 3 VPNs 9 draft-ietf-tsvwg-rsvp-l3vpn-03.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 April 29, 2010. 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 Customer 50 Edge (CE) routers and Provider Edge (PE) routers. This document 51 specifies procedures by which RSVP messages travelling from CE to CE 52 across an L3VPN may be appropriately handled by PE routers so that 53 admission control can be performed on PE-CE links. Optionally, 54 admission control across the provider's backbone may also be 55 supported. 57 Requirements Language 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [RFC2119]. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. Model of Operation . . . . . . . . . . . . . . . . . . . . 6 69 3. Admission Control on PE-CE Links . . . . . . . . . . . . . . . 7 70 3.1. New Objects of Type VPN-IPv4 . . . . . . . . . . . . . . . 8 71 3.2. Path Message Processing at Ingress PE . . . . . . . . . . 9 72 3.3. Path Message Processing at Egress PE . . . . . . . . . . . 10 73 3.4. Resv Processing at Egress PE . . . . . . . . . . . . . . . 11 74 3.5. Resv Processing at Ingress PE . . . . . . . . . . . . . . 11 75 3.6. Other RSVP Messages . . . . . . . . . . . . . . . . . . . 12 76 4. Admission Control in Provider's Backbone . . . . . . . . . . . 12 77 5. Inter-AS operation . . . . . . . . . . . . . . . . . . . . . . 13 78 5.1. Inter-AS Option A . . . . . . . . . . . . . . . . . . . . 13 79 5.2. Inter-AS Option B . . . . . . . . . . . . . . . . . . . . 14 80 5.2.1. Admission control on ASBR . . . . . . . . . . . . . . 14 81 5.2.2. No admission control on ASBR . . . . . . . . . . . . . 14 82 5.3. Inter-AS Option C . . . . . . . . . . . . . . . . . . . . 15 83 6. Operation with RSVP disabled . . . . . . . . . . . . . . . . . 16 84 7. Other RSVP procedures . . . . . . . . . . . . . . . . . . . . 16 85 7.1. Refresh overhead reduction . . . . . . . . . . . . . . . . 16 86 7.2. Cryptographic Authentication . . . . . . . . . . . . . . . 16 87 7.3. RSVP Aggregation . . . . . . . . . . . . . . . . . . . . . 17 88 7.4. Support for CE-CE RSVP-TE . . . . . . . . . . . . . . . . 17 89 8. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 18 90 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . . . . . . 18 91 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects . . . . . . 19 92 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects . . . . . . . . 20 93 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects . . . . . . . . . . 21 94 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects . . . . . 23 95 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 96 SENDER_TEMPLATE objects . . . . . . . . . . . . . . . . . 25 97 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC 98 objects . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 100 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 101 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 102 Appendix A. Alternatives Considered . . . . . . . . . . . . . . 33 103 Appendix A.1. GMPLS UNI approach . . . . . . . . . . . . . . . . . 33 104 Appendix A.2. VRF label approach . . . . . . . . . . . . . . . . . 33 105 Appendix A.3. VRF label plus VRF address approach . . . . . . . . 34 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 107 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34 108 12.2. Informative References . . . . . . . . . . . . . . . . . . 34 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 111 1. Introduction 113 [RFC4364] and [RFC4659] define a Layer 3 VPN service known as BGP/ 114 MPLS VPNs for IPv4 and for IPv6 respectively. [RFC2205] defines the 115 Resource Reservation Protocol (RSVP) which may be used to perform 116 admission control as part of the Integrated Services (Int-Serv) 117 architecture [RFC1633][RFC2210]. 119 Customers of a layer 3 VPN service may run RSVP for the purposes of 120 admission control (and associated resource reservation) in their own 121 networks. Since the links between Provider Edge (PE) and Customer 122 Edge (CE) routers in a layer 3 VPN may often be resource constrained, 123 it may be desirable to be able to perform admission control over 124 those links. In order to perform admission control using RSVP in 125 such an environment, it is necessary that RSVP control messages, such 126 as Path messages and Resv messages, are appropriately handled by the 127 PE routers. This presents a number of challenges in the context of 128 BGP/MPLS VPNs: 130 o RSVP Path message processing depends on routers recognizing the 131 router alert option in the IP header. However, packets traversing 132 the backbone of a BGP/MPLS VPN are MPLS encapsulated and thus the 133 router alert option is not normally visible to the egress PE. 135 o BGP/MPLS VPNs support non-unique addressing of customer networks. 136 Thus a PE at the ingress or egress of the provider backbone may be 137 called upon to process Path messages from different customer VPNs 138 with non-unique destination addresses. 140 o A PE at the ingress of the provider's backbone may receive Resv 141 messages corresponding to different customer VPNs from other PEs, 142 and needs to be able to associate those Resv messages with the 143 appropriate customer VPNs. 145 This document describes a set of procedures to overcome these 146 challenges and thus to enable admission control using RSVP over the 147 PE-CE links. We note that similar techniques may be applicable to 148 other protocols used for admission control such as the combination of 149 the NSIS Signaling Layer Protocol (NSLP) for QoS Signaling 150 ([I-D.ietf-nsis-qos-nslp]) and General Internet Signaling Transport 151 (GIST) protocol ([I-D.ietf-nsis-ntlp]). 153 Additionally, it may be desirable to perform admission control over 154 the provider's backbone on behalf of one or more L3VPN customers. 155 Core (P) routers in a BGP/MPLS VPN do not have forwarding entries for 156 customer routes, and thus cannot natively process RSVP messages for 157 customer flows. Also the core is a shared resource that carries 158 traffic for many customers, so issues of resource allocation among 159 customers and trust (or lack thereof) must also be addressed. This 160 draft also specifies procedures for supporting such a scenario. 162 This draft deals with establishing reservations for unicast flows 163 only. Because the support of multicast traffic in BGP/MPLS VPNs is 164 still evolving, and raises additional challenges for admission 165 control, we leave the support of multicast flows for further study at 166 this point. 168 1.1. Terminology 170 This document draws freely on the terminology defined in [RFC2205] 171 and [RFC4364]. For convenience, we provide a few brief definitions 172 here: 174 o CE (Customer Edge) Router: Router at the edge of a customer site 175 that attaches to the network of the VPN provider. 177 o PE (Provider Edge) Router: Router at the edge of the service 178 provider's network that attaches to one or more customer sites. 180 o VPN Label: An MPLS label associated with a route to a customer 181 prefix in a VPN (also called a VPN route label). 183 o VRF: VPN Routing and Forwarding Table. A PE typically has 184 multiple VRFs, enabling it to be connected to CEs that are in 185 different VPNs. 187 2. Problem Statement 189 The problem space of this document is the support of admission 190 control between customer sites when the customer subscribes to a BGP/ 191 MPLS VPN. We subdivide the problem into (a) the problem of admission 192 control on the PE-CE links (in both directions), and (b) the problem 193 of admission control across the provider's backbone. 195 For the PE-CE link subproblem, the most basic challenge is that RSVP 196 control messages contain IP addresses that are drawn from the 197 customer's address space, and PEs must be able to deal with traffic 198 from many customers who may have non-unique (or overlapping) address 199 spaces. Thus, it is essential that a PE be able in all cases to 200 identify the correct VPN context in which to process an RSVP control 201 message. Much of this draft deals with this issue. 203 For the case of making reservations across the provider backbone, we 204 observe that BGP/MPLS VPNs do not create any per-customer forwarding 205 state in the P (provider core) routers. Thus, in order to make 206 reservations on behalf of customer-specified flows, it is clearly 207 necessary to make some sort of aggregated reservation from PE-PE and 208 then map individual, customer-specific reservations onto an aggregate 209 reservation. That is similar to the problem tackled in [RFC3175] and 210 [RFC4804], with the additional complications of handling customer- 211 specific addressing associated with BGP/MPLS VPNs. 213 Finally, we note that RSVP Path messages are normally addressed to 214 the destination of a session, and contain the router alert IP option. 215 Routers along the path to the destination that are configured to 216 process RSVP messages must detect the presence of the router alert 217 option to allow them to intercept Path messages. However, the egress 218 PEs of a network supporting BGP/MPLS VPNs receive packets destined 219 for customer sites as MPLS-encapsulated packets, and may forward 220 those based only on examination of the MPLS label. Hence, a Path 221 message would be forwarded without examination of the IP options and 222 would therefore not receive appropriate processing at the PE. This 223 problem of recognizing and processing Path messages is also discussed 224 below. 226 2.1. Model of Operation 228 Figure 1 illustrates the basic model of operation with which this 229 document is concerned. 231 -------------------------- 232 / Provider \ 233 |----| | Backbone | |----| 234 Sender->| CE1| |-----| |-----| |CE2 |->Receiver 235 | |--| | |---| |---| | |---| | 236 |----| | | | P | | P | | | |----| 237 | PE1 |---| |-----| |-----| PE2 | 238 | | | | | | | | 239 | | |---| |---| | | 240 |-----| |-----| 241 | | 242 \ / 243 -------------------------- 245 Figure 1. Model of Operation for RSVP-based admission control over 246 MPLS/BGP VPN 248 To establish a unidirectional reservation for a point-to-point flow 249 from Sender to Receiver that takes account of resource availability 250 on the CE-PE and PE-CE links only, the following steps must take 251 place: 253 1. Sender sends a Path message to an IP address of the Receiver. 255 2. Path message is processed by CE1 using normal RSVP procedures 256 and forwarded towards the Receiver along the link CE1-PE1. 258 3. PE1 processes Path message and forwards towards the Receiver 259 across the provider backbone. 261 4. PE2 processes Path message and forwards towards the Receiver 262 along link PE2-CE2. 264 5. CE2 processes Path message using normal RSVP procedures and 265 forwards towards Receiver. 267 6. Receiver sends Resv message to CE2. 269 7. CE2 sends Resv message to PE2. 271 8. PE2 processes Resv message (including performing admission 272 control on link PE2-CE2) and sends Resv to PE1. 274 9. PE1 processes Resv message and sends Resv to CE1. 276 10. CE1 processes Resv using normal RSVP procedures, performs 277 admission control on the link CE1-PE1 and sends Resv message to 278 Sender if successful. 280 In each of the steps involving Resv messages (6 through 10) the node 281 sending the Resv uses the previously established Path state to 282 determine the "RSVP Previous Hop (PHOP)" and sends a Resv message to 283 that address. We note that establishing that Path state correctly at 284 PEs is one of the challenges posed by the BGP/MPLS environment. 286 3. Admission Control on PE-CE Links 288 In the following sections we trace through the steps outlined in 289 Section 2.1 and expand on the details for those steps where standard 290 RSVP procedures need to be extended or modified to support the BGP/ 291 MPLS VPN environment. For all the remaining steps described in the 292 preceding section, standard RSVP processing rules apply. 294 All the procedures described below support both IPv4 and IPv6 295 addressing. In all cases where IPv4 is referenced, IPv6 can be 296 substituted with identical procedures and results. Object 297 definitions for both IPv4 and IPv6 are provided in Section 8. 299 3.1. New Objects of Type VPN-IPv4 301 For RSVP signalling within a VPN, certain RSVP objects need to be 302 extended. Since customer IP addresses need not be unique, the 303 current types of SESSION, SENDER_TEMPLATE and FILTERSPEC objects are 304 no longer sufficient to globally identify RSVP states in P/PE 305 routers, since those are currently based on IP addresses. We propose 306 new types of SESSION, SENDER_TEMPLATE and FILTERSPEC objects, which 307 contain globally unique VPN-IPv4 format addresses. The ingress and 308 egress PE nodes translate between the regular IPv4 addresses for 309 messages to and from the CE, and VPN-IPv4 addresses for messages to 310 and from PE routers. The rules for this translation are described in 311 later sections. 313 The RSVP_HOP object in a RSVP message currently specifies an IP 314 address to be used by the neighboring RSVP hop to reply to the 315 message sender. However, MPLS VPN PE routers (especially those 316 separated by Option-B Autonomous System Border Routers -ASBRs) are 317 not required to have direct IP reachability to each other. To solve 318 this issue, we propose the use of label switching to forward RSVP 319 messages between nodes within a MPLS VPN. This is achieved by 320 defining a new VPN-IPv4 RSVP_HOP object. Use of the VPN-IPv4 321 RSVP_HOP object enables RSVP control plane reachability between any 322 two adjacent RSVP hops in a MPLS VPN (e.g. a PE in AS 1 and a PE in 323 AS2), regardless of whether they have IP reachability to each other. 325 The VPN-IPv4 RSVP_HOP object carries the IPv4 address of the message 326 sender and a logical interface handle as before, but in addition 327 carries a VPN-IPv4 address which also represents the sender of the 328 message. The message sender MUST also advertise this VPN-IPv4 HOP 329 address into BGP, associated with a locally allocated label, and this 330 advertisement MUST be propagated by BGP throughout the VPN and to 331 adjacent ASes if required to provide reachability to this PE. Frames 332 received by the PE marked with this label MUST be given to the local 333 control plane for processing. When a neighboring RSVP hop wishes to 334 reply to a message carrying a VPN-IPv4 RSVP_HOP, it looks for a BGP 335 advertisement of the VPN-IPv4 address contained in that RSVP_HOP. If 336 this address is found and carries an associated label, the 337 neighboring RSVP node MUST encapsulate the RSVP message with this 338 label and send it via MPLS encapsulation to the BGP next-hop 339 associated with the route. The destination IP address of the message 340 is taken from the IP address field of the RSVP_HOP object, as 341 described in [RFC2205]. Additionally, the IPv4 address in the 342 RSVP_HOP object continues to be used for all other existing purposes, 343 including neighbor matching between Path/Resv and SRefresh messages 344 ([RFC2961]), authentication ([RFC2747]), etc. 346 The VPN-IPv4 address used in the VPN-IPv4 RSVP_HOP object MAY 347 represent an existing address in the VRF that corresponds to the flow 348 (e.g. a local loopback or PE-CE link address within the VRF for this 349 customer), or MAY be created specially for this purpose. In the case 350 where the address is specially created for RSVP signaling (and 351 possibly other control protocols), the BGP advertisement MUST NOT be 352 redistributed to, or reachable by, any CEs outside the MPLS VPN. One 353 way to achieve this is by creating a special "control protocols VPN" 354 with VRF state on every PE/ASBR, carrying route targets not imported 355 into customer VRFs. In the case where a customer VRF address is used 356 as the VPN-IPv4 address, a VPN-IPv4 address in one customer VRF MUST 357 NOT be used to signal RSVP messages for a flow in a different VRF. 359 If a PE/ASBR is sending a Path message to another PE/ASBR within the 360 VPN, and it has any appropriate VPN-IPv4 address for signalling that 361 satisfies the requirements outlined above, it MUST use a VPN-IPv4 HOP 362 object with this address for all RSVP messages within the VPN. If a 363 PE/ASBR does not have any appropriate VPN-IPv4 address to use for 364 signalling, it MAY send the Path message with a regular IPv4 RSVP_HOP 365 object. In this case, the reply will be IP encapsulated. This 366 option is not preferred because there is no guarantee that the 367 neighboring RSVP hop has IP reachability to the sending node. If a 368 PE/ASBR receives or originates a Path message with a VPN-IPv4 369 RSVP_HOP object, any RSVP_HOP object in corresponding upstream 370 messages for this flow (e.g. Resv, ResvTear) or downstream messages 371 (e.g. ResvError, PathTear) sent by this node within the VPN MUST be 372 a VPN-IPv4 RSVP_HOP. 374 3.2. Path Message Processing at Ingress PE 376 When a Path message arrives at the ingress PE (step 3 of Section 2.1) 377 the PE needs to establish suitable Path state and forward the Path 378 message on to the egress PE. In the following paragraphs we 379 described the steps taken by the ingress PE. 381 The Path message is addressed to the eventual destination (the 382 receiver at the remote customer site) and carries the IP Router Alert 383 option, in accordance with [RFC2205]. The ingress PE must recognize 384 the router alert, intercept these messages and process them as RSVP 385 signalling messages. 387 As noted above, there is an issue in recognizing Path messages as 388 they arrive at the egress PE (PE 2 in Figure 1). The approach 389 defined here is to address the Path messages sent by the ingress PE 390 directly to the egress PE, and send it without IP Router Alert; that 391 is, rather than using the ultimate receiver's destination address as 392 the destination address of the Path message, we use the loopback 393 address of the egress PE as the destination address of the Path 394 message. This approach has the advantage that it does not require 395 any new data plane capabilities for the egress PE beyond those of a 396 standard BGP/MPLS VPN PE. Details of the processing of this message 397 at the egress PE are described below in Section 3.3. The approach of 398 addressing a Path message directly to an RSVP next hop (that may or 399 may not be the next IP hop) is already used in other environments 400 such as those of [RFC4206] and [RFC4804]. 402 The details of operation at the ingress PE are as follows. When the 403 ingress PE (PE1 in Figure 1) receives a Path message from CE1 that is 404 addressed to the receiver, the VRF that is associated with the 405 incoming interface is identified, just as for normal data path 406 operations. The Path state for the session is stored, and is 407 associated with that VRF, so that potentially overlapping addresses 408 among different VPNs do not appear to belong to the same session. 409 The destination address of the receiver is looked up in the 410 appropriate VRF, and the BGP Next-Hop for that destination is 411 identified. That next-hop is the egress PE (PE2 in Figure 1). A new 412 VPN-IPv4 SESSION object is constructed, containing the Route 413 Distinguisher (RD) that is part of the VPN-IPv4 route prefix for this 414 destination, and the IPv4 address from the SESSION. In addition, a 415 new VPN-IPv4 SENDER_TEMPLATE object is constructed, with the original 416 IPv4 address from the incoming SENDER_TEMPLATE plus the RD that is 417 used by this PE to advertise that prefix for this customer into the 418 VPN. A new Path message is constructed with a destination address 419 equal to the address of the egress PE identified above. This new 420 Path message will contain all the objects from the original Path 421 message, replacing the original SESSION and SENDER_TEMPLATE objects 422 with the new VPN-IPv4 type objects. The Path message is sent without 423 IP Router Alert and contains a RSVP_HOP object constructed as 424 specified in Section 3.1. 426 3.3. Path Message Processing at Egress PE 428 When a Path message arrives at the egress PE, it is addressed to the 429 PE itself, and is handed to RSVP for processing. The router extracts 430 the RD and IPv4 address from the VPN-IPv4 SESSION object, and 431 determines the local VRF context by finding a matching VPN-IPv4 432 prefix with the specified RD that has been advertised by this router 433 into BGP. The entire incoming RSVP message, including the VRF 434 information, is stored as part of the Path state. 436 Now the RSVP module can construct a Path message which differs from 437 the Path it received in the following ways: 439 a. Its destination address is the IP address extracted from the 440 SESSION Object; 442 b. The SESSION and SENDER_TEMPLATE objects are converted back to 443 IPv4-type by discarding the attached RD 445 c. The RSVP_HOP Object contains the IP address of the outgoing 446 interface of the egress PE and an LIH, as per normal RSVP 447 processing. 449 The router then sends the Path message on towards its destination 450 over the interface identified above. This Path message carries the 451 IP Router-Alert option as required by [RFC2205]. 453 3.4. Resv Processing at Egress PE 455 When a receiver at the customer site originates a Resv message for 456 the session, normal RSVP procedures apply until the Resv, making its 457 way back towards the sender, arrives at the "egress" PE (it is 458 "egress" with respect to the direction of data flow, i.e. PE2 in 459 figure 1). On arriving at PE2, the SESSION and FILTER_SPEC objects 460 in the Resv, and the VRF in which the Resv was received, are used to 461 find the matching Path state stored previously. At this stage, 462 admission control can be performed on the PE-CE link. 464 Assuming admission control is successful, the PE constructs a Resv 465 message to send to the RSVP HOP stored in the Path state, i.e., the 466 ingress PE (PE1 in Figure 1). The IPv4 SESSION object is replaced 467 with the same VPN-IPv4 SESSION object received in the Path. The IPv4 468 FILTER_SPEC object is replaced with a VPN-IPv4 FILTER_SPEC object, 469 which copies the VPN-IPv4 address from the SENDER_TEMPLATE received 470 in the matching Path message. The RSVP_HOP in the Resv message MUST 471 be constructed as specified in Section 3.1. The Resv message MUST be 472 addressed to the IP address contained within the RSVP_HOP object in 473 the Path message. If the Path message contained a VPN-IPv4 RSVP_HOP 474 object, the Resv MUST be MPLS-encapsulated using the label associated 475 with that VPN-IPv4 address in BGP, as described in Section 3.1. If 476 the Path message contained an IPv4 RSVP_HOP object, the Resv is 477 simply IP-encapsulated and addressed directly to the IP address in 478 the RSVP_HOP object. 480 If admission control is not successful on the egress PE, a ResvError 481 message is sent towards the receiver as per normal RSVP processing. 483 3.5. Resv Processing at Ingress PE 485 Upon receiving a Resv message at the ingress PE (with respect to data 486 flow, i.e. PE1 in Figure 1), the PE determines the local VRF context 487 and associated Path state for this Resv by decoding the received 488 SESSION and FILTER_SPEC objects. It is now possible to generate a 489 Resv message to send to the appropriate CE. The Resv message sent to 490 the ingress CE will contain IPv4 SESSION and FILTER_SPEC objects, 491 derived from the appropriate Path state. Since we assume in this 492 section that admission control over the Provider's backbone is not 493 needed, the ingress PE does not perform any admission control for 494 this reservation. 496 3.6. Other RSVP Messages 498 Processing of PathError, PathTear, ResvError, ResvTear and ResvConf 499 messages is generally straightforward and follows the rules of 500 [RFC2205]. These additional rules must be observed for messages 501 transmitted within the VPN (i.e. between the PEs): 503 o The SESSION, SENDER_TEMPLATE and FILTER_SPEC objects must be 504 converted from IPv4 to VPN-IPv4 form and back in the same manner 505 as described above for Path and Resv messages. 507 o The appropriate type of RSVP_HOP object (VPN-IPv4 or IPv4) must be 508 used as described above 510 o Depending on the type of RSVP HOP received from the neighbor, the 511 message must be MPLS-encapsulated or IP-encapsulated as described 512 above 514 o The matching state & VRF must be determined by decoding the RD and 515 IPv4 addresses in the SESSION and FILTER_SPEC objects. 517 o The message must be directly addressed to the appropriate PE, 518 without using the IP Router Alert option. 520 4. Admission Control in Provider's Backbone 522 The preceding section outlines how per-customer reservations can be 523 made over the PE-CE links. This may be sufficient in many situations 524 where the backbone is well engineered with ample capacity and there 525 is no need to perform any sort of admission control in the backbone. 526 However, in some cases where excess capacity cannot be relied upon 527 (e.g., during failures or unanticipated periods of overload) it may 528 be desirable to be able to perform admission control in the backbone 529 on behalf of customer traffic. 531 Because of the fact that routes to customer addresses are not present 532 in the P routers, along with the concerns of scalability that would 533 arise if per-customer reservations were allowed in the P routers, it 534 is clearly necessary to map the per-customer reservations described 535 in the preceding section onto some sort of aggregate reservations. 536 Furthermore, customer data packets need to be tunneled across the 537 provider backbone just as in normal BGP/MPLS VPN operation. 539 Given these considerations, a feasible way to achieve the objective 540 of admission control in the backbone is to use the ideas described in 541 [RFC4804]. MPLS-TE tunnels can be established between PEs as a means 542 to perform aggregate admission control in the backbone. 544 An MPLS-TE tunnel from an ingress PE to an egress PE can be thought 545 of as a virtual link of a certain capacity. The main change to the 546 procedures described above is that when a Resv is received at the 547 ingress PE, an admission control decision can be performed by 548 checking whether sufficient capacity of that virtual link remains 549 available to admit the new customer reservation. We note also that 550 [RFC4804] uses the IF_ID RSVP_HOP object to identify the tunnel 551 across the backbone, rather than the simple RSVP_HOP object described 552 in Section 3.2. The procedures of [RFC4804] should be followed here 553 as well. 555 To achieve effective admission control in the backbone, there needs 556 to be some way to separate the data plane traffic that has a 557 reservation from that which does not. We assume that packets that 558 are subject to admission control on the core will be given a 559 particular MPLS EXP value, and that no other packets will be allowed 560 to enter the core with this value unless they have passed admission 561 control. Some fraction of link resources will be allocated to queues 562 on core links for packets bearing that EXP value, and the MPLS-TE 563 tunnels will use that resource pool to make their constraint-based 564 routing and admission control decisions. This is all consistent with 565 the principles of aggregate RSVP reservations described in [RFC3175]. 567 5. Inter-AS operation 569 [RFC4364] defines three modes of inter-AS operation for MPLS/BGP 570 VPNs, referred to as options A, B and C. In the following sections we 571 describe how the scheme described above can operate in each inter-AS 572 environment. 574 5.1. Inter-AS Option A 576 Operation of RSVP in Inter-AS Option A is quite straightforward. 577 Each ASBR operates like a PE, and the ASBR-ASBR links can be viewed 578 as PE-CE links in terms of admission control. If the procedures 579 defined in Section 3 are enabled on both ASBRs, then admission 580 control may be performed on the inter-ASBR links. In addition, the 581 operator of each AS can independently decide whether or not to 582 perform admission control across his backbone. The new objects 583 described in this document MUST NOT be sent in any RSVP message 584 between two Option-A ASBRs. 586 5.2. Inter-AS Option B 588 To support inter-AS Option B, we require some additional processing 589 of RSVP messages on the ASBRs. Recall that, when packets are 590 forwarded from one AS to another in option B, the VPN label is 591 swapped by each ASBR as a packet goes from one AS to another. The 592 BGP next hop seen by the ingress PE will be the ASBR, and there need 593 not be IP visibility between the ingress and egress PEs. Hence when 594 the ingress PE sends the Path message to the BGP next hop of the VPN- 595 IPv4 route towards the destination, it will be received by the ASBR. 596 The ASBR determines the next hop of the route in a similar way as the 597 ingress PE - by finding a matching BGP VPN-IPv4 route with the same 598 RD and a matching prefix. 600 The provider(s) who interconnect ASes using option B may or may not 601 desire to perform admission control on the inter-AS links. This 602 choice affects the detailed operation of ASBRs. We describe the two 603 modes of operation - with and without admission control at the ASBRs 604 - in the following sections. 606 5.2.1. Admission control on ASBR 608 In this scenario, the ASBR performs full RSVP signalling and 609 admission control. The RSVP database is indexed on the ASBR using 610 the VPN-IPv4 SESSION, SENDER_TEMPLATE and FILTER_SPEC objects (which 611 uniquely identify RSVP sessions and flows as per the requirements of 612 [RFC2205]). These objects are forwarded unmodified in both 613 directions by the ASBR. All other procedures of RSVP are performed 614 as if the ASBR was a RSVP hop. In particular, the RSVP_HOP objects 615 sent in Path and Resv messages contain IP addresses of the ASBR, 616 which MUST be reachable by the neighbor to whom the message is being 617 sent. Note that since the VPN-IPv4 SESSION, SENDER_TEMPLATE and 618 FILTER_SPEC objects satisfy the uniqueness properties required for a 619 RSVP database implementation as per [RFC2209], no customer VRF 620 awareness is required on the ASBR. 622 5.2.2. No admission control on ASBR 624 If the ASBR is not doing admission control, it is desirable that per- 625 flow state not be maintained on the ASBR. This requires adjacent 626 RSVP hops (i.e. the ingress and egress PEs of the respective ASes) to 627 send RSVP messages directly between them. This is only possible if 628 they are MPLS-encapsulated. The use of the VPN-IPv4 HOP object 629 described in Section 3.1 is REQUIRED in this case. 631 When an ASBR that is not installing local RSVP state receives a Path 632 message, it looks up the next-hop of the matching BGP route as 633 described in Section 3.2, and sends the Path message to the next-hop, 634 without modifying any RSVP objects (including the RSVP_HOP). This 635 process is repeated at subsequent ASBRs until the Path message 636 arrives at a router that is installing local RSVP state (either the 637 ultimate egress PE, or an ASBR configured to perform admission 638 control). This router receives the Path and processes it as 639 described in Section 3.3 if it is a PE, or Section 5.2.1 if it is an 640 ASBR performing admission control. When this router sends the Resv 641 upstream, it looks up the routing table for a next-hop+label for the 642 VPN-IPv4 address in the PHOP, encapsulates the Resv with that label 643 and sends it upstream. This message will be received for control 644 processing directly on the upstream RSVP hop (that last updated the 645 RSVP_HOP field in the Path message), without any involvement of 646 intermediate ASBRs. 648 The ASBR is not expected to process any other RSVP messages apart 649 from the Path message as described above. The ASBR also does not 650 need to store any RSVP state. Note that any ASBR along the path that 651 wishes to do admission control or insert itself into the RSVP 652 signalling flow, may do so by writing its own RSVP_HOP object with 653 IPv4 and VPN-IPv4 address pointing to itself. 655 If an Option-B ASBR receives a RSVP Path message with an IPv4 656 RSVP_HOP, does not wish to perform admission control but is willing 657 to install local state for this flow, the ASBR MUST process and 658 forward RSVP signalling messages for this flow as described in 659 Section 5.2.1 (with the exception that it does not perform admission 660 control). If an Option-B ASBR receives a RSVP Path message with an 661 IPv4 RSVP_HOP, but does not wish to install local state or perform 662 admission control for this flow, the ASBR MUST NOT forward the Path 663 message. In addition, the ASBR SHOULD send a PathError message of 664 Error Code "RSVP over MPLS Problem"_, _Error Value "RSVP_HOP not 665 reachable across VPN" (see Section 9) signifying to the upstream RSVP 666 hop that the supplied RSVP_HOP object is insufficient to provide 667 reachability across this VPN. This failure condition is not expected 668 to be recoverable. 670 5.3. Inter-AS Option C 672 Operation of RSVP in Inter-AS Option C is also quite straightforward, 673 because there exists an LSP directly from ingress PE to egress PE. 674 In this case, there is no significant difference in operation from 675 the single AS case described in Section 3. Furthermore, if it is 676 desired to provide admission control from PE to PE, it can be done by 677 building an inter-AS TE tunnel and then using the procedures 678 described in Section 4. 680 6. Operation with RSVP disabled 682 It is often the case that RSVP will not be enabled on the PE-CE 683 links. In such an environment, a customer may reasonably expect that 684 RSVP messages sent into the L3 VPN network should be forwarded just 685 like any other IP datagrams. This transparency is useful when the 686 customer wishes to use RSVP within his own sites or perhaps to 687 perform admission control on the CE-PE links (in CE->PE direction 688 only), without involvement of the PEs. For this reason, a PE SHOULD 689 NOT discard or modify RSVP messages sent towards it from a CE when 690 RSVP is not enabled on the PE-CE links. Similarly a PE SHOULD NOT 691 discard or modify RSVP messages which are destined for one of its 692 attached CEs, even when RSVP is not enabled on those links. Note 693 that the presence of the router alert option in some RSVP messages 694 may cause them to be forwarded outside of the normal forwarding path, 695 but that the guidance of this paragraph still applies in that case. 696 Note also that this guidance applies regardless of whether RSVP-TE is 697 used in some, all, or none of the L3VPN network. 699 7. Other RSVP procedures 701 This section describes modifications to other RSVP procedures 702 introduced by MPLS VPNs 704 7.1. Refresh overhead reduction 706 The following points should be noted regarding RSVP refresh overhead 707 reduction ([RFC2961]) across a MPLS VPN: 709 o The hop between the ingress and egress PE of a VPN should be 710 considered as traversing one or more non-RSVP hops. As such, the 711 procedures described in Section 5.3 of [RFC2961] relating to non- 712 RSVP hops SHOULD be followed. 714 o The source IP address of a SRefresh message MUST match the IPv4 715 address signalled in the RSVP_HOP object contained in the 716 corresponding Path or Resv message. The IPv4 address in any 717 received VPN-IPv4 RSVP_HOP object MUST be used as the source 718 address of that message for this purpose. 720 7.2. Cryptographic Authentication 722 The following points should be noted regarding RSVP cryptographic 723 authentication ([RFC2747]) across a MPLS VPN: 725 o The IPv4 address in any received VPN-IPv4 RSVP_HOP object MUST be 726 used as the source address of that message for purposes of 727 identifying the security association. 729 o Forwarding of Challenge and Response messages MUST follow the same 730 rules as described above for hop-by-hop messages. Specifically, 731 if the originator of a Challenge/Response message has received a 732 VPN-IPv4 RSVP_HOP object from the corresponding neighbor, it MUST 733 use the label associated with that VPN-IPv4 address in BGP to 734 forward the Challenge/Response message. 736 7.3. RSVP Aggregation 738 [RFC3175] and [RFC4860] describe mechanisms to aggregate multiple 739 individual RSVP reservations into a single larger reservation on the 740 basis of a common DSCP/PHB for traffic classification. The following 741 points should be noted in this regard: 743 o The procedures described in this section apply only in the case 744 where the Aggregator and Deaggregator nodes are C/CE devices, and 745 the entire MPLS VPN lies within the Aggregation Region. The case 746 where the PE is also an Aggregator/Deaggregator is more complex 747 and not considered in this document. 749 o Aggregate RSVP sessions will be treated in the same way as regular 750 IPv4 RSVP sessions. To this end, all the procedures described in 751 Section 3 and Section 4 apply to aggregate RSVP sessions. New 752 SESSION, SENDER_TEMPLATE and FILTERSPEC objects are defined in 753 Section 8. 755 o End-To-End (E2E) RSVP sessions are passed unmodified through the 756 MPLS VPN. These RSVP messages may be identified by their IP 757 protocol (RSVP-E2E-IGNORE, 134). When the ingress PE receives any 758 RSVP message with this IP protocol, it MUST process this frame as 759 if it is regular customer traffic and ignore any IP Router-Alert 760 flags. The appropriate VPN and transport labels are applied to 761 the frame and it is forwarded towards the remote CE. Note that 762 this message will not be received or processed by any other P or 763 PE node. 765 o Any SESSION-OF-INTEREST objects (defined in [RFC4860]) are to be 766 conveyed unmodified across the MPLS VPN. 768 7.4. Support for CE-CE RSVP-TE 770 [I-D.ietf-l3vpn-e2e-rsvp-te-reqts] describes a set of requirements 771 for the establishment for CE-CE MPLS LSPs across networks offering an 772 L3VPN service. The requirements specified in that draft are similar 773 to those addressed by this document, in that both address the issue 774 of handling RSVP requests from customers in a VPN context. It is 775 possible that the solution described here could be adapted to meet 776 the requirements of [I-D.ietf-l3vpn-e2e-rsvp-te-reqts]. To the 777 extent that this draft uses signalling extensions described in 778 [RFC3473] which have already been used for GMPLS/TE, we expect that 779 CE-CE RSVP/TE will be incremental work built on these extensions. 780 These extensions will be considered in a separate document. 782 8. Object Definitions 784 8.1. VPN-IPv4 and VPN-IPv6 SESSION objects 786 The usage of the VPN-IPv4 (or VPN-IPv6) SESSION Object is described 787 in Section 3.2 to Section 3.6. The VPN-IPv4 (or VPN-IPv6) SESSION 788 object appears in RSVP messages that ordinarily contain a SESSION 789 object and are sent between ingress PE and egress PE in either 790 direction. The object MUST NOT be included in any RSVP messages that 791 are sent outside of the provider's backbone (except in the inter-AS 792 option B and C cases, as described above, when it may appear on 793 inter-AS links). 795 The VPN-IPv6 SESSION object is analogous to the VPN-IPv4 SESSION 796 object, using an VPN-IPv6 address ([RFC4659]) instead of an VPN-IPv4 797 address ([RFC4364]). 799 The formats of the objects are as follows: 801 o VPN-IPv4 SESSION object: Class = 1, C-Type = TBA 803 +-------------+-------------+-------------+-------------+ 804 | | 805 + + 806 | VPN-IPv4 DestAddress (12 bytes) | 807 + + 808 | | 809 +-------------+-------------+-------------+-------------+ 810 | Protocol Id | Flags | DstPort | 811 +-------------+-------------+-------------+-------------+ 813 o VPN-IPv6 SESSION object: Class = 1, C-Type = TBA 815 +-------------+-------------+-------------+-------------+ 816 | | 817 + + 818 | | 819 + VPN-IPv6 DestAddress (24 bytes) + 820 / / 821 . . 822 / / 823 | | 824 +-------------+-------------+-------------+-------------+ 825 | Protocol Id | Flags | DstPort | 826 +-------------+-------------+-------------+-------------+ 828 The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field 829 contains an address of the VPN-IPv4 (respectively VPN-IPv6) address 830 family encoded as specified in [RFC4364] (respectively [RFC4659]). 831 The content of this field is discussed in Section 3.2 and 832 Section 3.3. 834 The protocol ID, flags, and DstPort are identical to the same fields 835 in the IPv4 and IPv6 SESSION objects ([RFC2205]). 837 8.2. VPN-IPv4 and VPN-IPv6 SENDER_TEMPLATE objects 839 The usage of the VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE Object is 840 described in Section 3.2 and Section 3.3. The VPN-IPv4 (or VPN-IPv6) 841 SENDER_TEMPLATE object appears in RSVP messages that ordinarily 842 contain a SENDER_TEMPLATE object and are sent between ingress PE and 843 egress PE in either direction (such as Path, PathError, and 844 PathTear). The object MUST NOT be included in any RSVP messages that 845 are sent outside of the provider's backbone (except in the inter-AS 846 option B and C cases, as described above, when it may appear on 847 inter-AS links). The format of the object is as follows: 849 o VPN-IPv4 SENDER_TEMPLATE object: Class = 11, C-Type = TBA 851 +-------------+-------------+-------------+-------------+ 852 | | 853 + + 854 | VPN-IPv4 SrcAddress (12 bytes) | 855 + + 856 | | 857 +-------------+-------------+-------------+-------------+ 858 | Reserved | SrcPort | 859 +-------------+-------------+-------------+-------------+ 861 o VPN-IPv6 SENDER_TEMPLATE object: Class = 11, C-Type = TBA 863 +-------------+-------------+-------------+-------------+ 864 | | 865 + + 866 | | 867 + VPN-IPv6 SrcAddress (24 bytes) + 868 / / 869 . . 870 / / 871 | | 872 +-------------+-------------+-------------+-------------+ 873 | Reserved | SrcPort | 874 +-------------+-------------+-------------+-------------+ 876 The VPN-IPv4 SrcAddress (respectively VPN-IPv6 SrcAddress) field 877 contains an address of the VPN-IPv4 (respectively VPN-IPv6) address 878 family encoded as specified in [RFC4364] (respectively [RFC4659]). 879 The content of this field is discussed in Section 3.2 and 880 Section 3.3. 882 The SrcPort is identical to the SrcPort field in the IPv4 and IPv6 883 SENDER_TEMPLATE objects ([RFC2205]). 885 The Reserved field must be set to zero on transmit and ignored on 886 receipt. 888 8.3. VPN-IPv4 and VPN-IPv6 FILTER_SPEC objects 890 The usage of the VPN-IPv4 (or VPN-IPv6) FILTER_SPEC Object is 891 described in Section 3.4 and Section 3.5. The VPN-IPv4 (or VPN-IPv6) 892 FILTER_SPEC object appears in RSVP messages that ordinarily contain a 893 FILTER_SPEC object and are sent between ingress PE and egress PE in 894 either direction (such as Resv, ResvError, and ResvTear). The object 895 MUST NOT be included in any RSVP messages that are sent outside of 896 the provider's backbone (except in the inter-AS option B and C cases, 897 as described above, when it may appear on inter-AS links). 899 o VPN-IPv4 FILTER_SPEC object: Class = 10, C-Type = TBA 901 Definition same as VPN-IPv4 SENDER_TEMPLATE object. 903 o VPN-IPv6 FILTER_SPEC object: Class = 10, C-Type = TBA 905 Definition same as VPN-IPv6 SENDER_TEMPLATE object. 907 The content of the VPN-IPv4 SrcAddress (or VPN-IPv6 SrcAddress) field 908 is discussed in Section 3.4 and Section 3.5. 910 The SrcPort is identical to the SrcPort field in the IPv4 and IPv6 911 SENDER_TEMPLATE objects ([RFC2205]). 913 The Reserved field must be set to zero on transmit and ignored on 914 receipt. 916 8.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP objects 918 Usage of the VPN-IPv4 (or VPN-IPv6) RSVP_HOP Object is described in 919 Section 3.1 and Section 5.2.2. The VPN-IPv4 (VPN-IPv6) RSVP_HOP 920 object is used to establish signalling reachability between RSVP 921 neighbors separated by one or more Option-B ASBRs. This object may 922 appear in RSVP messages that carry a RSVP_HOP object, and that travel 923 between the Ingress and Egress PEs. It MUST NOT be included in any 924 RSVP messages that are sent outside of the provider's backbone 925 (except in the inter-AS option B and C cases, as described above, 926 when it may appear on inter-AS links). The format of the object is 927 as follows: 929 o VPN-IPv4 RSVP_HOP object: Class = 3, C-Type = TBA 931 +-------------+-------------+-------------+-------------+ 932 | IPv4 Next/Previous Hop Address (4 bytes) | 933 +-------------+-------------+-------------+-------------+ 934 | | 935 + + 936 | VPN-IPv4 Next/Previous Hop Address (12 bytes) | 937 + + 938 | | 939 +-------------+-------------+-------------+-------------+ 940 | Logical Interface Handle | 941 +-------------+-------------+-------------+-------------+ 943 o VPN-IPv6 RSVP_HOP object: Class = 3, C-Type = TBA 945 +-------------+-------------+-------------+-------------+ 946 | | 947 + + 948 | | 949 + IPv6 Next/Previous Hop Address (16 bytes) + 950 | | 951 + + 952 | | 953 +-------------+-------------+-------------+-------------+ 954 | | 955 + + 956 | | 957 + VPN-IPv6 Next/Previous Hop Address (24 bytes) + 958 / / 959 . . 960 / / 961 | | 962 +-------------+-------------+-------------+-------------+ 963 | Logical Interface Handle | 964 +-------------+-------------+-------------+-------------+ 966 The IPv4 Next/Previous Hop Address, IPv6 Next/Previous Hop Address 967 and the Logical Interface Handle fields are identical to those of the 968 RSVP_HOP object ([RFC2205]). 970 The VPN-IPv4 Next/Previous Hop Address (respectively VPN-IPv6 Next/ 971 Previous Hop Address) field contains an address of the VPN-IPv4 972 (respectively VPN-IPv6) address family encoded as specified in 973 [RFC4364] (respectively [RFC4659]). The content of this field is 974 discussed in Section 3.1. 976 8.5. Aggregated VPN-IPv4 and VPN-IPv6 SESSION objects 978 The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SESSION object is 979 described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively 980 AGGREGATE-IPv6-VPN) SESSION object appears in RSVP messages that 981 ordinarily contain a AGGREGATE-IPv4 (respectively AGGREGATE-IPv6) 982 SESSION object as defined in [RFC3175] and are sent between ingress 983 PE and egress PE in either direction. The GENERIC-AGGREGATE-VPN-IPv4 984 (respectively AGGREGATE-VPN-IPv6) SESSION object should appear in all 985 RSVP messages that ordinarily contain a GENERIC-AGGREGATE-IPv4 986 (respectively GENERIC-AGGREGATE-IPv6) SESSION object as defined in 987 [RFC4860] and are sent between ingress PE and egress PE in either 988 direction. These objects MUST NOT be included in any RSVP messages 989 that are sent outside of the provider's backbone (except in the 990 inter-AS option B and C cases, as described above, when it may appear 991 on inter-AS links). The processing rules for these objects are 992 otherwise identical to those of the VPN-IPv4 (respectively VPN-IPv6) 993 SESSION object defined in Section 8.1. The format of the object is 994 as follows: 996 o AGGREGATE-VPN-IPv4 SESSION object: Class = 1, C-Type = TBA 998 +-------------+-------------+-------------+-------------+ 999 | | 1000 + + 1001 | VPN-IPv4 DestAddress (12 bytes) | 1002 + + 1003 | | 1004 +-------------+-------------+-------------+-------------+ 1005 | /////// | Flags | /////// | DSCP | 1006 +-------------+-------------+-------------+-------------+ 1008 o AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = TBA 1010 +-------------+-------------+-------------+-------------+ 1011 | | 1012 + + 1013 | | 1014 + VPN-IPv6 DestAddress (24 bytes) + 1015 / / 1016 . . 1017 / / 1018 | | 1019 +-------------+-------------+-------------+-------------+ 1020 | Reserved | Flags | Reserved | DSCP | 1021 +-------------+-------------+-------------+-------------+ 1023 The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field 1024 contains an address of the VPN-IPv4 (respectively VPN-IPv6) address 1025 family encoded as specified in [RFC4364] (respectively [RFC4659]). 1026 The content of this field is discussed in Section 3.2 and 1027 Section 3.3. 1029 The flags and DSCP are identical to the same fields of the AGGREGATE- 1030 IPv4 and AGGREGATE-IPv6 SESSION objects ([RFC3175],). 1032 o GENERIC-AGGREGATE-VPN-IPv4 SESSION object: 1033 Class = 1, C-Type = TBA 1035 +-------------+-------------+-------------+-------------+ 1036 | | 1037 + + 1038 | VPN-IPv4 DestAddress (12 bytes) | 1039 + + 1040 | | 1041 +-------------+-------------+-------------+-------------+ 1042 | Reserved | Flags | PHB-ID | 1043 +-------------+-------------+-------------+-------------+ 1044 | Reserved | vDstPort | 1045 +-------------+-------------+-------------+-------------+ 1046 | Extended vDstPort | 1047 +-------------+-------------+-------------+-------------+ 1049 o GENERIC-AGGREGATE-VPN-IPv6 SESSION object: 1050 Class = 1, C-Type = TBA 1052 +-------------+-------------+-------------+-------------+ 1053 | | 1054 + + 1055 | | 1056 + VPN-IPv6 DestAddress (24 bytes) + 1057 / / 1058 . . 1059 / / 1060 | | 1061 +-------------+-------------+-------------+-------------+ 1062 | Reserved | Flags | PHB-ID | 1063 +-------------+-------------+-------------+-------------+ 1064 | Reserved | vDstPort | 1065 +-------------+-------------+-------------+-------------+ 1066 | Extended vDstPort | 1067 +-------------+-------------+-------------+-------------+ 1069 The VPN-IPv4 DestAddress (respectively VPN-IPv6 DestAddress) field 1070 contains an address of the VPN-IPv4 (respectively VPN-IPv6) address 1071 family encoded as specified in [RFC4364] (respectively [RFC4659]). 1072 The content of this field is discussed in Section 3.2 and 1073 Section 3.3. 1075 The flags, PHB-ID, vDstPort and Extended vDstPort are identical to 1076 the same fields of the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE- 1077 IPv6 SESSION objects ([RFC4860]). 1079 8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 SENDER_TEMPLATE objects 1081 The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object 1082 is described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively 1083 AGGREGATE-VPN-IPv6) SENDER_TEMPLATE object appears in RSVP messages 1084 that ordinarily contain a AGGREGATE-IPv4 (respectively AGGREGATE- 1085 IPv6) SENDER_TEMPLATE object as defined in [RFC3175] and [RFC4860], 1086 and are sent between ingress PE and egress PE in either direction. 1087 These objects MUST NOT be included in any RSVP messages that are sent 1088 outside of the provider's backbone (except in the inter-AS option B 1089 and C cases, as described above, when it may appear on inter-AS 1090 links). The processing rules for these objects are otherwise 1091 identical to those of the VPN-IPv4 (respectively VPN-IPv6) 1092 SENDER_TEMPLATE object defined in Section 8.2. The format of the 1093 object is as follows: 1095 o AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object: 1096 Class = 11, C-Type = TBA 1098 +-------------+-------------+-------------+-------------+ 1099 | | 1100 + + 1101 | VPN-IPv4 AggregatorAddress (12 bytes) | 1102 + + 1103 | | 1104 +-------------+-------------+-------------+-------------+ 1106 o AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object: 1107 Class = 11, C-Type = TBA 1109 +-------------+-------------+-------------+-------------+ 1110 | | 1111 + + 1112 | | 1113 + VPN-IPv6 AggregatorAddress (24 bytes) + 1114 / / 1115 . . 1116 / / 1117 | | 1118 +-------------+-------------+-------------+-------------+ 1120 The VPN-IPv4 AggregatorAddress (respectively VPN-IPv6 1121 AggregatorAddress) field contains an address of the VPN-IPv4 1122 (respectively VPN-IPv6) address family encoded as specified in 1123 [RFC4364] (respectively [RFC4659]). The content and processing rules 1124 for these objects are similar to those of the VPN-IPv4 1125 SENDER_TEMPLATE object defined in Section 8.2. 1127 The flags and DSCP are identical to the same fields of the AGGREGATE- 1128 IPv4 and AGGREGATE-IPv6 SESSION objects. 1130 8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC objects 1132 The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in 1133 Section 7.3. The AGGREGATE-VPN-IPv4 FILTER_SPEC object appears in 1134 RSVP messages that ordinarily contain a AGGREGATE-IPv4 FILTER_SPEC 1135 object as defined in [RFC3175] and [RFC4860], and are sent between 1136 ingress PE and egress PE in either direction. These objects MUST NOT 1137 be included in any RSVP messages that are sent outside of the 1138 provider's backbone (except in the inter-AS option B and C cases, as 1139 described above, when it may appear on inter-AS links). The 1140 processing rules for these objects are otherwise identical to those 1141 of the VPN-IPv4 FILTER_SPEC object defined in Section 8.3. The 1142 format of the object is as follows: 1144 o AGGREGATE-VPN-IPv4 FILTER_SPEC object: 1145 Class = 10, C-Type = TBA 1147 Definition same as AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object. 1149 o AGGREGATE-VPN-IPv6 FILTER_SPEC object: 1150 Class = 10, C-Type = TBA 1152 Definition same as AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object. 1154 9. IANA Considerations 1156 Section 8 defines new objects. Therefore, this document requests 1157 IANA to modify the RSVP parameters registry, 'Class Names, Class 1158 Numbers, and Class Types' subregistry, and: 1160 o assign six new C-Types under the existing SESSION Class (Class 1161 number 1), as suggested below: 1163 Class 1164 Number Class Name Reference 1165 ------ ----------------------- --------- 1167 1 SESSION [RFC2205] 1169 Class Types or C-Types: 1171 .. ... ... 1172 aa VPN-IPv4 [RFCXXXX] 1173 bb VPN-IPv6 [RFCXXXX] 1174 cc AGGREGATE-VPN-IPv4 [RFCXXXX] 1175 dd AGGREGATE-VPN-IPv6 [RFCXXXX] 1176 ee GENERIC-AGGREGATE-VPN-IPv4 [RFCXXXX] 1177 ff GENERIC-AGGREGATE-VPN-IPv6 [RFCXXXX] 1179 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1180 number of this specification. Suggested values: aa-ff=19-24] 1182 o assign four new C-Types under the existing SENDER_TEMPLATE Class 1183 (Class number 11), as suggested below: 1185 Class 1186 Number Class Name Reference 1187 ------ ----------------------- --------- 1189 11 SENDER_TEMPLATE [RFC2205] 1191 Class Types or C-Types: 1193 .. ... ... 1194 aa VPN-IPv4 [RFCXXXX] 1195 bb VPN-IPv6 [RFCXXXX] 1196 cc AGGREGATE-VPN-IPv4 [RFCXXXX] 1197 dd AGGREGATE-VPN-IPv6 [RFCXXXX] 1199 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1200 number of this specification. Suggested values: aa-dd=14-17] 1202 o assign four new C-Types under the existing FILTER_SPEC Class 1203 (Class number 10), as suggested below: 1205 Class 1206 Number Class Name Reference 1207 ------ ----------------------- --------- 1209 10 FILTER_SPEC [RFC2205] 1211 Class Types or C-Types: 1213 .. ... ... 1214 aa VPN-IPv4 [RFCXXXX] 1215 bb VPN-IPv6 [RFCXXXX] 1216 cc AGGREGATE-VPN-IPv4 [RFCXXXX] 1217 dd AGGREGATE-VPN-IPv6 [RFCXXXX] 1219 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1220 number of this specification. Suggested values: aa-dd=14-17] 1222 o assign two new C-Types under the existing RSVP_HOP Class (Class 1223 number 3), as suggested below: 1225 Class 1226 Number Class Name Reference 1227 ------ ----------------------- --------- 1229 3 RSVP_HOP [RFC2205] 1231 Class Types or C-Types: 1233 .. ... ... 1234 aa VPN-IPv4 [RFCXXXX] 1235 bb VPN-IPv6 [RFCXXXX] 1237 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1238 number of this specification. Suggested values: aa-bb=5-6] 1240 In addition, a new PathError code/value is required to identify a 1241 signalling reachability failure and the need for a VPN-IPv4 or VPN- 1242 IPv6 RSVP_HOP object as described in Section 5.2.2. Therefore, this 1243 document requests IANA to modify the RSVP parameters registry, 'Error 1244 Codes and Globally-Defined Error Value Sub-Codes' subregistry, and: 1246 o assign a new Error Code and sub-code, as suggested below: 1248 aa RSVP over MPLS Problem [RFCXXXX] 1250 This Error Code has the following globally-defined Error 1251 Value sub-codes: 1253 1 = RSVP_HOP not reachable across VPN [RFCXXXX] 1255 [Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 1256 number of this specification. Suggested values: aa=34] 1258 10. Security Considerations 1260 [RFC4364] addresses the security considerations of BGP/MPLS VPNs in 1261 general. General RSVP security considerations are discussed in 1262 [RFC2205]. To ensure the integrity of RSVP, the RSVP Authentication 1263 mechanisms defined in [RFC2747] and [RFC3097] SHOULD be supported. 1264 Those protect RSVP message integrity hop-by-hop and provide node 1265 authentication as well as replay protection, thereby protecting 1266 against corruption and spoofing of RSVP messages. 1267 [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses applicability of 1268 various keying approaches for RSVP Authentication. First, we note 1269 that the discussion about applicability of group keying to an intra- 1270 provider environment where RSVP hops are not IP hops is relevant to 1271 securing of RSVP among PEs of a given Service Provider deploying the 1272 solution specified in the present document. We note that the RSVP 1273 signaling in MPLS VPN is likely to spread over multiple 1274 administrative domains (e.g. the service provider operating the VPN 1275 service, and the customers of the service). Therefore the 1276 considerations in [I-D.ietf-tsvwg-rsvp-security-groupkeying] about 1277 inter-domain issues are likely to apply. 1279 Since RSVP messages travel through the L3VPN cloud directly addressed 1280 to PE or ASBR routers (without IP Router-Alert), P routers remain 1281 isolated from RSVP messages signalling customer reservations. 1282 Providers MAY choose to block PEs from sending IP Router-Alert 1283 datagrams to P routers as a security practice, without impacting the 1284 functionality described herein. 1286 Beyond those general issues, four specific issues are introduced by 1287 this document: resource usage on PEs, resource usage in the provider 1288 backbone, PE route advertisement outside the AS, and signalling 1289 exposure to ASBRs and PEs. We discuss these in turn. 1291 A customer who makes resource reservations on the CE-PE links for his 1292 sites is only competing for link resources with himself, as in 1293 standard RSVP, at least in the common case where each CE-PE link is 1294 dedicated to a single customer. Thus, from the perspective of the 1295 CE-PE links, this draft does not introduce any new security issues. 1296 However, because a PE typically serves multiple customers, there is 1297 also the possibility that a customer might attempt to use excessive 1298 computational resources on a PE (CPU cycles, memory etc.) by sending 1299 large numbers of RSVP messages to a PE. In the extreme this could 1300 represent a form of denial-of-service attack. In order to prevent 1301 such an attack, a PE SHOULD support mechanisms to limit the fraction 1302 of its processing resources that can be consumed by any one CE or by 1303 the set of CEs of a given customer. For example, a PE might 1304 implement a form of rate limiting on RSVP messages that it receives 1305 from each CE. We observe that these security risks and measures 1306 related to PE resource usage are very similar for any control plane 1307 protocol operating between CE and PE (e.g. RSVP, routing, multicast) 1309 The second concern arises only when the service provider chooses to 1310 offer resource reservation across the backbone, as described in 1311 Section 4. In this case, the concern may be that a single customer 1312 might attempt to reserve a large fraction of backbone capacity, 1313 perhaps with a co-ordinated effort from several different CEs, thus 1314 denying service to other customers using the same backbone. 1315 [RFC4804] provides some guidance on the security issues when RSVP 1316 reservations are aggregated onto MPLS tunnels, which are applicable 1317 to the situation described here. We note that a provider MAY use 1318 local policy to limit the amount of resources that can be reserved by 1319 a given customer from a particular PE, and that a policy server could 1320 be used to control the resource usage of a given customer across 1321 multiple PEs if desired. It is RECOMMENDED that an implementation of 1322 this specification support local policy on the PE to control the 1323 amount of resources that can be reserved by a given customer/CE. 1325 Use of the VPN-IPv4 HOP object requires exporting a PE VPN-IPv4 route 1326 to another AS, and potentially could allow unchecked access to remote 1327 PEs if those routes were indiscriminately redistributed. However, as 1328 described in Section 3.1, no route which is not within a customer's 1329 VPN should ever be advertised to (or reachable from) that customer. 1330 If a PE uses a local address already within a customer VRF (like 1331 PE-CE link address), it MUST NOT send this address in any RSVP 1332 messages in a different customer VRF. A "control plane" VPN MAY be 1333 created across PEs and ASBRs and addresses in this VPN can be used to 1334 signal RSVP sessions for any customers, but these routes MUST NOT be 1335 advertised to, or made reachable from, any customer. An 1336 implementation of the present document MAY support such operation 1337 using a "control plane" VPN. Alternatively, ASBRs MAY implement the 1338 signalling procedures described in Section 5.2.1, even if admission 1339 control is not required on the inter-AS link, as these procedures do 1340 not require any direct P/PE route advertisement out of the AS. 1342 Finally, certain operations described herein (Section 3) require an 1343 ASBR or PE to receive and locally process a signalling packet 1344 addressed to the BGP next-hop address advertised by that router. 1345 This requirement does not strictly apply to MPLS/BGP VPNs [RFC4364]. 1346 This could be viewed as opening ASBRs and PEs to being directly 1347 addressable by customer devices where they were not open before, and 1348 could be considered a security issue. If a provider wishes to 1349 mitigate this situation, the implementation MAY support the "control 1350 protocol VPN" approach described above. That is, whenever a 1351 signalling message is to be sent to a PE or ASBR, the address of the 1352 router in question would be looked up in the "control protocol VPN", 1353 and the message would then be sent on the LSP that is found as a 1354 result of that lookup. This would ensure that the router address is 1355 not reachable by customer devices. 1357 [RFC4364] mentions use of IPsec both on a CE-CE basis and PE-PE 1358 basis: "Cryptographic privacy is not provided by this architecture, 1359 nor by Frame Relay or ATM VPNs. These architectures are all 1360 compatible with the use of cryptography on a CE-CE basis, if that is 1361 desired. The use of cryptography on a PE-PE basis is for further 1362 study." 1364 The procedures specified in the present document for admission 1365 control on the PE-CE links (Section 3) are compatible with the use of 1366 IPsec on a PE-PE basis. The optional procedures specified in the 1367 present document for admission control in the Service Provider's 1368 backbone (Section 4) are not compatible with the use of IPsec on a 1369 PE-PE basis, since those procedures depend on the use of PE-PE MPLS 1370 TE Tunnels to perform aggregate reservations through the Service 1371 Provider's backbone. 1373 [RFC4923] describes a model for RSVP operation through IPsec 1374 Gateways. In a nutshell, a form of hierarchical RSVP reservation is 1375 used where an RSVP reservation is made for the IPsec tunnel and then 1376 individual RSVP reservations are admitted/aggregated over the tunnel 1377 reservation. This model applies to the case where IPsec is used on a 1378 CE-CE basis. In that situation, the procedures defined in the 1379 present document would simply apply "as is" to the reservation 1380 established for the IPsec tunnel(s). 1382 11. Acknowledgments 1384 Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric 1385 Rosen, Dan Tappan and Lou Berger for their many contributions to 1386 solving the problems described in this draft. Thanks to Ferit 1387 Yegenoglu for his useful comments. We also thank Stefan Santesson 1388 and Vijay Gurbani for their review comments. 1390 Appendix A. Alternatives Considered 1392 At this stage a number of alternatives to the approach described 1393 above have been considered. We document some of the approaches 1394 considered here to assist future discussion. None of these has been 1395 shown to improve upon the approach described above, and the first two 1396 seem to have significant drawbacks relative to the approach described 1397 above. 1399 Appendix A.1. GMPLS UNI approach 1401 [RFC4208] defines the GMPLS UNI. In Section 7 the operation of the 1402 GMPLS UNI in a VPN context is briefly described. This is somewhat 1403 similar to the problem tackled in the current document. The main 1404 difference is that the GMPLS UNI is primarily aimed at the problem of 1405 allowing a CE device to request the establishment of an LSP across 1406 the network on the other side of the UNI. Hence the procedures in 1407 [RFC4208] would lead to the establishment of an LSP across the VPN 1408 provider's network for every RSVP request received, which is not 1409 desired in this case. 1411 To the extent possible, the approach described in this document is 1412 consistent with [RFC4208], while filling in more of the details and 1413 avoiding the problem noted above. 1415 Appendix A.2. VRF label approach 1417 Another approach to solving the problems described here involves the 1418 use of label switching to ensure that Path, Resv, and other RSVP 1419 messages are directed to the appropriate VRF. One challenge with 1420 such an approach is that [RFC4364] does not require labels to be 1421 allocated for VRFs, only for customer prefixes, and that there is no 1422 simple, existing method for advertising the fact that a label is 1423 bound to a VRF. If, for example, an ingress PE sent a Path message 1424 labelled with a VPN label that was advertised by the egress PE for 1425 the prefix that matches the destination address in the Path, there is 1426 a risk that the egress PE would simply label-switch the Path directly 1427 on to the CE without performing RSVP processing. 1429 A second challenge with this approach is that an IP address needs to 1430 be associated with a VRF and used as the PHOP address for the Path 1431 message sent from ingress PE to egress PE. That address must be 1432 reachable from the egress PE, and exist in the VRF at the ingress PE. 1433 Such an address is not always available in today's deployments, so 1434 this represents at least a change to existing deployment practices. 1436 Appendix A.3. VRF label plus VRF address approach 1438 It is possible to create an approach based on that described in the 1439 previous section which addresses the main challenges of that 1440 approach. The basic approach has two parts: (a) define a new BGP 1441 Extended Community to tag a route (and its associated MPLS label) as 1442 pointing to a VRF; (b) allocate a "dummy" address to each VRF, 1443 specifically to be used for routing RSVP messages. The dummy address 1444 (which could be anything, e.g. a loopback of the associated PE) would 1445 be used as a PHOP for Path messages and would serve as the 1446 destination for Resv messages but would not be imported into VRFs of 1447 any other PE. 1449 12. References 1451 12.1. Normative References 1453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1454 Requirement Levels", BCP 14, RFC 2119, March 1997. 1456 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1457 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1458 Functional Specification", RFC 2205, September 1997. 1460 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 1461 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 1462 RFC 3175, September 2001. 1464 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1465 Networks (VPNs)", RFC 4364, February 2006. 1467 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1468 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1469 IPv6 VPN", RFC 4659, September 2006. 1471 [RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation 1472 Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels", 1473 RFC 4804, February 2007. 1475 12.2. Informative References 1477 [I-D.ietf-l3vpn-e2e-rsvp-te-reqts] 1478 Kumaki, K., Kamite, Y., and R. Zhang, "Requirements for 1479 supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP- 1480 VPN", draft-ietf-l3vpn-e2e-rsvp-te-reqts-04 (work in 1481 progress), August 2009. 1483 [I-D.ietf-nsis-ntlp] 1484 Schulzrinne, H. and M. Stiemerling, "GIST: General 1485 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 1486 (work in progress), June 2009. 1488 [I-D.ietf-nsis-qos-nslp] 1489 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 1490 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 1491 (work in progress), February 2008. 1493 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 1494 Behringer, M. and F. Faucheur, "Applicability of Keying 1495 Methods for RSVP Security", 1496 draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in 1497 progress), June 2009. 1499 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1500 Services in the Internet Architecture: an Overview", 1501 RFC 1633, June 1994. 1503 [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol 1504 (RSVP) -- Version 1 Message Processing Rules", RFC 2209, 1505 September 1997. 1507 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1508 Services", RFC 2210, September 1997. 1510 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 1511 Authentication", RFC 2747, January 2000. 1513 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1514 and S. Molendini, "RSVP Refresh Overhead Reduction 1515 Extensions", RFC 2961, April 2001. 1517 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 1518 Authentication -- Updated Message Type Value", RFC 3097, 1519 April 2001. 1521 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1522 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1523 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1525 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1526 Hierarchy with Generalized Multi-Protocol Label Switching 1527 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 1529 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 1530 "Generalized Multiprotocol Label Switching (GMPLS) User- 1531 Network Interface (UNI): Resource ReserVation Protocol- 1532 Traffic Engineering (RSVP-TE) Support for the Overlay 1533 Model", RFC 4208, October 2005. 1535 [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. 1536 Davenport, "Generic Aggregate Resource ReSerVation 1537 Protocol (RSVP) Reservations", RFC 4860, May 2007. 1539 [RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS) Signaling 1540 in a Nested Virtual Private Network", RFC 4923, 1541 August 2007. 1543 Authors' Addresses 1545 Bruce Davie 1546 Cisco Systems, Inc. 1547 1414 Mass. Ave. 1548 Boxborough, MA 01719 1549 USA 1551 Email: bsd@cisco.com 1553 Francois le Faucheur 1554 Cisco Systems, Inc. 1555 Village d'Entreprise Green Side - Batiment T3 1556 400, Avenue de Roumanille 1557 Biot Sophia-Antipolis 06410 1558 France 1560 Email: flefauch@cisco.com 1562 Ashok Narayanan 1563 Cisco Systems, Inc. 1564 1414 Mass. Ave. 1565 Boxborough, MA 01719 1566 USA 1568 Email: ashokn@cisco.com