idnits 2.17.1 draft-kumaki-murai-l3vpn-rsvp-te-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 21, 2012) is 4141 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Kumaki, Ed. 2 Internet Draft KDDI Corporation 3 Intended Status: Experimental T. Murai 4 Expires: June 20, 2013 Furukawa Network Solutions Corp. 5 D. Cheng 6 Huawei Technologies 7 S. Matsushima 8 Softbank Telecom 9 P. Jiang 10 KDDI Corporation 11 December 21, 2012 13 Support for RSVP-TE in L3VPNs 14 draft-kumaki-murai-l3vpn-rsvp-te-09.txt 16 Abstract 18 IP Virtual Private Networks (VPNs) provide connectivity between sites 19 across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS 20 and a single provider edge (PE) node may provide access to multiple 21 customer sites belonging to different VPNs. 23 The VPNs may support a number of customer services including RSVP and 24 RSVP-TE traffic. This document describes how to support RSVP-TE 25 between customer sites when a single PE supports multiple VPNs and 26 labels are not used to identify VPNs between PEs. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 This Internet-Draft will expire on June 20, 2013. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with 61 respect to this document. Code Components extracted from this 62 document must include Simplified BSD License text as described in 63 Section 4.e of the Trust Legal Provisions and are provided without 64 warranty as described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction..................................................3 69 2. Motivation....................................................3 70 2.1 Network Example...........................................4 71 3. Protocol Extensions and Procedures............................5 72 3.1 Object Definitions........................................5 73 3.1.1 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 SESSION Object 74 ..............................................................5 75 3.1.2 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 SENDER_TEMPLATE 76 Objects.......................................................7 77 3.1.3 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 FILTER_SPEC 78 Objects.......................................................8 79 3.1.4 VPN-IPv4 and VPN-IPv6 RSVP_HOP Objects..................9 80 3.2 Handling..................................................9 81 3.2.1 Path Message Processing at Ingress PE...................9 82 3.2.2 Path Message Processing at Egress PE....................10 83 3.2.3 Resv Processing at Egress PE............................10 84 3.2.4 Resv Processing at Ingress PE...........................10 85 3.2.5 Other RSVP Messages.....................................10 86 4. Management Considerations.....................................11 87 4.1 Impact on Network Operation...............................11 88 5. Security Considerations.......................................11 89 6. IANA Considerations...........................................12 90 7. References....................................................12 91 7.1 Normative References......................................13 92 7.2 Informative References....................................13 93 8. Acknowledgments...............................................13 94 9. Author's Addresses............................................14 95 10. Contributors' Addresses......................................14 97 Conventions used in this document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 1. Introduction 105 Service Providers would like to use BGP/MPLS IP-VPNs [RFC4364] to 106 support connections between Customer Edge (CE) sites. As described in 107 [RFC5824], these connections can be MPLS Traffic Engineered (TE) 108 Label Switched Paths (LSPs) established using extensions to RSVP 109 [RFC3209] for a number of different deployment scenarios. The 110 requirements for supporting MPLS-TE LSP connections across BGP/MPLS 111 IP-VPNs are documented in [RFC5824]. 113 In order to establish a customer MPLS-TE LSP over a BGP/MPLS IP-VPN, 114 it is necessary for the RSVP-TE control messages, including Path 115 messages and Resv messages described in [RFC3209], to be 116 appropriately handled by the Provider Edge (PE) routers. 117 [RFC4364] allows RSVP messages sent within a VPN's context to be 118 handled just like any other VPN data. In such a solution, the 119 RSVP-TE component at a PE that sends messages toward a remote PE 120 must process the messages in the context of the VPN and must 121 ensure that the messages are correctly labelled. Similarly, when 122 a message is received by a PE having been sent across the core, 123 both labels to indicate the correct VPN context. 125 Implementation of the standards-based solution described in the 126 previous paragraph is possible, but requires proper support on 127 the PE. In particular, a PE must be able to process RSVP messages 128 within the context of the appropriate VPN VRF. This may be 129 achieved easily in some implementations, in others it is not so 130 easy to achieved. 132 This document defines experimental formats and mechanisms that 133 follows a different approach. The documented approach enables the 134 VPN identifier to be carried in the RSVP-TE protocol message so 135 that there is no requirement for label based VRF identification 136 on the PE. 138 The experiment proposed by this document does not negate the 139 label based approach supported by [RFC4364]. The experiment is 140 intended to enable research into alternate methods of supporting 141 RSVP-TE within VPNs. 143 2. Motivation 144 If multiple BGP/MPLS IP-VPNs are supported at the same PE, new 145 RSVP-TE extensions are required so that RSVP-TE control messages 146 from the CEs can be appropriately handled by the PE. 148 2.1 Network Example 150 Figure 1 (Customer MPLS TE LSPs in the context of BGP/MPLS IP-VPNs) 151 shows two VPNs supported by a core IP/MPLS network. Both VPNs have 152 customer sites supported by the two PEs shown in the figure. The 153 customer sites operate MPLS-TE LSPs. 155 Here, we make the following set of assumptions. 157 1. VPN1 and VPN2 are for different customers. 158 2. CE1 and CE3 are head-end routers. 159 3. CE2 and CE4 are tail-end routers. 160 4. The same address (e.g., 192.0.2.1) is assigned at CE2 and CE4. 162 <--------A customer MPLS TE LSP for VPN1--------> 164 ....... ....... 165 . --- . --- --- --- --- . --- . 166 .|CE1|----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2|. 167 . --- . --- --- --- --- . --- . 168 ....... | | ....... 169 (VPN1) | | (VPN1) 170 | | 171 ....... | | ....... 172 . --- . | | . --- . 173 .|CE3|------+ +-------|CE4|. 174 . --- . . --- . 175 ....... ....... 176 (VPN2) (VPN2) 178 <--------A customer MPLS TE LSP for VPN2--------> 179 ^ ^ 180 | | 181 VRF instance VRF instance 183 <-Customer-> <---BGP/MPLS IP-VPN---> <-Customer-> 184 network network 186 Figure 1: Customer MPLS TE LSPs in the context of BGP/MPLS IP-VPNs 188 Consider that customers in VPN1 and VPN2 would like to establish a 189 customer MPLS TE LSPs between their sites (i.e., between CE1 and CE2, 190 and between CE3 and CE4). In this situation the following RSVP-TE 191 Path messages would be sent: 193 1. CE1 would send a Path message to PE1 to establish 194 the MPLS TE LSP (VPN1) between CE1 and CE2. 196 2. CE3 would also send a Path message to PE1 to establish 197 the MPLS TE LSP (VPN2) between CE1 and CE2. 199 After receiving each Path messages, PE1 can identify the customer 200 context for each Path message from the incoming interface over which 201 the message was received. PE1 forwards the messages to PE2 using the 202 routing mechanisms described in [RFC4364] and [RFC4659]. 204 When the Path messages are received at PE2, that node needs to 205 distinguish the messages and determine which applies to VPN1 and 206 which to VPN2 so that the right forwarding state can be established 207 and so that the messages can be passed on to the correct CE. Although 208 the messages will arrive at PE2 with an MPLS label that identifies 209 the VPN, the messages will be delivered to the RSVP-TE component on 210 PE2 and the context of the core VPN LSP (i.e., the label) will be 211 lost. Some RSVP-TE protocol mechanism is therefore needed to embed 212 the VPN identifier within the RSVP-TE message. 214 Similarly, Resv messages sent from PE2 to PE1 need an RSVP-TE 215 mechanisms to assign them to the correct VPN. 217 3. Protocol Extensions and Procedures 219 This section provides the additional RSVP-TE objects to meet the 220 requirements described in Section 2. These are new variants of the 221 SESSION, SENDER_TEMPLATE and FILTERSPEC objects. These new objects 222 will act as identifiers and allow PEs to The new object types are 223 defined in Section 3.1, and the specific procedure is described in 224 Section 3.2. 226 3.1 Object Definitions 228 3.1.1 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 SESSION Object 230 The LSP_TUNNEL_VPN-IPv4 (or VPN-IPv6) SESSION object appears in 231 RSVP-TE messages that ordinarily contain a SESSION object and are 232 sent between ingress PE and egress PE in either direction. The object 233 MUST NOT be included in any RSVP-TE message that is sent outside of 234 the provider's backbone. 236 The LSP_TUNNEL_VPN-IPv6 SESSION object is analogous to the 237 LSP_TUNNEL_VPN-IPv4 SESSION object, using a VPN-IPv6 address 238 ([RFC4659]) instead of a VPN-IPv4 address ([RFC4364]). 240 This experimentation will be carried out using private Class Types. 241 These can be identified in this document as C-Type=EXPn: 243 Class = SESSION, LSP_TUNNEL_VPN-IPv4 C-Type = EXP1 244 Class = SESSION, LSP_TUNNEL_VPN-IPv6 C-Type = EXP2 245 Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv4 C-Type = EXP3 246 Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv6 C-Type = EXP4 247 Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv4 C-Type = EXP5 248 Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv6 C-Type = EXP6 250 Experimenters MUST ensure that there is no conflict between the 251 private Class Types used for this experiment and other Class 252 Types used by the PEs. 254 The formats of the objects are as follows: 256 Class = SESSION, LSP_TUNNEL_VPN-IPv4 C-Type = EXP1 258 0 1 2 3 259 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | | 262 + + 263 | VPN-IPv4 tunnel end point address (12 bytes) | 264 + + 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | MUST be zero | Tunnel ID | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Extended Tunnel ID | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Class = SESSION, LSP_TUNNEL_VPN-IPv6 C-Type = EXP2 273 0 1 2 3 274 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | | 277 + + 278 | VPN-IPv6 tunnel end point address | 279 + + 280 | (24 bytes) | 281 + + 282 | | 283 + + 284 | | 285 + + 286 | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | MUST be zero | Tunnel ID | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | | 291 + + 292 | Extended Tunnel ID | 293 + + 294 | (16 bytes) | 295 + + 296 | | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 The VPN-IPv4 tunnel end point address (respectively, VPN-IPv6 tunnel 300 end point address) field contains an address of 301 the VPN-IPv4 (respectively, VPN-IPv6) address family encoded as 302 specified in [RFC4364](respectively, [RFC4659]). 304 The Tunnel ID and Extended Tunnel ID are identical to the same fields 305 in the LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6 SESSION objects 306 as per [RFC3209]. 308 3.1.2 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 SENDER_TEMPLATE 309 Objects 311 The LSP_TUNNEL_VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object appears 312 in RSVP-TE messages that ordinarily contain a SENDER_TEMPLATE object 313 and are sent between ingress PE and egress PE in either direction 314 (such as Path, PathError, and PathTear). The object MUST NOT be 315 included in any RSVP-TE messages that are sent outside of the 316 provider's backbone. The format of the object is as follows: 318 Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv4 C-Type = EXP3 320 0 1 2 3 321 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | | 324 + + 325 | VPN-IPv4 tunnel sender address (12 bytes) | 326 + + 327 | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | MUST be zero | LSP ID | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv6 C-Type = EXP4 334 0 1 2 3 335 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | | 338 + + 339 | VPN-IPv6 tunnel sender address | 340 + + 341 | (24 bytes) | 342 + + 343 | | 344 + + 345 | | 346 + + 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | MUST be zero | LSP ID | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 The VPN-IPv4 tunnel sender address (respectively, VPN-IPv6 tunnel 353 sender address) field contains an address of the VPN-IPv4 354 (respectively, VPN-IPv6) address family encoded as specified 355 in [RFC4364] (respectively, [RFC4659]). 357 The LSP ID is identical to the LSP ID field in the LSP_TUNNEL_IPv4 358 and LSP_TUNNEL_IPv6 SENDER_TEMPLATE objects as 359 per [RFC3209]. 361 3.1.3 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 FILTER_SPEC Objects 363 The LSP_TUNNEL_VPN-IPv4 (or VPN-IPv6) FILTER_SPEC object appears in 364 RSVP-TE messages that ordinarily contain a FILTER_SPEC object and are 365 sent between ingress PE and egress PE in either direction (such as 366 Resv, ResvError, and ResvTear). The object MUST NOT be included in 367 any RSVP-TE messages that are sent outside of the provider's 368 backbone. 370 Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv4 C-Type = EXP5 372 The format of the LSP_TUNNEL_VPN-IPv4 FILTER_SPEC object is identical 373 to the LSP_TUNNEL_VPN-IPv4 SENDER_TEMPLATE object. 375 Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv6 C-Type = EXP6 377 The format of the LSP_TUNNEL_VPN-IPv6 FILTER_SPEC object is identical 378 to the LSP_TUNNEL_VPN-IPv6 SENDER_TEMPLATE object. 380 3.1.4 VPN-IPv4 and VPN-IPv6 RSVP_HOP Objects 382 The format of the VPN-IPv4 and VPN-IPv6 RSVP_HOP objects are 383 identical to objects described in [RFC6016]. 385 3.2 Handling 387 It assumes that ingress PEs and egress PEs in the context of BGP/MPLS 388 IP-VPNs have RSVP-TE capabilities. 390 3.2.1 Path Message Processing at Ingress PE 392 When a Path message arrives at the ingress PE (PE1 in Figure 1), the 393 PE needs to establish suitable Path state and forward the Path 394 message on to the egress PE (PE2 in Figure 1). In this section 395 we described the message handling process at the ingress PE. 397 1. CE1 would send a Path message to PE1 to establish the MPLS TE 398 LSP (VPN1) between CE1 and CE2. The Path message 399 is addressed to the eventual destination (the receiver at the 400 remote customer site) and carries the IP Router Alert option, 401 in accordance with [RFC2205]. The ingress PE must recognize 402 the router alert, intercept these messages and process them 403 as RSVP-TE signalling messages. 405 2. When the ingress PE receives a Path message from a CE that is 406 addressed to the receiver, the VRF that is associated with the 407 incoming interface can be identified (this step does not 408 deviate from current behavior). 410 3. The tunnel end point address of the receiver is looked up in 411 the appropriate VRF, and the BGP Next-Hop for that tunnel end 412 point address is identified. The next-hop is the egress PE. 414 4. A new LSP_TUNNEL_VPN-IPv4/VPN-IPv6 SESSION object is 415 constructed, containing the Route Distinguisher (RD) that is 416 part of the VPN-IPv4/VPN-IPv6 route prefix for this tunnel end 417 point address, and the IPv4/IPv6 tunnel end point address from 418 the original SESSION object. 420 5. A new LSP_TUNNEL_VPN-IPv4/IPv6 SENDER_TEMPLATE object is 421 constructed, with the original IPv4/IPv6 tunnel sender address 422 from the incoming SENDER_TEMPLATE plus the RD that is used by 423 the PE to advertise the prefix for the customers VPN. 425 6. A new Path message is sent containing all the objects from the 426 original Path message, replacing the original SESSION and 427 SENDER_TEMPLATE objects with the new 428 LSP_TUNNEL_VPN-IPv4/VPN-IPv6 type objects. This Path message is 429 sent directly to the egress PE (the next hop as being looked up 430 in step 3 above) without IP Router Alert. 432 3.2.2 Path Message Processing at Egress PE 434 In this section we described the message handling process at the 435 egress PE. 437 1. When a Path message arrives at the egress PE (PE2 in 438 Figure 1) , it is addressed to the PE itself, and is handed 439 to RSVP for processing. 441 2. The router extracts the RD and IPv4/IPv6 address from the 442 LSP_TUNNEL_VPN-IPv4/VPN-IPv6 SESSION object, and determines 443 the local VRF context by finding a matching VPN-IPv4 prefix 444 with the specified RD that has been advertised by this router 445 into BGP. 447 3. The entire incoming RSVP message, including the VRF 448 information, is stored as part of the Path state. 450 4. The egress PE can now construct a Path message which differs 451 from the Path message it received in the following ways: 453 a. Its tunnel end point address is the IP address extracted 454 from the SESSION object; 456 b. The SESSION and SENDER_TEMPLATE objects are converted 457 back to IPv4-type/IPv6-type by discarding the attached 458 RD; 460 c. The RSVP_HOP object contains the IP address of the 461 outgoing interface of the egress PE and an Logical 462 Interface Handle (LIH), as per normal RSVP processing. 464 5. The egress PE then sends the Path message on towards its 465 tunnel end point address over the interface identified above. 466 This Path message carries the IP Router-Alert option as 467 required by [RFC2205]. 469 3.2.3 Resv Processing at Egress PE 470 When a receiver at the customer site originates a Resv message for 471 the session, normal RSVP procedures apply until the Resv, making its 472 way back towards the sender, arrives at the "egress" PE (it is 473 "egress" with respect to the direction of data flow, i.e. PE2 in 474 figure 1). On arriving at PE2, the SESSION and FILTER_SPEC objects 475 in the Resv, and the VRF in which the Resv was received, are used to 476 find the matching Path state stored previously. 478 The PE constructs a Resv message to send to the RSVP HOP stored in 479 the Path state, i.e., the ingress PE (PE1 in Figure 1). The LSP 480 TUNNEL IPv4/IPv6 SESSION object is replaced with the same 481 LSP_TUNNEL_VPN-IPv4/VPN-IPv6 SESSION object received in the Path. The 482 LSP TUNNEL IPv4/IPv6 FILTER_SPEC object is replaced with a 483 LSP_TUNNEL_VPN-IPv4/VPN-IPv6 FILTER_SPEC object, which copies the 484 VPN-IPv4/VPN-IPv6 address from the LSP TUNNEL SENDER_TEMPLATE 485 received in the matching Path message. 487 The Resv message MUST be addressed to the IP address contained within 488 the RSVP_HOP object in the Path message. 490 3.2.4 Resv Processing at Ingress PE 492 Upon receiving a Resv message at the ingress PE (with respect to data 493 flow, i.e. PE1 in Figure 1), the PE determines the local VRF context 494 and associated Path state for this Resv by decoding the received 495 SESSION and FILTER_SPEC objects. It is now possible to generate a 496 Resv message to send to the appropriate CE. The Resv message sent to 497 the ingress CE will contain LSP TUNNEL IPv4/IPv6 SESSION and LSP 498 TUNNEL FILTER_SPEC objects, derived from the appropriate Path state. 500 3.2.5 Other RSVP Messages 502 Processing of other RSVP messages, i.e., PathError, PathTear, 503 ResvError, ResvTear, and ResvConf message in general follows the 504 rules defined in [RFC2205], with additional rules that MUST be 505 observed for messages transmitted within the VPN, i.e., between the 506 PEs as follows: 508 o The SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects MUST be 509 converted from LSP_TUNNEL_IPv4/LSP_TUNNEL_IPv6 [RFC3209] to 510 LSP_TUNNEL_VPN_IPv4/LSP_TUNNEL_VPN_IPv6 form, respectively, and 511 back in the same manner as described above for Path and Resv 512 messages. 514 o The appropriate type of RSVP_HOP object (VPN-IPv4 or VPN-IPv6) MUST 515 be used as described in Section 8.4 of [RFC6016]. 517 o Depending on the type of RSVP_HOP object received from the 518 neighbor, the message MUST be MPLS encapsulated or IP encapsulated. 520 o The matching state and VRF MUST be determined by decoding the 521 corresponding RD and IPv4 (respectively, IPv6) address in the 522 SESSION and FILTER_SPEC objects. 524 o The message MUST be directly addressed to the appropriate PE, 525 without using the Router Alert Option. 527 4. Management Considerations 529 MPLS-TE based BGP/MPLS IP-VPNs are based on a peer model. If an 530 operator would like to configure a new site to an existing VPN 531 configuration of both the CE router and the attached PE router is 532 required. The operator is not required to modify the configuration 533 of PE routers connected to other sites or modify the configuration 534 of other VPNs. 536 4.1 Impact on Network Operation 538 It is expected that the use of the extensions specified in this 539 document will not significantly increase the level of operational 540 traffic. 542 Furthermore, the additional extensions described in this document 543 will have no impact on the operation of existing resiliency 544 mechanisms available within MPLS-TE. 546 5. Security Considerations 548 This document defines RSVP-TE extensions for BGP/MPLS IP-VPNs. The 549 general security issues for RSVP-TE are described in [RFC3209], 550 [RFC4364] addresses the specific security considerations of BGP/MPLS 551 VPNs. General security considerations for MPLS are described in 552 [RFC5920]. 554 In order to secure the control plane, techniques such as TCP 555 Authentication Option (TCP-AO) [RFC5925] MAY be used authenticate BGP 556 messages. 558 To ensure the integrity of an RSVP request, the RSVP Authentication 559 mechanisms defined in [RFC2747], update by [RFC3097], SHOULD be used. 561 6. IANA Considerations 563 This document makes no request for IANA actions. 565 7. References 566 7.1 Normative References 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, March 1997. 571 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 572 V. and Swallow, G., "RSVP-TE: Extensions to RSVP for 573 LSP Tunnels", RFC 3209, December 2001. 575 7.2 Informative References 577 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and 578 Jamin, S., "Resource ReSerVation Protocol (RSVP) -- 579 Version 1 Functional Specification", RFC 2205, 580 September 1997. 582 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP 583 Cryptographic Authentication", RFC 2747, January 2000. 585 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 586 Authentication -- Updated Message Type Value", 587 RFC 3097, April 2001. 589 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 590 Networks (VPNs)", RFC 4364, February 2006. 592 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and 593 F. Le Faucheur, "BGP-MPLS IP Virtual Private Network 594 (VPN) Extension for IPv6 VPN", RFC 4659, 595 September 2006. 597 [RFC5824] Kumaki, K., Zhang, R. and Kamite, Y., "Requirements for 598 supporting Customer RSVP and RSVP-TE over a BGP/MPLS 599 IP-VPN", RFC 5824, April 2010. 601 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 602 Networks", RFC 5920, July 2010. 604 [RFC5925] J. Touch, et. al., "The TCP Authentication Option", 605 RFC5925, June 2010. 607 [RFC6016] Davie, B., Faucheur, F. and Narayanan, A., "Support for 608 the Resource Reservation Protocol (RSVP) in Layer 3 609 VPNs", RFC 6016, October 2010. 611 8. Acknowledgments 613 The authors would like to express thanks to Makoto Nakamura and 614 Daniel King for their helpful and useful comments and feedback. 616 9. Author's Addresses 618 Kenji Kumaki 619 KDDI Corporation 620 Garden Air Tower 621 Iidabashi, Chiyoda-ku, 622 Tokyo 102-8460, JAPAN 623 Email: ke-kumaki@kddi.com 625 Tomoki Murai 626 Furukawa Network Solutions Corp. 627 5-1-9, Higashi-Yawata, Hiratsuka 628 Kanagawa 254-0016, JAPAN 629 Email: murai@fnsc.co.jp 631 Dean Cheng 632 Huawei Technologies 633 2330 Central Expressway 634 Santa Clara CA 95050, U.S.A. 635 Email: dean.cheng@huawei.com 637 Satoru Matsushima 638 Softbank Telecom 639 1-9-1,Higashi-Shimbashi,Minato-Ku 640 Tokyo 105-7322, JAPAN 641 Email: satoru.matsushima@g.softbank.co.jp 643 Peng Jiang 644 KDDI Corporation 645 Garden Air Tower 646 Iidabashi, Chiyoda-ku, 647 Tokyo 102-8460, JAPAN 648 Email: pe-jiang@kddi.com 650 10. Contributors' Addresses 652 Chikara Sasaki 653 KDDI R&D Laboratories, Inc. 654 2-1-15 Ohara Fujimino 655 Saitama 356-8502, JAPAN 656 Email: ch-sasaki@kddilabs.jp 658 Daisuke Tatsumi 659 KDDI Corporation 660 Garden Air Tower 661 Iidabashi, Chiyoda-ku, 662 Tokyo 102-8460, JAPAN 663 Email: da-tatsumi@kddi.com