idnits 2.17.1 draft-saad-teas-rsvpte-ip-tunnels-01.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 : ---------------------------------------------------------------------------- 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 date (November 04, 2019) is 1628 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) == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group T. Saad 3 Internet-Draft V. Beeram 4 Intended status: Standards Track Juniper Networks 5 Expires: May 7, 2020 November 04, 2019 7 IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels 8 draft-saad-teas-rsvpte-ip-tunnels-01 10 Abstract 12 This document describes the use of RSVP (Resource Reservation 13 Protocol), including all the necessary extensions, to establish 14 Point-to-Point (P2P) Traffic Engineered IP (IP-TE) Label Switched 15 Path (LSP) tunnel(s) for use in native IP forwarding networks. 17 This document proposes specific extensions to the RSVP protocol to 18 allow the establishment of explicitly routed IP paths using RSVP as 19 the signaling protocol. The result is the instantiation of an IP 20 Path which can be automatically routed away from network failures, 21 congestion, and bottlenecks. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 7, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Overview of IP LSP Tunnels . . . . . . . . . . . . . . . . . 4 61 3.1. Creation and Management . . . . . . . . . . . . . . . . . 4 62 3.2. Path Maintenance . . . . . . . . . . . . . . . . . . . . 5 63 3.3. Signaling Extensions . . . . . . . . . . . . . . . . . . 5 64 3.3.1. RSVP Path message . . . . . . . . . . . . . . . . . . 5 65 3.4. RSVP Resv Label Object . . . . . . . . . . . . . . . . . 6 66 3.5. EAB address Handling . . . . . . . . . . . . . . . . . . 7 67 3.5.1. Egress Router . . . . . . . . . . . . . . . . . . . . 7 68 3.5.2. Ingress and Transit Router . . . . . . . . . . . . . 7 69 3.6. Protection . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.7. Shared Forwarding . . . . . . . . . . . . . . . . . . . . 8 71 3.8. Error Conditions . . . . . . . . . . . . . . . . . . . . 9 72 4. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 76 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 9.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 In native IP networks, each router runs a routing protocol to 85 determine the best next-hop(s) to a specific destination. The best 86 next-hop(s) are usually determined by favoring those that run along 87 the shortest path to the destination. When data flows across the 88 network, it is routed hop-by-hop and follows the selected path by 89 each hop towards that destination on each hop. 91 It is sometimes desirable for an ingress router to be able to steer 92 traffic towards a destination along a pre-determined or pre-computed 93 path that may follow a path other than the default shortest path. 94 For example, some flows mayrequire to be forwarded along the least 95 latency path. Others, may desire to be routed with bandwidth 96 guarantees along the selected path, or along a path that honors 97 certain resource affinities or Shared Risk Link Group (SRLG) 98 memberships. 100 A solution to such use-cases entails: 1) router(s) in the network to 101 be able to maintain and disseminate per link state information, 2) 102 ingress routers or an external server to be able to perform a 103 stateful path computation for feasible path(s) on top of the network 104 topology, and 3) for ingress router(s) to be able to steer or tunnel 105 the traffic along the established path towards the destination. 107 Mechanisms have been defined to achieve this with RSVP extensions for 108 Traffic Engineered Multiprotocol Label Switching (MPLS-TE) networks 109 as described in [RFC3209]. This document proposes extensions to the 110 existing mechanisms for achieving this in networks that rely on 111 native IP for their forwarding. 113 This document covers the necessary extensions for establishing Point- 114 to-Point (P2P) Traffic-Engineered IP (IP-TE) Label Switched Path 115 (LSP) Tunnels. The equivalent extensions needed for setting up 116 multicast IP-TE LSPs are currently out of the scope of this document. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 2.1. Acronyms 128 The reader is assumed to be familiar with the terminology used in 129 [RFC2205] and [RFC3209]. 131 IP-TE LSP (Traffic Engineered IP Label Switched Path): 133 The path created by programming of an IP route along the 134 explicitly specified or dynamically computed sequence of router 135 hops, allowing an IP packet to be forwarded from one hop to 136 another along the established path. 138 IP-TE LSP Tunnel: 140 An IP-TE LSP which is used to tunnel traffic over the pre- 141 established IP path. 143 Traffic Engineered IP Tunnel (IP-TE Tunnel): 145 A set of one or more IP-TE LSP Tunnels which carries a traffic 146 trunk. 148 3. Overview of IP LSP Tunnels 150 IP-TE LSP tunnels are established over a native IP forwarding 151 network. In many cases, IP-TE LSP(s) are explicitly routed from an 152 ingress router. The explicit route used to establish an IP-TE LSP 153 may be locally computed at the ingress router, or externally computed 154 by an entity such as a Path Computation Element (PCE) [RFC4655]. 156 To support the setup of IP-TE LSP tunnel(s), the egress routers 157 reserve one or more local IP prefixes or Egress Address Block(s) 158 (EABs) that are dedicated for RSVP to establish IP-TE LSP(s) tunnels. 160 The EAB(s) addresses at the egress router are only managed by the 161 RSVP protocol and are not required to be exchanged by any other 162 routing protocol. 164 It is possible in some cases, where the IP-TE LSP(s) are contained 165 within a single administrative domain boundary, for EAB(s) to be 166 allocated from the private IP address space as defined in [RFC1918] 167 or from the unique-local space as defined in [RFC4193] and [RFC6890]. 169 Also useful in some applications for sets of IP-TE LSP tunnels to be 170 associated together to facilitate reroute operations or to spread a 171 traffic trunk over multiple IP-TE LSP tunnel paths. For traffic 172 engineering applications to IP-TE LSP tunnel(s), such sets are called 173 traffic engineered tunnels (TE IP tunnels). 175 3.1. Creation and Management 177 An IP-TE LSP tunnel is unidirectional in nature. To create an IP-TE 178 LSP tunnel, the ingress router of the IP-TE LSP tunnel creates an 179 RSVP Path message with a session type of LSP_TUNNEL_IPv4 or 180 LSP_TUNNEL_IPv6 and follows the procedures outlined in [RFC3473] to 181 insert a Generalized Label Request object into the Path message. The 182 Generalized Label Request object indicates that an IP address binding 183 is requested to the IP-TE LSP tunnel. The binding of an EAB address 184 to an IP-TE LSP tunnel happens at the egress router and is signaled 185 using an RSVP Resv message sent from the egress router. 187 The ingress router uses a pre-computed explicit path to populate the 188 EXPLICIT_ROUTE object that is added the RSVP Path message. The 189 explicitly routed path can be administratively specified, or 190 automatically computed by a suitable entity based on QoS and policy 191 requirements, taking into consideration the prevailing network state. 192 In addition, RSVP-TE signaling [RFC3209] allows for the specification 193 of an explicit path as a sequence of strict and loose routes. Such 194 combination of abstract nodes, and strict and loose routes 195 significantly enhances the flexibility of path definitions. 197 The ingress MAY also add a RECORD_ROUTE object to the RSVP Path 198 message in order to receive information about the actual route 199 traversed by the IP-TE LSP tunnel. The RECORD_ROUTE object MAY also 200 be used by the egress router to determine whether Shared Forwarding 201 as described in Section 3.7 is possible amongst different IP-TE LSP 202 tunnel(s). 204 3.2. Path Maintenance 206 If the ingress router discovers a better path, after an IP-TE LSP 207 tunnel has been successfully established, it can dynamically reroute 208 the session by changing the EXPLICIT_ROUTE object. If problems are 209 encountered with the EXPLICIT_ROUTE object, either because it causes 210 a routing loop or because some intermediate routers do not support 211 it, the ingress is notified. 213 Make-before-break procedures can also be employed to modify the 214 characteristics of an IP-TE LSP tunnel. As described in [RFC3209], 215 the LSP ID in the Sender Template object is updated in the new RSVP 216 Path message that is signaled. As usual, the combination of the 217 LSP_TUNNEL SESSION object and the SE reservation style naturally 218 accommodates smooth transitions in bandwidth and routing. 220 For example, to trigger a bandwidth increase, a new RSVP Path Message 221 with a new LSP_ID can be used to attempt a larger bandwidth 222 reservation while the current LSP_ID continues to be refreshed to 223 ensure that the reservation is not lost if the larger reservation 224 fails. 226 3.3. Signaling Extensions 228 This section describes RSVP signaling extensions and modifications to 229 existing RSVP objects that are carried in RSVP Path or Resv messages 230 and are required to establish IP-TE LSP tunnel(s). 232 3.3.1. RSVP Path message 234 To signal an IP-TE LSP tunnel, the Generalized Label Request object 235 is carried in the RSVP Path message and used to request an IP address 236 binding to the IP-TE LSP tunnel. 238 The Generalized Label Request is defined in [RFC3471] and has the 239 below format: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | LSP Enc. Type |Switching Type | G-PID | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 To request an IPv4 or IPv6 binding to an IP-TE LSP tunnel, the 248 Generalized Label object carries the following specifics: 250 1. the LSP encoding type is set to Packet (1) [RFC3471]. 252 2. the LSP switching type is set to "IPv4-TE" (TBD1), or IPv6-TE 253 (TBD2) 255 3. the Generalized Payload Identifier (G-PID) MAY be set to All 256 (0) or in some cases to the specific payload type if known, 257 e.g. Ethernet (33) [RFC3471]. 259 3.4. RSVP Resv Label Object 261 The egress is responsible to bind an IP EAB address to an IP-TE LSP 262 tunnel. 264 Once the egress router receives the RSVP Path message with the 265 Generalized Label Request object containing the parameters described 266 in Section 3.3.1, the egress router determines and binds an EAB 267 address to the newly established IP-TE LSP tunnel. Note, subject to 268 a local policy and additional path check(s), the egress MAY assign an 269 already in used EAB address to the newly established IP-TE LSP 270 tunnel. 272 The RSVP Resv message that is created by the egress router uses the 273 Generalized Label defined in [RFC3471] to carry the EAB address that 274 is bound to newly established IP-TE LSP tunnel. 276 The RSVP Generalized Label object has the following format: 278 LABEL class = 16, C_Type = 2 280 The information carried in a Generalized Label is: 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Label | 286 | ... | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Label (Variable Length): 291 Carries label information. The interpretation of this field 292 depends the parameters signaled in the Generalized Label 293 Request. 295 3.5. EAB address Handling 297 The RSVP Resv message that is created by the egress router is 298 forwarded upstream along the signaling path towards the ingress 299 router. Each router starting from the egress will perform the 300 following steps when binding the EAB address to the IP-TE LSP tunnel. 302 3.5.1. Egress Router 304 The egress router manages the EAB addresses for the use of 305 establishing IP LSP tunnel(s). 307 The egress router MAY assign unique EAB address to newly established 308 IP-TE LSP tunnel(s) and MAY free an existing EAB address upon 309 destroying a previously established IP-TE LSP tunnel. Note that an 310 egress router MAY hold on to an EAB when the IP-TE LSP is being 311 destroyed if it determines other IP-TE LSP(s) are sharing it. 313 Once an EAB address is allocated and bound to a new IP-TE LSP tunnel, 314 the egress router programs the address in its forwarding table as 315 local address - hence, resulting in decapsulation of the outer IP 316 header on any packet arriving over the IP-TE LSP tunnel and hence 317 yielding the original IP datagram that was tunneled over the IP LSP 318 tunnel, 320 3.5.2. Ingress and Transit Router 322 A transit or an ingress router extracts the EAB address that the 323 egress router binds to the IP-TE LSP tunnel from the Generalized 324 Label object contained in the RSVP Resv message that is propagated 325 upstream as described in Section 3.4. The transit or ingress router 326 uses the EAB address to program an IP route in the Routing 327 Information Base (RIB) and uses the previously signaled 328 EXPLICIT_ROUTE object to derive the next-hop information associated 329 with the EAB route at that hop. 331 An advantage of using RSVP to establish IP-TE LSP tunnels is that it 332 enables the allocation of resources along the path. For example, 333 bandwidth can be allocated to each IP-TE LSP tunnel using standard 334 RSVP reservations as described in [RFC3209]. 336 3.6. Protection 338 Fast Reroute (FRR) procedures that are defined in [RFC4090] describe 339 the mechanisms for router along the LSP path to act as a Point of 340 Local Repair (PLR) and reroute traffic and signaling of a protected 341 RSVP-TE LSP onto a pre-established bypass tunnel in the event of a 342 protected TE link or node failure. 344 Similar mechanisms can be employed for protecting IP-TE LSP tunnel(s) 345 in IP network(s). An ingress or transit router acting as potential 346 PLR can pre-establish bypass tunnel(s) that protect the primary IP-TE 347 LSP tunnel against the protected link or downstream node failure. 349 Upon failure of the protected link, the traffic arriving over the 350 protected IP-TE LSP on the PLR is automatically tunneled over the 351 pre-established bypass IP-TE LSP tunnel and packets are forwarded 352 towards the Merge Point (MP) router. At the MP router, the incoming 353 IP packets are decapsulated exposing the original IP header of the 354 protected IP-TE LSP tunnel. The packets are forwarded downstream of 355 the MP router along the 357 3.7. Shared Forwarding 359 One capability of the IP data plane is its ability to reuse the IP 360 forwarding entry when setting up IP-TE LSP(s) from multiple sources 361 and that share a common destination. This capability MAY be 362 preserved provided certain requirements are met. We refer to this 363 capability as "Shared Forwarding". Shared Forwarding is a local 364 policy local to egress router responsible for binding an EAB address 365 to the signaled IP-TE LSP tunnel. 367 The Shared Forwarding function allows the reduction of forwarding 368 entries on any transit router RIB. The Shared forwarding paths are 369 identical in function to independently routed Multi-point to Point 370 (MP2P) paths that share part of their path(s) from the intersecting 371 router and towards the egress router. 373 If the egress router policy allows for Shared Forwarding, and upon 374 signaling a new IP-TE LSP tunnel, the egress inspects the recorded 375 path (extracted from the RECORD_ROUTE object). If the egress router 376 determines that the newly signaled IP-TE LSP path intersects and 377 merges with other IP-TE LSP from the intersection point to the 378 egress, and if Shared Forwarding is enabled, it MUST assign the same 379 EAB address bound to the existing IP-TE LSP tunnel. 381 Note, forwarding memory savings from Shared Forwarding can be quite 382 dramatic in some topologies where a high degree of meshing is 383 required. 385 3.8. Error Conditions 387 This section will be updated in future revisions of this document. 389 4. Next Steps 391 The authors of this document are following up with the DetNet Working 392 Group on ways to leverage this solution to signal and establish a TE 393 IP path for a DetNet IP flow. The DetNet IP data plane uses 394 "6-tuple" based flow identification as described in 395 [I-D.ietf-detnet-ip]. 397 A new revision of this document will be posted to describe the 398 extensions required to signal the necessary flow identification so it 399 can be programmed on all hops of the IP Path. 401 5. IANA Considerations 403 This section will be updated in future revisions of this document. 405 6. Security Considerations 407 This section will be updated in future revisions of this document. 409 7. Acknowledgement 411 The authors would like to thank Igor Bryskin for providing valuable 412 feedback to this document. 414 8. Contributors 416 Raveendra Torvi 417 Juniper Networks 419 Email: rtorvi@juniper.net 421 9. References 423 9.1. Normative References 425 [I-D.ietf-detnet-ip] 426 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 427 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", 428 draft-ietf-detnet-ip-03 (work in progress), October 2019. 430 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 431 and E. Lear, "Address Allocation for Private Internets", 432 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 433 . 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, 437 DOI 10.17487/RFC2119, March 1997, 438 . 440 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 441 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 442 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 443 September 1997, . 445 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 446 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 447 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 448 . 450 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 451 Switching (GMPLS) Signaling Functional Description", 452 RFC 3471, DOI 10.17487/RFC3471, January 2003, 453 . 455 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 456 Switching (GMPLS) Signaling Resource ReserVation Protocol- 457 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 458 DOI 10.17487/RFC3473, January 2003, 459 . 461 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 462 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 463 DOI 10.17487/RFC4090, May 2005, 464 . 466 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 467 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 468 . 470 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 471 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 472 May 2017, . 474 9.2. Informative References 476 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 477 Element (PCE)-Based Architecture", RFC 4655, 478 DOI 10.17487/RFC4655, August 2006, 479 . 481 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 482 "Special-Purpose IP Address Registries", BCP 153, 483 RFC 6890, DOI 10.17487/RFC6890, April 2013, 484 . 486 Authors' Addresses 488 Tarek Saad 489 Juniper Networks 491 Email: tsaad@juniper.net 493 Vishnu Pavan Beeram 494 Juniper Networks 496 Email: vbeeram@juniper.net