idnits 2.17.1 draft-ietf-rsvp-routing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 30, 1995) is 10527 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) -- Looks like a reference, but probably isn't: 'Note 1' on line 176 -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Deborah Estrin 3 Expiration: December 1995 USC/ISI 4 File: draft-ietf-rsvp-routing-00.txt Scott Shenker 5 PARC 6 Daniel Zappala 7 USC/ISI 9 Routing Support For RSVP 11 June 30, 1995 13 Status of Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 29 Rim). 31 Abstract 33 This memo describes an interface between RSVP and routing protocols. 34 The interface allows RSVP to request information and services from 35 routing in the form of an asynchronous query-reply protocol. 37 1. Introduction 39 This document describes an interface between RSVP [4] [3] and routing 40 protocols. The interface allows RSVP to request information and 41 services from routing in the form of an asynchronous query-reply 42 protocol. This document describes the design of the interface and 43 details a specification of a portion of the interface based on our 44 experience using RSVP with DVMRP [2] as a supporting multicast 45 routing protocol. The routing services we discuss represent only a 46 subset of the functionality that RSVP may need; we are continuing to 47 investigate other services. This document assumes familiarity with 48 RSVP. 50 First, Section 2 presents a brief overview of relevant RSVP 51 functionality and some routing problems RSVP encounters. These 52 problems lead to a set of RSVP's requirements for routing, presented 53 in Section 3. Section 4 details a general routing model that RSVP 54 can use to interact with a variety of different routing protocols. 55 Section 5 outlines the particular queries and responses that comprise 56 the interface between RSVP and routing, focusing on how RSVP uses 57 this interface. Section 6 discusses the costs and limitations placed 58 on routing if it implements the services requested by RSVP. Finally, 59 Section 7 details the specification of the interface messages. 61 2. RSVP Overview 63 Using RSVP, sources send "Path" messages hop-by-hop to the 64 destination. Each router uses the "Path" message to create reverse- 65 path routing state and forwards the message toward the destination. 66 Receivers send "Resv" messages toward sources, following the 67 reverse-path routing state. Each router uses the "Resv" message to 68 query admission control and accept or reject the embedded reservation 69 request. All of the routing and reservation state is "soft-state"; 70 RSVP refreshes the soft-state periodically and removes it after a 71 period of inactivity. 73 Note that after RSVP processes a "Path" message at a router, it re- 74 sends it as if it originated from the original sender. For multicast 75 destinations, the forwarding entry depends on both the source and the 76 destination; thus RSVP can only resume forwarding of the "Path" 77 message if it knows the necessary routing entry. RSVP may also need 78 to send a different "Path" message out each outgoing interface on 79 multicast routers. It needs this functionality to establish 80 reverse-path routing information, to advertise service 81 characteristics [1] over different branches of a multicast tree, to 82 send multicast Path messages over non-RSVP clouds, and to pack 83 multicast Path messages. Thus, for this functionality, RSVP may also 84 need to know the necessary routing entry. 86 RSVP has no knowledge of route changes, other than by capturing them 87 with periodic "Path" messages. In addition, once a route changes, 88 RSVP has no guarantee that the new path can be reserved at a level 89 equal to the old one. Thus, route changes may lead to a long-term 90 service disruption. Figure 1 shows an example of how this may 91 happen. Receiver R1 has reserved a branch of the existing multicast 92 tree. A link comes back into service, causing routing to find a new 93 shortest path. Multicast routing adapts to this change and the 94 reservation protocol sends a reservation up the new route. The 95 reservation fails, however, and R1 is left without a reserved route. 97 S 98 | 99 [ ] 100 / S 101 / S 102 / S 103 [ ] [ ] S : multicast tree for S 104 X T S 105 ^ T S T : link comes back into 106 M T S service 107 [ ]SSSSS[ ] 108 S S ^ : attempt to use "better" 109 ^ S S M route 110 M S S 111 [ ] [ ] X : reservation failure 112 S S 113 ^ S S 114 M S S 115 [ ] [ ] 116 | | 117 R1 R2 119 Figure 1: Service Disruption Caused by Route Change 121 RSVP is also limited to establishing reservations over whichever path 122 routing chooses. Most routing protocols maintain a single, shortest 123 path between a source and destination. We refer to this shortest 124 path as the "default route". If RSVP is unable to attain a 125 reservation over the default route, then it has no recourse. 127 3. RSVP Requirements 129 To address these limitations, we have designed an interface between 130 RSVP and routing. Using this interface, RSVP may acquire routing 131 entries to allow it to send control messages hop-by-hop, as well as 132 request routing services that provide it with extra functionality. 133 We express the interface design as a set of requirements that RSVP 134 places on routing. The initial set of requirements includes: 136 o supplying on demand the forwarding entry for a source- 137 destination pair, 139 o providing notification of route changes for supplied routes, 141 o keeping a working route in place once a reservation has been 142 secured, barring any failed links or routers along the route, 143 and 145 o constructing on demand explicit routes when a reservation 146 request is rejected along the default route. [Note 1] 148 We expect this list of requirements to grow as we continue to 149 investigate how routing can support RSVP. 151 RSVP needs to learn about routing entries for the reasons discussed 152 in Section 2. Note that for unicast routing RSVP does not need to 153 learn about routing entries; routing is based on destination only and 154 not on the source-destination pair. However, in order to provide a 155 common interface to all routing protocols, we do not distinguish 156 between unicast and multicast destinations. 158 RSVP requires notification of route changes so that it can adapt its 159 reservations to changes in the route between a source and 160 destination. It can do this by re-sending "Path" or "Resv" messages 161 where needed. For multicast destinations, a route change consists of 162 any change in the multicast tree for a source-group pair, including 163 prunes and grafts as well as routing changes due to failed or 164 recovered links. If routing can not support route change 165 notification, then RSVP must poll routing for route entries in order 166 to adapt to route changes. 168 Once RSVP secures a reservation over a route, it may request that 169 routing "pin" the route by not adapting to route changes other than 170 those caused by link or node failures. By providing this service, 171 routing allows RSVP to provide applications with a service commitment 172 that is interrupted only by failure along the committed path. If 173 routing can not support route pinning, then RSVP must adapt to 174 routing changes and may notify applications that its service 175 _________________________ 176 [Note 1] We use the term explicit routes in place of source routes 177 because they may be used by receivers as well as sources. 179 commitment is interruptable. As part of this service, routing may 180 also provide "smooth switching" from a reserved non-default route to 181 a reserved default route. This may allow routing to reduce its 182 overhead of maintaining non-default routes while still satisfying 183 RSVP's requirement. 185 Finally, if RSVP is unable to attain a reservation over the default 186 route, it may request that routing provide an alternate route between 187 the source and destination. By providing this service, routing and 188 RSVP can cooperate to find a route that satisfies a receiver's 189 service request. Routing can choose routes based on feedback from 190 RSVP concerning previous reservation availability. Routing also has 191 the option of rejecting an alternate path request if there are no 192 available paths. Figure 2 shows an example of using an alternate 193 route. Receiver R2 has already reserved a branch of the existing 194 multicast tree. Receiver R1 joins the tree, but its reservation 195 attempt fails. Routing supplies a new route and the second 196 reservation attempt succeeds. 198 S 199 | 200 [ ] 201 / S 202 / S 203 / S 204 [ ] [ ] S : multicast tree for S 205 X | S 206 ^ | S ^ : first reservation attempt 207 M | N> S M 208 [ ]-----[ ] 209 / S X : reservation failure 210 ^ /^ S 211 M / N S ^ : second reservation attempt 212 [ ] [ ] N 213 | S 214 ^ | ^ S 215 M | N S 216 [ ] [ ] 217 | | 218 R1 R2 220 Figure 2: Using Alternate Routes 222 4. RSVP Routing Model 224 Because RSVP must learn about routing entries from a variety of 225 different routing protocols, we have adopted portions of the DVMRP 226 routing model [2] as an abstraction through which RSVP can 227 communicate with all routing protocols. A routing entry for a 228 source-destination pair consists of an incoming virtual interface and 229 a set of outgoing virtual interfaces. A virtual interface is simply 230 a number that routing creates to refer to each of the interfaces (or 231 virtual interfaces) it uses to send and receive packets on the 232 router. Note that the implementation of the virtual interface is 233 hidden from RSVP; whether the interface is a real interface, a 234 pseudo-device, or a tunnel is irrelevant. 236 When RSVP receives a packet, it expects the forwarding engine to tell 237 it which virtual interface the packet arrived on. This allows RSVP 238 to suppress forwarding of packets that routing has determined have 239 arrived via the wrong incoming virtual interface, while still 240 allowing local processing. When RSVP sends a packet, it expects that 241 it can tell the forwarding engine to forward the packet directly over 242 a particular vif, without performing any of the forwarding engine's 243 usual routing checks or lookups. Together, these functions allow 244 RSVP to forward distinct packets hop-by-hop over each link in a 245 unicast or multicast path between a source and destination(s). 247 The RSVP routing model defines a virtual interface (or vif) using the 248 following attributes: 250 id a unique identifier, 252 threshold a TTL threshold, 254 status a bitmask status vector, and 256 local_addr a local address. 258 RSVP uses the TTL threshold to control the scope of a control 259 message. The status vector currently only defines whether the 260 virtual interface has been administratively disabled. 262 5. Routing Support 264 The following sections describe the routing support messages 265 exchanged by RSVP and routing. 267 5.1 Obtaining Routing Entries 269 Before RSVP can obtain routing entries, it must first discover 270 which virtual interfaces (vifs) routing is using. It does this by 271 issuing an Initial Query: 273 Initial_Query(). 275 Routing responds with an Initial Reply that includes the number of 276 vifs and a list of vifs as defined by the RSVP routing model: 278 Initial_Reply(num,vif_list). 280 Once RSVP has received the Initial Reply, it can begin requesting 281 routing entries by sending a Route Query for a source-destination 282 pair: 284 Route_Query(source,destination). 286 Routing responds by sending a Route Reply that includes the 287 incoming vif and an outgoing vif bitmask: 289 Route_Reply(source,destination,incoming_vif,outgoing_vif_bitmask). 291 5.2 Route Change Notification 293 RSVP can request notification of route changes by sending a Route 294 Query with an additional notification flag: 296 Route_Query(source,destination,notification). 298 By setting the notification flag in the query, RSVP requests that 299 routing provide route change notification. If routing is able to 300 provide this service, it sets a corresponding notification flag in 301 the Route Reply, otherwise it clears the flag. If RSVP receives a 302 Route Reply with the notification bit set, it can assume that 303 routing will notify it when the routing entry for the source- 304 destination pair changes. In the meantime, RSVP can use the 305 routing entry indefinitely. 307 5.3 Route Pinning 309 Once RSVP has reserved a route, it may request route pinning by 310 sending a Service Query to the last-hop router using a service 311 bitmask to indicate the service requested: 313 Service_Query(source,destination,service_bitmask,vif). 315 The Service Query may optionally include the vif between the 316 last-hop router and the host to indicate where the service begins. 318 The service bitmask codes two types of service: route pinning and 319 smooth switching. If routing can provide route pinning, then RSVP 320 can assume that the current route from the source to the 321 destination will remain unchanged until a link or node along the 322 route fails. If routing can provide smooth switching, then RSVP 323 can assume that routing will not switch from the pinned route to a 324 default route until (a) the default route is reserved or (b) the 325 pinned route fails. Smooth switching requires considerable 326 coordination between RSVP and routing; whether this is a viable 327 service is related to whether the network has enough information 328 to know how to respond, and whether another route reserved for the 329 same per-hop service will provide the same end-to-end QoS. 331 If RSVP requests route pinning, then routing attempts to pin the 332 route and returns a Service Reply in the same format with the 333 service bitmask set to indicate whether it could perform the 334 desired service. Routing may take a relatively longer time to 335 return a Service Reply than other replies because it may have to 336 contact other routers to determine whether it can provide the 337 requested service. In addition, if routing returns a Service 338 Reply indicating the route is pinned, it may later send an 339 unsolicited Service Reply indicating that the route is no longer 340 pinned. This may occur if a link or node fails, or if other 341 constraints prevent routing from continuing to pin the route. 343 5.4 Alternate Routes 345 If RSVP fails to obtain a reservation over the default route, it 346 may request an alternate route by sending a Service Query to the 347 last-hop router as defined above. The service bitmask indicates 348 RSVP's request for an alternate route. Routing returns a Service 349 Reply indicating in the service bitmask whether it has provided 350 the requested service. 352 To provide routing with feedback on the reservation status of 353 routes, RSVP sends routing status reports to routing: 355 Status_Report(source,destination,status,vif,status_info). 357 At last-hop routers, RSVP tells routing whether a reservation over 358 the current route was successful, using a status of "success" or 359 "failure." The status info may contain failure information or the 360 level of reservation attained; routing can use this as input to 361 its route selection process. 363 RSVP also sends routing status reports to help it when 364 coordinating alternate path requests. At every router, RSVP tells 365 routing whether it has reserved the incoming link for a particular 366 route, using a status of "unreserved" or "reserved." Routing 367 assumes that all links are unreserved until told otherwise. When 368 a receiver joins a multicast tree, it may re-route unreserved 369 branches of the tree if it carries an explicit route for a 370 different branch. However, receivers may not re-route reserved 371 branches; routing should maintain stability for receivers that 372 have already obtained a reservation. 374 6. Service Costs and Limitations 376 Each of the functions described above introduces routing costs and 377 limitations. 379 Routing incurs very little cost for providing route change 380 notification; essentially it only has to tag the subset of its 381 routing entries for which RSVP is interested in receiving 382 notification. This amounts to keeping an extra bit for each routing 383 entry. Since this service can be provided independently by each 384 router, its implementation is not subject to any interoperability 385 constraints. 387 Providing route pinning introduces substantial costs for some routing 388 protocols. If a routing protocol uses aggregation and maintains 389 routes based on a group of sources (for example a subnet), then 390 pinning a route requires extra source-specific state that would not 391 otherwise be kept. Routing must continue to maintain the aggregated 392 route for non-pinned sources. 394 Routers that implement route pinning will also encounter some basic 395 operational limitations of the service. For example, pinning a 396 portion of the multicast tree for one receiver has the side effect of 397 pinning those links for all other downstream receivers. Some 398 protocols may require that all routers between the source and 399 destination must support route pinning in order to provide the 400 service. In addition, if a router starts to pin a route during a 401 route change, it may pin the wrong route. In some situations, 402 routing may pin the route back onto itself, forming a black hole. 403 The routing protocol needs added protocol mechanisms to keep pinning 404 from disrupting the integrity of routing. 406 Routers that implement alternate path routing encounter the same 407 costs and limitations as with route pinning. One significant 408 difference is that the likelihood of forming black holes is much 409 greater. Consider Figure 3, where receivers R1 and R2 both want to 410 use an alternate route for a multicast tree of sender S. Routing 411 uses an explicitly-routed graft for each receiver. Depending on the 412 sequence of links that the two grafts travel, they may form a black 413 hole in the multicast tree. 415 S 416 | 417 [ ] 418 / \ 419 N/ \M 420 / \ 421 [ ] [ ] M : intended explicit 422 | | explicit route for R1 423 N| |M 424 |