Internet Draft Daniel Zappala Expiration: January 1999 University of Oregon File: draft-ietf-rsvp-routing-02.txt Jeff Kann USC/ISI RSRR: A Routing Interface For RSVP 1 July 1998 Status of Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo describes version 2 of RSRR, a routing interface for RSVP. By using this interface, RSVP may obtain forwarding information from routers and use it to place reservation state within the network. Version 1 of this interface was designed primarily for RSVP interaction with IPv4 multicast routing protocols. Version 2 adds support for IPv4 unicast as well as IPv6 unicast and multicast routing. A backwards compatibility mechanism is provided. Zappala, Kann Expiration: January 1999 [Page 1] Internet Draft RSRR June 1998 1. Introduction This document describes Routing Support for Resource Reservations (RSRR), an abstract interface by which RSVP [5] may obtain routing information. RSVP is a resource reservation protocol used by hosts to request Quality of Service from the network. RSVP does not include a routing protocol; instead it may use any underlying routing protocol(s) to determine where it should carry resource reservations. The RSRR interface provides RSVP with forwarding table entries and notifies it when those entries change. This document elaborates on the routing support described in the RSVP spec [2]. This document describes version 2 of RSRR. In addition to IPv4 multicast routing protocols, which were covered extensively in the version 1 document, version 2 explicitly addresses IPv4 unicast routing and adds support for IPv6 unicast and multicast routing. Version 2, like version 1, also provides RSVP with information on the interfaces known to RSRR. Finally, version 2 includes a backwards- compatibility mechanism that allows RSVP to determine the version of RSRR that a routing daemon is using. Section 2 gives an overview of RSVP functionality and its requirements for routing and kernel support. Section 3 describes RSRR as an abstract service interface. Section 4 describes how this interface might typically be implemented within RSVP. Appendix A gives a specification of RSRR used for communication between RSVP and routing daemons. Appendix B lists the RSRR version 1 specification, which version 2 implementations must also support. This is included for reference, since some implementations may support multiple versions. Appendix C lists the implementation status of RSRR. 2. RSVP Overview and RSRR Motivation Using RSVP, sources send "Path" messages hop-by-hop to the destination (Figure 1a). Each router uses the "Path" message to create reverse-path routing state and forwards the message toward the destination. Receivers send "Resv" messages toward sources, following the reverse-path routing state (Figure 1b). Each router uses the "Resv" message to query admission control to accept or reject the embedded reservation request. Reservation messages utilize various "styles" to allow sharing among different senders. For example, the shared-explicit style targets a reservation at a list of senders, and the wildcard style targets a reservation at all upstream senders (Figure 1c). Zappala, Kann Expiration: January 1999 [Page 2] Internet Draft RSRR June 1998 Sender Sender S2 S1 S3 - - - - - | | | | | | | | | | - P - R - - - | P | R R \ / R / R - P - R R - R - R | | | | | | | | P - P R - R - - P / \ P R / \ R R \ / R P / - R / - R - R P / | | R / | | | | P / P - P R / R - R - R P / P / \ P R / R / \ R | R - - - - - - - R | | | | | | | | | | | | | | - - - - - - - R1 R2 R3 R1 R2 R3 Receiver (a) PATH message (b) RESV message merged (c) RESV message branches multicasted as it follows path as it travels toward downstream state upstream multiple senders Figure 1: RSVP Overview With proper operating system support, a router could pull an RSVP " Path" message out of the forwarding engine, do RSVP processing, and then resume forwarding the message. However, multicast "Path" messages have unique requirements. After RSVP performs its processing, it may need to send a different copy of the "Path" message out each outgoing interface. Normally, IP multicast replicates datagrams and sends identical copies out each of the outgoing interfaces. Thus, RSVP does not use regular IP multicast forwarding and instead needs to replicate the "Path" messages on its own and simulate its own multicast forwarding. To accomplish this objective, RSVP needs to obtain forwarding table entries from the routing protocol; this is what the RSRR interface is for. In addition, the operating system must support several basic functions for RSVP. First, RSVP needs to know which interface a "Path" message arrives on. This allows RSVP to suppress forwarding of multicast packets that routing has determined have arrived via the wrong incoming interface. It also needs to receive all multicast "Path" messages, even if they arrive on the wrong interface; this allows RSVP processing to occur for local receivers. Second, RSVP must be allowed to insert the original source address of the "Path" message in its IP header This allows the "Path" message to be Zappala, Kann Expiration: January 1999 [Page 3] Internet Draft RSRR June 1998 processed by downstream routers as if it came from the original source. Finally, when RSVP sends a multicast packet, it expects that it can tell the operating system to forward the packet directly over a particular interface, without performing any of the usual multicast routing checks and without looping the packet back to other interfaces. These operating system functions, combined with RSRR, allow RSVP to forward distinct packets hop-by-hop over each link in a multicast path between a source and destination(s). When obtaining forwarding table entries from RSRR, RSVP also needs to know whether the multicast routing protocol is using sender-rooted (e.g shortest-path) trees or shared trees (e.g. with the PIM [3] or CBT [1] multicast routing protocols). For shared trees, RSVP only needs to obtain and store one route for all senders to the group. In addition, RSVP must mimic the IP multicast forwarding model. This means that for bidirectional shared trees, a packet can be accepted over any interface and is forwarded over all other interfaces listed in the route. When running over shared trees, RSVP can also significantly decrease the size of the "scope" object in wildcard filter "Resv" messages. RSVP uses a "scope" object, listing all upstream senders, to prevent looping of wildcard filter "Resv" messages [4] (Figure 2a). For shared trees, RSVP can use a " scope" object that includes a wildcard address, greatly reducing the size of the "Resv" message. A "Resv" message with a wildcard address would follow shared tree state but never sender tree state (Figure 2b). Zappala, Kann Expiration: January 1999 [Page 4] Internet Draft RSRR June 1998 S1 S2 S3 S1 S2 S3 - - - - - - | | | | | | | | | | | | - - - - - - R \ / R / R R \ / R / R R[1] - R[2] - R[3] R[*] - R[*] - R[3] | | | | | | | | - - - - R \ / R R \ / R R[1,2] - R[3] R[*] - R[3] | | | | - R - R | R[1,2,3] | R[*,3] - R - R | | | | - - Receiver Receiver (a) wildcard RESV message (b) wildcard RESV message with carrying scope objects senders #1,2 on a shared tree Figure 2: The "Scope" Object in Wildcard Reservations 3. Abstract Service Interface We describe RSRR as an abstract service interface because it may be realized in several different ways. For example, some implementations may use system calls if the operating system can supply the functionality of RSRR. In a typical implementation, RSVP might use the RSRR abstraction as the basis of an interface to a routing support module (see Section 4), in addition to using the RSRR protocol (see Appendix A) to communicate with multicast routing protocol daemons. To achieve this generality, the following interface description uses the term "RSRR client" to indicate the entity requesting routes and the term "RSRR server" to indicate the responding entity. The client is typically the RSVP daemon and the server is typically a routing protocol daemon or the operating system. The first thing an RSRR client must do is determine the set of network interfaces the RSRR server is using. This allows the client to make sense of the routes it acquires from the server. RSRR represents network interfaces -- which may be physical interfaces, tunnels, or any other operating system mechanism -- as "virtual Zappala, Kann Expiration: January 1999 [Page 5] Internet Draft RSRR June 1998 interfaces" or "vifs". A vif has the following attributes: id a unique identifier, threshold a TTL threshold, prefix a CIDR prefix, status a bitmask status vector, family the address family, length the address length, and local_addr a local address. This information represents what the RSRR client (e.g. RSVP) needs to simulate IP multicast forwarding. IP multicast uses the "TTL threshold" to control the scope of packets, checking it on a per-packet basis. A newer form of administrative scoping is enforced on a per-route basis, so it is reflected in the routes themselves and is thus transparent to the RSRR client. The server may also define a "status" vector for any other information it needs to pass to the client. The RSRR client obtains the set of network interfaces by issuing an Interface Query of the form: Interface_Query(). The server responds with an Interface Reply that includes the number of vifs and a list of the vifs with their attributes as defined above: Interface_Reply(num, vif_list). The RSRR server automatically notifies the client if the set of inter- faces or their status changes. Notification is in the form of a sponta- neous Interface Reply. Once the RSRR client has received the Initial Reply, it can begin requesting routes by sending a Route Query for a source-destination pair: Route_Query(source, destination, notification). The RSRR server responds by sending a Route Reply: Zappala, Kann Expiration: January 1999 [Page 6] Internet Draft RSRR June 1998 Route_Reply(source, destination, notification, incoming_vif, outgoing_vif_bitmask, tree_type). Multicast routes consist of an "incoming vif" and an "outgoing vif bit- mask". Unicast routes consist of a single bit set in the "outgoing vif bitmask" to indicate the next hop; the "incoming vif" is always zero and should be ignored by the client. In addition, for unicast queries and replies the "source" address is zero. By setting the "notification" flag in the Route Query, the RSRR client may ask the server to notify it when a route changes. A multicast route change is a change in the "incoming vif" or "outgoing vif bitmask", i.e. joins, prunes, link failures and link recoveries are all included. A unicast route change is a change in the "outgoing vif bitmask". If the server is able to provide this service, it sets a corresponding "notifi- cation" flag in the Route Reply, otherwise it clears the flag. If the client receives a Route Reply with the "notification" flag set, it can assume that routing will notify it -- via a spontaneous Route Reply -- when the route for the source-destination pair changes. In the mean- time, the RSRR client can assume the route has not changed. If the RSRR server can not support route change notification, then the client must poll routing for forwarding table entries in order to learn of route changes. The "tree type" flag in the Route Reply is used only for multicast routes. It has one of the following values: o sender o unidirectional shared o hybrid unidirectional shared o bidirectional shared o hybrid bidirectional shared The tree type indicates how forwarding occurs on the tree and thus how to interpret the route contained in the Route Reply. The "sender" value indicates that a separate multicast tree is constructed for each sender. Typically this is a shortest-path tree, but it may also be built using QoS routing, alternate paths, or other methods. In this case, packets must arrive via the "incoming vif" and are then sent on all of the vifs listed in the "outgoing vif bitmask". A " unidirectional shared" tree is constructed for the entire group, but data flows in only one direc- tion -- from the root of the tree down to all group members. The for- warding model for the "unidirectional shared" tree is the same as for a sender tree; the difference is that senders transmit data to the root of Zappala, Kann Expiration: January 1999 [Page 7] Internet Draft RSRR June 1998 the tree along separate branches. At routers where these branches are located, a Route Reply with the "sender" tree type will be returned. A "bidirectional shared" tree allows data to be sent by any group member. An incoming packet may arrive on any interface, and it is sent on all remaining vifs listed in the "outgoing vif bitmask". For this tree type, the " incoming vif" is set to zero and should be ignored. Hybrid multicast trees are those where some senders use a shared tree and others use a sender tree. If the tree type is set to one of the hybrid types, this indicates that the sender listed in the Route Reply is using the shared tree given by the route. Senders that are using a sender tree will have a "sender" tree type. Note that for hybrid trees the RSRR client must issue queries for each sender in case that sender is using a separate tree. This is in contrast to the case where all senders use a shared tree, in which case the RSRR client does not need to issue separate Route Queries for each of them. Hybrid trees have the further consequence that senders can change tree types over time. Changes of this sort are handled by route change noti- fication. For example, if a sender on a hybrid shared tree later switches to a sender-based tree, the RSRR server will send an updated Route Reply with a new route and a new tree type. Likewise, if all senders are using a shared tree, but later one switches to a shortest- path tree, the RSRR server will send two Route Replies -- one for the shared tree that changes the tree type to hybrid, and one for the sender that is now using a sender tree. 4. Implementing RSRR within RSVP A typical RSVP implementation could use the RSRR abstraction to build a routing support module that handles interface configuration and routing queries for IPv4 and IPv6 unicast and multicast routing information. Figure 3 shows how the routing support module would interact with RSVP and other router components. The module has three interfaces, all of which are modeled on the RSRR abstract service interface. First, RSVP's core processing routines request interface configuration and forwarding table entries from the routing support module. The module then collects this information from several sources. It uses operating system calls when the kernel is able to provide the required information. Otherwise, it uses the RSRR Proto- col to collect this information from a routing protocol daemon. Appendix A specifies the RSRR protocol for interprocess communica- tion. For example, ISI's current implementation gets unicast inter- faces and routes from the kernel, while it gets multicast interfaces and routes using the RSRR protocol. Zappala, Kann Expiration: January 1999 [Page 8] Internet Draft RSRR June 1998 RSVP Daemon ___________ | Core RSVP | | Processing| | Routines | |-----------| | ^ Routing Support Routing Daemon | | Interface (IPv4/IPv6 Unicast/Multicast) | v | ___________________________ | --------- | RSRR | ______ | | | |Routing|<---------->|| | | Core | | |Support| | Protocol || RSRR |<-->| Routing | | |Module | | || Task | | Routines | | |_______| | ||______| | | |___________| |____________|_____________| ^ ^ | Operating System Calls | | | v v ======================================================= Kernel Figure 3: RSVP Routing Support Module 5. Conclusion Using RSRR version 2 and the routing support module has made it eas- ier to upgrade RSVP to include IPv6 support by packaging interface configuration and route acquisition for IPv4 and IPv6 unicast and multicast routing into one module. The impact of RSRR on a routing daemon is low. The daemon only has to handle RSRR protocol queries when an RSVP session is created and when a route for an RSVP session changes. The daemon incurs very lit- tle cost for providing route change notification; essentially it only has to tag the subset of its routes for which RSVP is interested in receiving notification. This amounts to keeping an extra bit for each routing entry. Furthermore, the RSRR services can be provided independently by each router, so its implementation is not subject to any interoperability constraints. 6. Acknowledgments We would like to thank Bob Braden, Deborah Estrin, Bill Fenner, Scott Shenker, and Lixia Zhang for their help with this work. Zappala, Kann Expiration: January 1999 [Page 9] Internet Draft RSRR June 1998 References [1] A. J. Ballardie, P.F. Francis, and J. Crowcroft, "Core Based Trees", In "ACM SIGCOMM", August 1993. [2] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", work in progress, March 1997. [3] Stephen Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ching-Gung Liu, and Liming Wei, "An Architecture for Wide-Area Mul- ticast Routing", In "ACM SIGCOMM", August 1994. [4] Daniel Zappala, "RSVP Loop Prevention for Wildcard Reservations", Work in Progress, February 1996. [5] Lixia Zhang, Steve Deering, Deborah Estrin, Scott Shenker, and Daniel Zappala, "RSVP: A New Resource ReSerVation Protocol", "IEEE Network", September 1993. Zappala, Kann Expiration: January 1999 [Page 10] Internet Draft RSRR June 1998 Appendices A. RSRR Protocol Specification This section details the RSRR version 2 messages format to be exchanged between RSVP and a routing protocol. RSVP would like to use version 2 of RSRR to communicate with routing protocols, but fall back to version 1 if routing does not support version 2. One way to do this would be to issue an Interface Query for version 2 and wait to see if routing responds. If routing is using version 1 this message will be dropped and, after a timeout, RSVP could send a version 1 query. However, to avoid this delay, we have included a mechanism in RSRR for backwards compatibility. RSVP issues an Interface Query using version 1, but sets the Num field to the maximum version of RSRR that RSVP supports. The routing protocol, if it supports only version 1, will ignore this field and respond with an Interface Reply for ver- sion 1. A routing protocol supporting version 2 and higher should examine this field and respond using a version equal to the minimum of Num and the maximum supported version of RSRR. This mechanism allows RSVP and routing to communicate using the maximum version of RSRR that they both support. Note that routing protocols implement- ing version 2 or higher should also be able to support queries for lower versions of RSRR. For reference, the version 1 RSRR specifica- tion is listed in Appendix A. A.1 RSRR message format An RSRR message consists of: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Flags | Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |... | | | Version Routing Support for Resource Reservations Version. This document specifies version 2 of RSRR. Type This document defines four message codes for RSRR: 1 = Interface Query 2 = Interface Reply Zappala, Kann Expiration: January 1999 [Page 11] Internet Draft RSRR June 1998 3 = Route Query 4 = Route Reply The rest of the message is defined separately for each RSRR code. A.2 Interface Query +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Flags | Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version 1 For compatibility reasons. Type 1 = Interface Query Flags A bit vector that specifies what RSVP requests, currently only Notification bit is defined. +-+-+-+-+-+-+-+-+ | |N| +-+-+-+-+-+-+-+-+ N = 1 if RSVP requests notification of interfaces changes Num Maximum supported RSRR version Zappala, Kann Expiration: January 1999 [Page 12] Internet Draft RSRR June 1998 A.3 Interface Reply +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Flags | Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vif ID-1 |Vif Threshold-1| Prefix | Vif Status-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Address Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vif Local Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vif ID-N |Vif Threshold-N| Prefix | Vif Status-N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Address Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vif Local Address-N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version 2 Type 2 = Interface Reply Flags 1 = Error occurred during initial query, 0 otherwise Num Number of vifs being reported Vif ID-N ID for the Nth vif Vif Threshold-N The threshold ttl for the vif; an outgoing message must have a ttl greater than the threshold to be sent Prefix The CIDR prefix for the address Vif Status-N A bit vector representing the vif status: +-+-+-+-+-+-+-+-+ | |N|P|U|M| Zappala, Kann Expiration: January 1999 [Page 13] Internet Draft RSRR June 1998 +-+-+-+-+-+-+-+-+ N = 1 if notification will be made in case of vif changes. P = 1 if vif is physical interface, 0 if it is virtual. U = 1 if vif is unicast-disabled, 0 if it is enabled. M = 1 if vif is multicast-disabled, 0 if it is enabled. The rest of the field is transmitted as zeroes. Address Family The address family of the following address. Address Length The length of the following address in octets. Vif Local Address-N The local address of the physical interface corresponding to the vif A.4 Route Query +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Flags | Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Address Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version 2 Type 3 = Route Query Flags Currently only the Notification Bit is defined: +-+-+-+-+-+-+-+-+ | |N| +-+-+-+-+-+-+-+-+ N = 1 if RSVP requests route change notification for this query, Zappala, Kann Expiration: January 1999 [Page 14] Internet Draft RSRR June 1998 0 otherwise. The rest of the field is transmitted as zeroes. Num 0 Address Family The address family of the following address. Address Length The length of the following address in octets. Destination Address Destination address being queried (unicast or multicast) Source Address Source address being queried (null for unicast) Query Identifier Identifier used by reservation protocol Zappala, Kann Expiration: January 1999 [Page 15] Internet Draft RSRR June 1998 A.5 Route Reply +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Flags | Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Address Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Incoming Vif | Tree Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | | + + | Outgoing Vif Bitmask | + + | | + + | | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version 2 Type 4 = Route Reply Flags The currently defined flags are: +-+-+-+-+-+-+-+-+ | |E|N| +-+-+-+-+-+-+-+-+ N is set if N is set in the corresponding route query and the router can perform route change notification for the query. Otherwise N is cleared. Zappala, Kann Expiration: January 1999 [Page 16] Internet Draft RSRR June 1998 E is set if routing is unable to obtain routing information for the route query. Otherwise E is cleared. The rest of the field is transmitted as zeroes. Address Family The address family of the following address. Address Length The length of the following address in octets. Destination Address destination address of query = destination address of reply Source Address source address of query = source address of reply (null if unicast) Query Identifier identifier used by reservation protocol, copied from query message Incoming Vif incoming Vif for (S,G) or default (S,*) if no group-specific state; invalid if E bit is set Tree Type the currently defined values are: 0 sender tree 1 unidirectional shared tree 2 hybrid unidirectional shared tree 3 bidirectional shared tree 4 hybrid bidirectional shared tree Reserved transmitted as 0 Outgoing Vif Bitmask bitmask of outgoing Vifs for (S,G) or default (S,*) if no group-specific state; invalid if E bit is set; RSVP should handle entire bitmask size or otherwise warn user that some routing information may be lost B. RSRR V1 Protocol Specification Zappala, Kann Expiration: January 1999 [Page 17] Internet Draft RSRR June 1998 B.1 RSRR V1 Message Format An RSRR v1 message consists of: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Flags | Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |... | | | Version Routing Support for Resource Reservations Version. This appendix specifies version 1 of RSRR. Type This appendix defines four message codes for RSRR: 1 = Initial Query 2 = Initial Reply 3 = Route Query 4 = Route Reply The rest of the message is defined separately for each RSRR code. B.2 Initial Query +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Flags | Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version as defined above. Type 1 = Initial Query Flags, Num 0 Zappala, Kann Expiration: January 1999 [Page 18] Internet Draft RSRR June 1998 B.3 Initial Reply +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Flags | Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vif ID-1 |Vif Threshold-1| Vif Status-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vif Local Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vif ID-N |Vif Threshold-N| Vif Status-N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vif Local Address-N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version as defined above. Type 2 = Initial Reply Flags 0 Num Number of vifs being reported Vif ID-N ID for the Nth vif Vif Threshold-N The threshold ttl for the vif; an outgoing message must have a ttl greater than the threshold to be sent Vif Status-N A bit vector representing the vif status. Currently only the Disabled bit is defined: +-+-+-+-+-+-+-+-+ | |D| +-+-+-+-+-+-+-+-+ D = 1 if vif is administratively disabled, 0 otherwise. The rest of the field is transmitted as zeroes. Vif Local Address-N Zappala, Kann Expiration: January 1999 [Page 19] Internet Draft RSRR June 1998 The local address of the physical interface corresponding to the vif B.4 Route Query +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Flags | Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version as defined above Type 3 = Route Query Flags Currently only the Notification Bit is defined: +-+-+-+-+-+-+-+-+ | |N| +-+-+-+-+-+-+-+-+ N = 1 if RSVP requests route change notification for this query, 0 otherwise. The rest of the field is transmitted as zeroes. Num 0 Destination Address Group address being queried Source Address Source address being queried Query Identifier Identifier used by reservation protocol Zappala, Kann Expiration: January 1999 [Page 20] Internet Draft RSRR June 1998 B.5 Route Reply +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Flags | Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Incoming Vif | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outgoing Vif Bitmask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version as defined above. Type 4 = Route Reply Flags The currently defined flags are: +-+-+-+-+-+-+-+-+ | | S |E|N| +-+-+-+-+-+-+-+-+ N is set if N is set in the corresponding route query and the router can perform route change notification for the query. Otherwise N is cleared. E is set if routing is unable to obtain routing information for the route query. Otherwise E is cleared. S has the binary value 01 if the listed sender is using a shared tree, but some other senders for the same destination use sender trees. S has the binary value 10 if all senders for the destination use shared trees. Otherwise, S has the value 00. The rest of the field is transmitted as zeroes. Destination Address group address of query = group address of reply Source Address source address of query = source address of reply Zappala, Kann Expiration: January 1999 [Page 21] Internet Draft RSRR June 1998 Query Identifier identifier used by reservation protocol, copied from query message Incoming Vif incoming Vif for (S,G) or default (S,*) if no group-specific state; invalid if E bit is set Reserved transmitted as 0 Outgoing Vif Bitmask bitmask of outgoing Vifs for (S,G) or default (S,*) if no group-specific state; invalid if E bit is set C. Implementations Code supporting RSRR that has been and is being developed includes: o ISI's RSVP version 4.2 and Xerox PARC's distribution of DVMRP/mrouted version 3.8 support RSRR version 1, minus support for shared trees o ISI plans to release a future version of RSVP with support for RSRR version 2, o UO plans to add support for RSRR version 2 to Merit's GateD multi- cast version 5, specifically testing shared tree support with IPv4 PIM sparse mode. This code should be general enough to support other multicast protocols implemented within GateD. Security Considerations Security considerations are not discussed in this memo. Authors' Addresses Daniel Zappala Department of Computer and Information Science University of Oregon Eugene, OR 97403 EMail: zappala@cs.uoregon.edu Jeff Kann USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 EMail: kann@isi.edu Zappala, Kann Expiration: January 1999 [Page 22] Internet Draft RSRR June 1998 Zappala, Kann Expiration: January 1999 [Page 23]