idnits 2.17.1 draft-ietf-rsvp-routing-02.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-19) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 17 instances of too long lines in the document, the longest one being 6 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 (1 July 1998) is 9424 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Daniel Zappala 3 Expiration: January 1999 University of Oregon 4 File: draft-ietf-rsvp-routing-02.txt Jeff Kann 5 USC/ISI 7 RSRR: A Routing Interface For RSVP 9 1 July 1998 11 Status of Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 Abstract 32 This memo describes version 2 of RSRR, a routing interface for RSVP. 33 By using this interface, RSVP may obtain forwarding information from 34 routers and use it to place reservation state within the network. 35 Version 1 of this interface was designed primarily for RSVP 36 interaction with IPv4 multicast routing protocols. Version 2 adds 37 support for IPv4 unicast as well as IPv6 unicast and multicast 38 routing. A backwards compatibility mechanism is provided. 40 1. Introduction 42 This document describes Routing Support for Resource Reservations 43 (RSRR), an abstract interface by which RSVP [5] may obtain routing 44 information. RSVP is a resource reservation protocol used by hosts 45 to request Quality of Service from the network. RSVP does not 46 include a routing protocol; instead it may use any underlying routing 47 protocol(s) to determine where it should carry resource reservations. 48 The RSRR interface provides RSVP with forwarding table entries and 49 notifies it when those entries change. This document elaborates on 50 the routing support described in the RSVP spec [2]. 52 This document describes version 2 of RSRR. In addition to IPv4 53 multicast routing protocols, which were covered extensively in the 54 version 1 document, version 2 explicitly addresses IPv4 unicast 55 routing and adds support for IPv6 unicast and multicast routing. 56 Version 2, like version 1, also provides RSVP with information on the 57 interfaces known to RSRR. Finally, version 2 includes a backwards- 58 compatibility mechanism that allows RSVP to determine the version of 59 RSRR that a routing daemon is using. 61 Section 2 gives an overview of RSVP functionality and its 62 requirements for routing and kernel support. Section 3 describes 63 RSRR as an abstract service interface. Section 4 describes how this 64 interface might typically be implemented within RSVP. Appendix A 65 gives a specification of RSRR used for communication between RSVP and 66 routing daemons. Appendix B lists the RSRR version 1 specification, 67 which version 2 implementations must also support. This is included 68 for reference, since some implementations may support multiple 69 versions. Appendix C lists the implementation status of RSRR. 71 2. RSVP Overview and RSRR Motivation 73 Using RSVP, sources send "Path" messages hop-by-hop to the 74 destination (Figure 1a). Each router uses the "Path" message to 75 create reverse-path routing state and forwards the message toward the 76 destination. Receivers send "Resv" messages toward sources, 77 following the reverse-path routing state (Figure 1b). Each router 78 uses the "Resv" message to query admission control to accept or 79 reject the embedded reservation request. Reservation messages 80 utilize various "styles" to allow sharing among different senders. 81 For example, the shared-explicit style targets a reservation at a 82 list of senders, and the wildcard style targets a reservation at all 83 upstream senders (Figure 1c). 85 Sender Sender S2 S1 S3 86 - - - - - 87 | | | | | | | | | | 88 - P - R - - - 89 | P | R R \ / R / R 90 - P - R R - R - R 91 | | | | | | | | 92 P - P R - R - - 93 P / \ P R / \ R R \ / R 94 P / - R / - R - R 95 P / | | R / | | | | 96 P / P - P R / R - R - R 97 P / P / \ P R / R / \ R | R 98 - - - - - - - R 99 | | | | | | | | | | | | | | 100 - - - - - - - 101 R1 R2 R3 R1 R2 R3 Receiver 103 (a) PATH message (b) RESV message merged (c) RESV message branches 104 multicasted as it follows path as it travels toward 105 downstream state upstream multiple senders 107 Figure 1: RSVP Overview 109 With proper operating system support, a router could pull an RSVP " 110 Path" message out of the forwarding engine, do RSVP processing, and 111 then resume forwarding the message. However, multicast "Path" 112 messages have unique requirements. After RSVP performs its 113 processing, it may need to send a different copy of the "Path" 114 message out each outgoing interface. Normally, IP multicast 115 replicates datagrams and sends identical copies out each of the 116 outgoing interfaces. Thus, RSVP does not use regular IP multicast 117 forwarding and instead needs to replicate the "Path" messages on its 118 own and simulate its own multicast forwarding. 120 To accomplish this objective, RSVP needs to obtain forwarding table 121 entries from the routing protocol; this is what the RSRR interface is 122 for. In addition, the operating system must support several basic 123 functions for RSVP. First, RSVP needs to know which interface a 124 "Path" message arrives on. This allows RSVP to suppress forwarding 125 of multicast packets that routing has determined have arrived via the 126 wrong incoming interface. It also needs to receive all multicast 127 "Path" messages, even if they arrive on the wrong interface; this 128 allows RSVP processing to occur for local receivers. Second, RSVP 129 must be allowed to insert the original source address of the "Path" 130 message in its IP header This allows the "Path" message to be 131 processed by downstream routers as if it came from the original 132 source. Finally, when RSVP sends a multicast packet, it expects that 133 it can tell the operating system to forward the packet directly over 134 a particular interface, without performing any of the usual multicast 135 routing checks and without looping the packet back to other 136 interfaces. These operating system functions, combined with RSRR, 137 allow RSVP to forward distinct packets hop-by-hop over each link in a 138 multicast path between a source and destination(s). 140 When obtaining forwarding table entries from RSRR, RSVP also needs to 141 know whether the multicast routing protocol is using sender-rooted 142 (e.g shortest-path) trees or shared trees (e.g. with the PIM [3] or 143 CBT [1] multicast routing protocols). For shared trees, RSVP only 144 needs to obtain and store one route for all senders to the group. In 145 addition, RSVP must mimic the IP multicast forwarding model. This 146 means that for bidirectional shared trees, a packet can be accepted 147 over any interface and is forwarded over all other interfaces listed 148 in the route. 150 When running over shared trees, RSVP can also significantly decrease 151 the size of the "scope" object in wildcard filter "Resv" messages. 152 RSVP uses a "scope" object, listing all upstream senders, to prevent 153 looping of wildcard filter "Resv" messages [4] (Figure 2a). For 154 shared trees, RSVP can use a " scope" object that includes a wildcard 155 address, greatly reducing the size of the "Resv" message. A "Resv" 156 message with a wildcard address would follow shared tree state but 157 never sender tree state (Figure 2b). 159 S1 S2 S3 S1 S2 S3 160 - - - - - - 161 | | | | | | | | | | | | 162 - - - - - - 163 R \ / R / R R \ / R / R 164 R[1] - R[2] - R[3] R[*] - R[*] - R[3] 165 | | | | | | | | 166 - - - - 167 R \ / R R \ / R 168 R[1,2] - R[3] R[*] - R[3] 169 | | | | 170 - R - R 171 | R[1,2,3] | R[*,3] 172 - R - R 173 | | | | 174 - - 175 Receiver Receiver 177 (a) wildcard RESV message (b) wildcard RESV message with 178 carrying scope objects senders #1,2 on a shared tree 180 Figure 2: The "Scope" Object in Wildcard Reservations 182 3. Abstract Service Interface 184 We describe RSRR as an abstract service interface because it may be 185 realized in several different ways. For example, some 186 implementations may use system calls if the operating system can 187 supply the functionality of RSRR. In a typical implementation, RSVP 188 might use the RSRR abstraction as the basis of an interface to a 189 routing support module (see Section 4), in addition to using the RSRR 190 protocol (see Appendix A) to communicate with multicast routing 191 protocol daemons. 193 To achieve this generality, the following interface description uses 194 the term "RSRR client" to indicate the entity requesting routes and 195 the term "RSRR server" to indicate the responding entity. The client 196 is typically the RSVP daemon and the server is typically a routing 197 protocol daemon or the operating system. 199 The first thing an RSRR client must do is determine the set of 200 network interfaces the RSRR server is using. This allows the client 201 to make sense of the routes it acquires from the server. RSRR 202 represents network interfaces -- which may be physical interfaces, 203 tunnels, or any other operating system mechanism -- as "virtual 204 interfaces" or "vifs". A vif has the following attributes: 206 id a unique identifier, 208 threshold a TTL threshold, 210 prefix a CIDR prefix, 212 status a bitmask status vector, 214 family the address family, 216 length the address length, and 218 local_addr a local address. 220 This information represents what the RSRR client (e.g. RSVP) needs to 221 simulate IP multicast forwarding. IP multicast uses the "TTL threshold" 222 to control the scope of packets, checking it on a per-packet basis. A 223 newer form of administrative scoping is enforced on a per-route basis, 224 so it is reflected in the routes themselves and is thus transparent to 225 the RSRR client. The server may also define a "status" vector for any 226 other information it needs to pass to the client. 228 The RSRR client obtains the set of network interfaces by issuing an 229 Interface Query of the form: 231 Interface_Query(). 233 The server responds with an Interface Reply that includes the number of 234 vifs and a list of the vifs with their attributes as defined above: 236 Interface_Reply(num, vif_list). 238 The RSRR server automatically notifies the client if the set of inter- 239 faces or their status changes. Notification is in the form of a sponta- 240 neous Interface Reply. 242 Once the RSRR client has received the Initial Reply, it can begin 243 requesting routes by sending a Route Query for a source-destination 244 pair: 246 Route_Query(source, destination, notification). 248 The RSRR server responds by sending a Route Reply: 250 Route_Reply(source, destination, notification, incoming_vif, 251 outgoing_vif_bitmask, tree_type). 253 Multicast routes consist of an "incoming vif" and an "outgoing vif bit- 254 mask". Unicast routes consist of a single bit set in the "outgoing vif 255 bitmask" to indicate the next hop; the "incoming vif" is always zero and 256 should be ignored by the client. In addition, for unicast queries and 257 replies the "source" address is zero. 259 By setting the "notification" flag in the Route Query, the RSRR client 260 may ask the server to notify it when a route changes. A multicast route 261 change is a change in the "incoming vif" or "outgoing vif bitmask", i.e. 262 joins, prunes, link failures and link recoveries are all included. A 263 unicast route change is a change in the "outgoing vif bitmask". If the 264 server is able to provide this service, it sets a corresponding "notifi- 265 cation" flag in the Route Reply, otherwise it clears the flag. If the 266 client receives a Route Reply with the "notification" flag set, it can 267 assume that routing will notify it -- via a spontaneous Route Reply -- 268 when the route for the source-destination pair changes. In the mean- 269 time, the RSRR client can assume the route has not changed. If the RSRR 270 server can not support route change notification, then the client must 271 poll routing for forwarding table entries in order to learn of route 272 changes. 274 The "tree type" flag in the Route Reply is used only for multicast 275 routes. It has one of the following values: 277 o sender 279 o unidirectional shared 281 o hybrid unidirectional shared 283 o bidirectional shared 285 o hybrid bidirectional shared 287 The tree type indicates how forwarding occurs on the tree and thus how 288 to interpret the route contained in the Route Reply. The "sender" value 289 indicates that a separate multicast tree is constructed for each sender. 290 Typically this is a shortest-path tree, but it may also be built using 291 QoS routing, alternate paths, or other methods. In this case, packets 292 must arrive via the "incoming vif" and are then sent on all of the vifs 293 listed in the "outgoing vif bitmask". A " unidirectional shared" tree 294 is constructed for the entire group, but data flows in only one direc- 295 tion -- from the root of the tree down to all group members. The for- 296 warding model for the "unidirectional shared" tree is the same as for a 297 sender tree; the difference is that senders transmit data to the root of 298 the tree along separate branches. At routers where these branches are 299 located, a Route Reply with the "sender" tree type will be returned. A 300 "bidirectional shared" tree allows data to be sent by any group member. 301 An incoming packet may arrive on any interface, and it is sent on all 302 remaining vifs listed in the "outgoing vif bitmask". For this tree 303 type, the " incoming vif" is set to zero and should be ignored. 305 Hybrid multicast trees are those where some senders use a shared tree 306 and others use a sender tree. If the tree type is set to one of the 307 hybrid types, this indicates that the sender listed in the Route Reply 308 is using the shared tree given by the route. Senders that are using a 309 sender tree will have a "sender" tree type. Note that for hybrid trees 310 the RSRR client must issue queries for each sender in case that sender 311 is using a separate tree. This is in contrast to the case where all 312 senders use a shared tree, in which case the RSRR client does not need 313 to issue separate Route Queries for each of them. 315 Hybrid trees have the further consequence that senders can change tree 316 types over time. Changes of this sort are handled by route change noti- 317 fication. For example, if a sender on a hybrid shared tree later 318 switches to a sender-based tree, the RSRR server will send an updated 319 Route Reply with a new route and a new tree type. Likewise, if all 320 senders are using a shared tree, but later one switches to a shortest- 321 path tree, the RSRR server will send two Route Replies -- one for the 322 shared tree that changes the tree type to hybrid, and one for the sender 323 that is now using a sender tree. 325 4. Implementing RSRR within RSVP 327 A typical RSVP implementation could use the RSRR abstraction to build 328 a routing support module that handles interface configuration and 329 routing queries for IPv4 and IPv6 unicast and multicast routing 330 information. Figure 3 shows how the routing support module would 331 interact with RSVP and other router components. The module has three 332 interfaces, all of which are modeled on the RSRR abstract service 333 interface. First, RSVP's core processing routines request interface 334 configuration and forwarding table entries from the routing support 335 module. The module then collects this information from several 336 sources. It uses operating system calls when the kernel is able to 337 provide the required information. Otherwise, it uses the RSRR Proto- 338 col to collect this information from a routing protocol daemon. 339 Appendix A specifies the RSRR protocol for interprocess communica- 340 tion. For example, ISI's current implementation gets unicast inter- 341 faces and routes from the kernel, while it gets multicast interfaces 342 and routes using the RSRR protocol. 344 RSVP Daemon 345 ___________ 346 | Core RSVP | 347 | Processing| 348 | Routines | 349 |-----------| 350 | ^ Routing Support Routing Daemon 351 | | Interface (IPv4/IPv6 Unicast/Multicast) 352 | v | ___________________________ 353 | --------- | RSRR | ______ | | 354 | |Routing|<---------->|| | | Core | 355 | |Support| | Protocol || RSRR |<-->| Routing | 356 | |Module | | || Task | | Routines | 357 | |_______| | ||______| | | 358 |___________| |____________|_____________| 359 ^ ^ 360 | Operating System Calls | 361 | | 362 v v 363 ======================================================= 364 Kernel 366 Figure 3: RSVP Routing Support Module 368 5. Conclusion 370 Using RSRR version 2 and the routing support module has made it eas- 371 ier to upgrade RSVP to include IPv6 support by packaging interface 372 configuration and route acquisition for IPv4 and IPv6 unicast and 373 multicast routing into one module. 375 The impact of RSRR on a routing daemon is low. The daemon only has 376 to handle RSRR protocol queries when an RSVP session is created and 377 when a route for an RSVP session changes. The daemon incurs very lit- 378 tle cost for providing route change notification; essentially it only 379 has to tag the subset of its routes for which RSVP is interested in 380 receiving notification. This amounts to keeping an extra bit for 381 each routing entry. Furthermore, the RSRR services can be provided 382 independently by each router, so its implementation is not subject to 383 any interoperability constraints. 385 6. Acknowledgments 387 We would like to thank Bob Braden, Deborah Estrin, Bill Fenner, Scott 388 Shenker, and Lixia Zhang for their help with this work. 390 References 392 [1] A. J. Ballardie, P.F. Francis, and J. Crowcroft, "Core Based Trees", 393 In "ACM SIGCOMM", August 1993. 395 [2] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, "Resource 396 ReSerVation Protocol (RSVP) - Version 1 Functional Specification", 397 work in progress, March 1997. 399 [3] Stephen Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, 400 Ching-Gung Liu, and Liming Wei, "An Architecture for Wide-Area Mul- 401 ticast Routing", In "ACM SIGCOMM", August 1994. 403 [4] Daniel Zappala, "RSVP Loop Prevention for Wildcard Reservations", 404 Work in Progress, February 1996. 406 [5] Lixia Zhang, Steve Deering, Deborah Estrin, Scott Shenker, and 407 Daniel Zappala, "RSVP: A New Resource ReSerVation Protocol", "IEEE 408 Network", September 1993. 410 Appendices 412 A. RSRR Protocol Specification 414 This section details the RSRR version 2 messages format to be 415 exchanged between RSVP and a routing protocol. 417 RSVP would like to use version 2 of RSRR to communicate with routing 418 protocols, but fall back to version 1 if routing does not support 419 version 2. One way to do this would be to issue an Interface Query 420 for version 2 and wait to see if routing responds. If routing is 421 using version 1 this message will be dropped and, after a timeout, 422 RSVP could send a version 1 query. 424 However, to avoid this delay, we have included a mechanism in RSRR 425 for backwards compatibility. RSVP issues an Interface Query using 426 version 1, but sets the Num field to the maximum version of RSRR that 427 RSVP supports. The routing protocol, if it supports only version 1, 428 will ignore this field and respond with an Interface Reply for ver- 429 sion 1. A routing protocol supporting version 2 and higher should 430 examine this field and respond using a version equal to the minimum 431 of Num and the maximum supported version of RSRR. This mechanism 432 allows RSVP and routing to communicate using the maximum version of 433 RSRR that they both support. Note that routing protocols implement- 434 ing version 2 or higher should also be able to support queries for 435 lower versions of RSRR. For reference, the version 1 RSRR specifica- 436 tion is listed in Appendix A. 438 A.1 RSRR message format 440 An RSRR message consists of: 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Version | Type | Flags | Num | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 |... | 446 | | 448 Version 449 Routing Support for Resource Reservations Version. This 450 document specifies version 2 of RSRR. 452 Type 453 This document defines four message codes for RSRR: 455 1 = Interface Query 456 2 = Interface Reply 457 3 = Route Query 458 4 = Route Reply 460 The rest of the message is defined separately for each RSRR code. 462 A.2 Interface Query 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Version | Type | Flags | Num | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Version 469 1 For compatibility reasons. 471 Type 472 1 = Interface Query 474 Flags 475 A bit vector that specifies what RSVP requests, currently 476 only Notification bit is defined. 478 +-+-+-+-+-+-+-+-+ 479 | |N| 480 +-+-+-+-+-+-+-+-+ 482 N = 1 if RSVP requests notification of interfaces changes 484 Num 485 Maximum supported RSRR version 487 A.3 Interface Reply 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Version | Type | Flags | Num | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Vif ID-1 |Vif Threshold-1| Prefix | Vif Status-1 | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Address Family | Address Length | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Vif Local Address-1 | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 |... | 499 | | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Vif ID-N |Vif Threshold-N| Prefix | Vif Status-N | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Address Family | Address Length | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Vif Local Address-N | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Version 509 2 511 Type 512 2 = Interface Reply 514 Flags 515 1 = Error occurred during initial query, 0 otherwise 517 Num 518 Number of vifs being reported 520 Vif ID-N 521 ID for the Nth vif 523 Vif Threshold-N 524 The threshold ttl for the vif; an outgoing message must have a 525 ttl greater than the threshold to be sent 527 Prefix 528 The CIDR prefix for the address 530 Vif Status-N 531 A bit vector representing the vif status: 533 +-+-+-+-+-+-+-+-+ 534 | |N|P|U|M| 535 +-+-+-+-+-+-+-+-+ 537 N = 1 if notification will be made in case of vif changes. 538 P = 1 if vif is physical interface, 0 if it is virtual. 539 U = 1 if vif is unicast-disabled, 0 if it is enabled. 540 M = 1 if vif is multicast-disabled, 0 if it is enabled. 542 The rest of the field is transmitted as zeroes. 544 Address Family 545 The address family of the following address. 547 Address Length 548 The length of the following address in octets. 550 Vif Local Address-N 551 The local address of the physical interface corresponding to the 552 vif 554 A.4 Route Query 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Version | Type | Flags | Num | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Address Family | Address Length | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Destination Address | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Source Address | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Query Identifier | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 Version 569 2 571 Type 572 3 = Route Query 574 Flags 575 Currently only the Notification Bit is defined: 577 +-+-+-+-+-+-+-+-+ 578 | |N| 579 +-+-+-+-+-+-+-+-+ 581 N = 1 if RSVP requests route change notification for this query, 582 0 otherwise. 584 The rest of the field is transmitted as zeroes. 586 Num 587 0 589 Address Family 590 The address family of the following address. 592 Address Length 593 The length of the following address in octets. 595 Destination Address 596 Destination address being queried (unicast or multicast) 598 Source Address 599 Source address being queried (null for unicast) 601 Query Identifier 602 Identifier used by reservation protocol 604 A.5 Route Reply 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Version | Type | Flags | Num | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Address Family | Address Length | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Destination Address | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Source Address | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Query Identifier | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Incoming Vif | Tree Type | Reserved | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | | 620 + + 621 | | 622 + + 623 | | 624 + + 625 | Outgoing Vif Bitmask | 626 + + 627 | | 628 + + 629 | | 630 + + 631 | | 632 + + 633 | | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 Version 637 2 639 Type 640 4 = Route Reply 642 Flags 643 The currently defined flags are: 645 +-+-+-+-+-+-+-+-+ 646 | |E|N| 647 +-+-+-+-+-+-+-+-+ 649 N is set if N is set in the corresponding route query and the 650 router can perform route change notification for the query. 651 Otherwise N is cleared. 653 E is set if routing is unable to obtain routing information for 654 the route query. Otherwise E is cleared. 656 The rest of the field is transmitted as zeroes. 658 Address Family 659 The address family of the following address. 661 Address Length 662 The length of the following address in octets. 664 Destination Address 665 destination address of query = destination address of reply 667 Source Address 668 source address of query = source address of reply (null if unicast) 670 Query Identifier 671 identifier used by reservation protocol, copied from query message 673 Incoming Vif 674 incoming Vif for (S,G) or default (S,*) if no group-specific 675 state; invalid if E bit is set 677 Tree Type 678 the currently defined values are: 680 0 sender tree 681 1 unidirectional shared tree 682 2 hybrid unidirectional shared tree 683 3 bidirectional shared tree 684 4 hybrid bidirectional shared tree 686 Reserved 687 transmitted as 0 689 Outgoing Vif Bitmask 690 bitmask of outgoing Vifs for (S,G) or default (S,*) if no 691 group-specific state; invalid if E bit is set; RSVP 692 should handle entire bitmask size or otherwise warn 693 user that some routing information may be lost 695 B. RSRR V1 Protocol Specification 696 B.1 RSRR V1 Message Format 698 An RSRR v1 message consists of: 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Version | Type | Flags | Num | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 |... | 704 | | 706 Version 707 Routing Support for Resource Reservations Version. This 708 appendix specifies version 1 of RSRR. 710 Type 711 This appendix defines four message codes for RSRR: 713 1 = Initial Query 714 2 = Initial Reply 715 3 = Route Query 716 4 = Route Reply 718 The rest of the message is defined separately for each RSRR code. 720 B.2 Initial Query 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Version | Type | Flags | Num | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 Version as defined above. 728 Type 729 1 = Initial Query 731 Flags, Num 732 0 734 B.3 Initial Reply 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Version | Type | Flags | Num | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Vif ID-1 |Vif Threshold-1| Vif Status-1 | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Vif Local Address-1 | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 |... | 744 | | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Vif ID-N |Vif Threshold-N| Vif Status-N | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Vif Local Address-N | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 Version as defined above. 753 Type 754 2 = Initial Reply 756 Flags 757 0 759 Num 760 Number of vifs being reported 762 Vif ID-N 763 ID for the Nth vif 765 Vif Threshold-N 766 The threshold ttl for the vif; an outgoing message must have a 767 ttl greater than the threshold to be sent 769 Vif Status-N 770 A bit vector representing the vif status. Currently only 771 the Disabled bit is defined: 773 +-+-+-+-+-+-+-+-+ 774 | |D| 775 +-+-+-+-+-+-+-+-+ 777 D = 1 if vif is administratively disabled, 0 otherwise. 779 The rest of the field is transmitted as zeroes. 781 Vif Local Address-N 782 The local address of the physical interface corresponding to the 783 vif 785 B.4 Route Query 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Version | Type | Flags | Num | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Destination Address | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Source Address | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Query Identifier | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 Version as defined above 799 Type 800 3 = Route Query 802 Flags 803 Currently only the Notification Bit is defined: 805 +-+-+-+-+-+-+-+-+ 806 | |N| 807 +-+-+-+-+-+-+-+-+ 809 N = 1 if RSVP requests route change notification for this query, 810 0 otherwise. 812 The rest of the field is transmitted as zeroes. 814 Num 815 0 817 Destination Address 818 Group address being queried 820 Source Address 821 Source address being queried 823 Query Identifier 824 Identifier used by reservation protocol 826 B.5 Route Reply 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Version | Type | Flags | Num | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Destination Address | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Source Address | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Query Identifier | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Incoming Vif | Reserved | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Outgoing Vif Bitmask | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 Version as defined above. 844 Type 845 4 = Route Reply 847 Flags 848 The currently defined flags are: 850 +-+-+-+-+-+-+-+-+ 851 | | S |E|N| 852 +-+-+-+-+-+-+-+-+ 854 N is set if N is set in the corresponding route query and the 855 router can perform route change notification for the query. 856 Otherwise N is cleared. 858 E is set if routing is unable to obtain routing information for 859 the route query. Otherwise E is cleared. 861 S has the binary value 01 if the listed sender is using a shared 862 tree, but some other senders for the same destination use sender 863 trees. S has the binary value 10 if all senders for the 864 destination use shared trees. Otherwise, S has the value 00. 866 The rest of the field is transmitted as zeroes. 868 Destination Address 869 group address of query = group address of reply 871 Source Address 872 source address of query = source address of reply 874 Query Identifier 875 identifier used by reservation protocol, copied from query message 877 Incoming Vif 878 incoming Vif for (S,G) or default (S,*) if no group-specific 879 state; invalid if E bit is set 881 Reserved 882 transmitted as 0 884 Outgoing Vif Bitmask 885 bitmask of outgoing Vifs for (S,G) or default (S,*) if no 886 group-specific state; invalid if E bit is set 888 C. Implementations 890 Code supporting RSRR that has been and is being developed includes: 892 o ISI's RSVP version 4.2 and Xerox PARC's distribution of 893 DVMRP/mrouted version 3.8 support RSRR version 1, minus support for 894 shared trees 896 o ISI plans to release a future version of RSVP with support for RSRR 897 version 2, 899 o UO plans to add support for RSRR version 2 to Merit's GateD multi- 900 cast version 5, specifically testing shared tree support with IPv4 901 PIM sparse mode. This code should be general enough to support 902 other multicast protocols implemented within GateD. 904 Security Considerations 906 Security considerations are not discussed in this memo. 908 Authors' Addresses 910 Daniel Zappala 911 Department of Computer and Information Science 912 University of Oregon 913 Eugene, OR 97403 914 EMail: zappala@cs.uoregon.edu 916 Jeff Kann 917 USC Information Sciences Institute 918 4676 Admiralty Way 919 Marina del Rey, CA 90292 920 EMail: kann@isi.edu