INTERNET-DRAFT Lixia Zhang <draft-ietf-rsvp-diagnostic-msgs-04.txt> Andreas Terzis Expiration: February 1999 UCLA Subramaniam Vincent August 1998 RSVP Diagnostic Messages <draft-ietf-rsvp-diagnostic-msgs-04.txt> Status of this 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). Distribution of this memo is unlimited. This Internet Draft expires in February, 1999. Abstract This document specifies the RSVP diagnosis facility. As the deployment of RSVP is spreading out, it becomes clear that a method for collecting information about the RSVP state along the path is needed. This specification describes the functionality, diagnostic message formats, and processing rules. draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 1]
INTERNET-DRAFT February 1999 1. Introduction In the original design of the RSVP protocol, error messages are the only means for the end hosts to receive feedback information regarding a specific request that has failed, a failure in setting up either a PATH state or reservation state. In the absence of failures, one receives no feedback regarding the details of a reservation that has been put in place, such as whether, or where, or how, one's own reservation request is merged with that of others. In case of a failure, the error message carries back only the information from the failed point, without any information about the state at other hops before or after the failure. Such missing information, however, can be highly desirable for debugging purpose, or for network resource management in general. This document specifies RSVP diagnostic messages that allows one to collect information of RSVP state along the path from a receiver to a specific sender. Diagnostic messages are independent from any other RSVP control messages and produce no side-effects. That is, they do not change any RSVP state at either routers or hosts. Similarly, they do not represent an error report but a collection of RSVP state information as requested. We have the following design goals in mind: - To be able to collect RSVP state information at every hop along the path where the PATH state has been set up, either for an existing reservation or before a reservation request is made; here the "hop" means RSVP-capable routers. More specifically, we want to be able to collect information about flowspec, refresh timer values, and reservation merging at each hop along the path. - To be able to collect the routing hop count for each non-RSVP cloud. - To avoid diagnostic packet implosion or explosion. The following are specifically identified as non-goals: - Checking the resource availability along a path. Such functionality may be useful for future reservation requests, but would require modifications to existing admission control module which is beyond the scope of RSVP. draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 2]
INTERNET-DRAFT February 1999 2. Overview We define two types of RSVP diagnostic packets, diagnostic request (DREQ) and reply (DREP). This diagnostic tool can be invoked by a client from any host that may or may not be a participant of the RSVP session to be diagnosed. Thus generally speaking three nodes are involved in performing the diagnostic function: the requester, the starting and the ending nodes of the diagnosis, as shown in Figure 1. It is possible that the client invoking the diagnosis function may reside directly on the LAST-HOP, in which case that the first two nodes are the the same. The starting node of the diagnosis is named "LAST-HOP", meaning the last-hop of the path segment to be diagnosed, which can be either the receiving end or an intermediate router along a reserved path. The ending node is the sender host in general, although one can also limit the length of the path segment to be diagnosed by specifying a hop-count limit for the diagnosis messages. To avoid packet implosion or explosion, all diagnostic packets are forwarded via unicast only. A client invokes RSVP diagnostic functions by generating a DREQ packet and sending to the LAST-HOP node which should be on the RSVP path to be diagnosed. This DREQ packet specifies the RSVP session and a sender host to that session. The DREQ packet starts collecting information at the LAST-HOP node and proceeds toward the sender (see Figure 1). Receiver LAST-HOP Sender __ __ __ __ __ __ __ | |---------| |------>| |-->| |-->| |-->| |---->| | |__| |__| DREQ |__| |__| |__| |__| |__| ^ | RSVP routers | |request _|_ | | Requester |___| Figure 1 Each RSVP-capable router receiving the DREQ packet adds to the packet a response data object containing the router's RSVP state for the specified RSVP session, and then forwards the request via unicast to the router that it believes to be the previous hop for the given sender. Each subsequent RSVP router attaches its own response data draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 3]
INTERNET-DRAFT February 1999 object to the end of the DREQ packet, then forwards via unicast to the previous hop. When the DREQ packet reaches the sender, the sender changes the packet type to Diagnostic Reply (DREP) and sends the completed response to the original requester. Partial response may also be returned before the DREQ packet reaches the sender if any error condition along the path, such as "no path state", prevents further forwarding of the DREQ packet, or if the specified hop-count for the diagnosis has been reached. DREP packets can be unicast back to the requester either directly, or in a hop-by-hop manner by reversing the exact path that the DREQ packet has taken. The former is faster and more efficient, but the latter may be the only choice if the packets have to cross firewalls, due to the way that firewalls operate. To facilitate the latter case, a DREQ packet may optionally carry a ROUTE object, which is a list of router addresses that the DREQ packet has passed through on the way to the sender; this ROUTE object is built incrementally as the DREQ packet passes through the intermediate routers. The DREP packet can then be returned to the requester by reversing the path. When the path consists of many hops, it is possible that the total length of a DREP packet will exceed the path MTU size before reaching the sender, thus the packet has to be fragmented. Relying on IP fragmentation and reassembly, however, can be problematic, especially when DREP packets are returned to the requester hop-by-hop, in which case fragmentation/reassembly would have to be performed at every hop. To avoid such excessive overhead, we let the requester define a default path MTU size which is carried in every DREQ packet. If an intermediate router finds that the default MTU size is bigger than that of the outgoing link, it returns the DREQ packet with the corresponding error bit set. If an intermediate router detects that a DREQ packet size reaches the MTU size, it sends a partial DREP, consisting of the collected responses back, to the requester and then continues to forward the trimmed DREQ packet to the next hop towards the sender. Through out this document we use the word "DREQ packet", rather the word "message" to call a diagnostic request since it always consists of a single packet. On the other hand, one DREQ packet can generate multiple DREP packets, each containing a fragment of the total reply. Furthermore, when discussing diagnostic packet handling, the terminology used refers to the direction of data packet flow, thus "outgoing interface" of a router is the interface a DREQ packet comes from. THE DREQ then gets forwarded to an "incoming interface", because DREQ packets travel in the reverse direction of the data flow. draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 4]
INTERNET-DRAFT February 1999 Notice that one can forward DREQ packets only after the RSVP PATH state has been set up. If no PATH state exists, one may resort to the traceroute or mtrace facility to examine whether the unicast/multicast routing is working correctly. 3. Diagnostic Packet Format A diagnostic packet consists of the following parts: +-----------------------------------+ | RSVP common header | +-----------------------------------+ | Diagnostic packet header object | +-----------------------------------+ | session object | +-----------------------------------+ | (optional) SELECT object | +-----------------------------------+ | (optional) ROUTE object | +-----------------------------------+ | zero or more Response Object | +-----------------------------------+ 3.1. RSVP Message Common Header In the RSVP message common header, 0 1 2 3 +-------------+-------------+-------------+-------------+ | Vers | Flags| Type | RSVP Checksum | +-------------+-------------+-------------+-------------+ | Send_TTL | reserved | RSVP Length | +-------------+-------------+-------------+-------------+ The Flags field is unused for now and must be set to zero. Type = 8: DREQ Type = 9: DREP draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 5]
INTERNET-DRAFT February 1999 The RSVP Checksum is the 16-bit one's complement of the one's complement sum of the whole diagnosis message (including this header). For computing the checksum, the checksum field is set to zero. When receiving packets, the checksum MUST be verified before processing a packet. Send_TTL: the TTL value that a router puts in the IP packet header when forwarding the DREQ packet to the previous hop. RSVP length: the total length of this diagnostic packet in bytes, including the common header. If this is a DREP packet and the MF flag in the diagnostic packet header (see below) is set, this length field indicate the length of this single DREP fragment, rather than the total length of the the complete DREP reply (which may not be known in advance). 3.2. RSVP Diagnostic Packet Header Object Both DREQ and DREP headers are a concatenation of Diagnostic Packet Header Object and an RSVP Session object, as defined below: draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 6]
INTERNET-DRAFT February 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | class | c-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-RSVP-hops | RSVP-hop-count| Reserved |H|MF| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +---------------+---------------+---------------+---------------+ | path MTU | Fragment offset | +---------------+---------------+---------------+---------------+ | | | Sender Filter-Spec | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAST-HOP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Response Address Filter-Spec | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Next-Hop RSVP_HOP Object | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | + Followed by RSVP Session Object | | | Length is the length of this diagnostic header object. Class = 30. C-type field is used to distinguish between IPv4 (C-type = 1) and IPv6 (Ctype = 2). In the IPv6 case addresses will be 16 bytes each. Max-RSVP-hops specifies the maximum number of RSVP hops that the requester wants to collect information from. In case an error condition in the middle of the path prevents the DREQ packet from reaching the specified sender, one may use this field to perform an expanding-length search to reach the point just before the problem. The fragment offset field indicates where in the total reply this draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 7]
INTERNET-DRAFT February 1999 fragment belongs. The fragment offset is measured in octets. The first fragment has offset zero. RSVP-hop-count field records the number of RSVP hops that have been traversed so far. The H flag indicates how the reply should be returned. When H = 0, DREP packets should be sent to the response address directly. If H = 1, DREP packets must be returned to the LAST-HOP address in a hop- by-hop way. The node specified by the LAST-HOP address then forwards DREP packets to the response address. The MF flag means "more fragments". It must be set to zero (0) on all DREQ packets, and set to one (1) on all DREP packets that carry partial results and are returned by intermediate routers due to the MTU limit. When the sender converts a DREQ packet to DREP, the MF flag remains zero. An intermediate router may also converts a DREQ packet to DREP when the DREQ packet has traversed the specified number of Max-RSVP-hops, in which case the MF flag remains zero. Message ID identifies an individual DREQ packet and the corresponding reply (or all the fragments of the reply). A possible way of using the message ID is the 16 bits to specify the ID of the process doing the query and the low 16 bits to be the sequence number of the query. This way processes on the same machine can distinguish between each other's replies and between different copies of the same query. The path MTU is a 16-bit field that specifies a default MTU size, in number of bytes, that all diagnostic packets must fit within. Sender Filter-Spec is the IP address plus the port of the sender being traced. The DREQ packet proceeds hop-by-hop towards this address. LAST-HOP address is the IP address of the last hop at the receiving end for the path being traced. The DREQ packet starts collecting information at this node and proceeds toward the sender. Response Address Filter-Spec contains the IP address and the port to which the DREP packet(s) should be sent. This Response Address Filter-Spec specifies the process originating the request. The Next-Hop RSVP_HOP object carries the IP address of the interface to which the DREQ must be forwarded to. This object is updated on a hop by hop basis, and is used for the same reasons that a RESV message contains an RSVP_HOP object. That is, to distinguish logical interfaces and avoid problems caused by routing asymmetries. draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 8]
INTERNET-DRAFT February 1999 The session object identifies the RSVP session for which the state information is being collected. Optionally, the diagnostic packet may contain a SELECT object which carries a list of [Class, C-type] pairs, each pair specifies one type of RSVP object the diagnosis invoking client wants to examine. When a SELECT object is included in the DREQ packet, each RSVP router along the way should attach to the response object each type of the objects specified in the SELECT list. In the absence of a SELECT object, the router will attach a set of default objects. The SELECT object has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | class | c-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | class | c-type | class | c-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field represents the total length of the object in number of bytes. Class = 33 C-type field is not used at the moment and must be set to zero. The object payload part carries a list of [Class, C-type] pairs. In case where the requested number of objects is an odd number, the last two bytes must be set to zero. Optionally, the diagnostic packet may also contain a ROUTE object, as defined below. The ROUTE object is to be used to return DREP packets hop-by-hop. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | class | c-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | R-pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + List of RSVP routers | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 9]
INTERNET-DRAFT February 1999 The Length field represents the total length of the object in number of bytes, from which the number of addresses in the RSVP router list can be easily computed. Class = 31. C-type field is used to distinguish between IPv4 (C-type = 1) and IPv6 (Ctype = 2) ROUTE object. R-pointer is used in DREP packets only (see Section 4.2 for details), but is incremented as each hop adds its incoming interface address in the ROUTE object. In a DREQ packet, the List of RSVP routers lists all the RSVP hops between the LAST-HOP address, as specified in the Diagnostic packet header object, and the last RSVP router the DREQ packet has visited. In a DREP packet, List of RSVP routers lists all the RSVP hops between the LAST-HOP and the router that returns this DREP packet. 3.3. Response Data Object When receiving a DREQ packet, each RSVP router attaches a "response data" object to it before forwarding on. The response data object is defined as follows: draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 10]
INTERNET-DRAFT February 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | class | C-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DREQ Arrival Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Incoming Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outgoing Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous-RSVP-Hop Router Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reservation style | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | D-TTL |M|R-err| K | timer value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | (TUNNEL object) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Tspec object | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | filter spec object | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | flowspec object | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class = 32. Ctype 1 and 2 specify whether this is an IPv4 or IPv6 response data, respectively. DREQ Arrival Time is a 32-bit NTP timestamp specifying the arrival time of the DREQ packet at this router. The 32-bit form of an NTP timestamp consists of the middle 32 bits of the full 64-bit form; that is, the low 16 bits of the integer part and the high 16 bits of the fractional part. Incoming Interface Address specifies the IP address of the interface draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 11]
INTERNET-DRAFT February 1999 on which packets from the sender, as defined in the Diagnostic Packet Header, are expected to arrive, or 0 if unknown. Outgoing Interface Address specifies the IP address of the interface from which the DREQ packet comes, and to which packets from the given sender and for the specified session address flow, or 0 if unknown. Previous-RSVP-Hop Router Address specifies the router from which this router receives RSVP PATH messages for this source, or 0 if unknown. Notice that the response object format as shown above assumes IPv4 addresses of 4-byte each; in case of IPv6 (indicated by C-type = 2), these three addresses will be 16 bytes each. Reservation style is the 4-byte value of RSVP Style Object as defined in the RSVP specification. D-TTL contains the routing hop count this DREQ packet traveled from the down-stream RSVP router to the current router. M is a single-bit flag which indicates whether the reservation, as described by the objects below, is merged with reservations from other downstream interfaces when being forwarded upstream. R-error is a 3-bit field that indicates error conditions at a router. Currently defined values are 0x00: no error 0x01: no PATH state 0x02: MTU too big 0x04: ROUTE object too big K is the refresh timer parameter defined in RSVP, and timer value is the local refresh timer value in seconds. The next part, TUNNEL object, is an optional one which should be inserted when a DREQ packet arrives at an RSVP router that acts as a tunnel exit point. The TUNNEL object provides mapping between the end-to-end RSVP session that is being diagnosed and the RSVP session over the tunnel. This mapping information allows the diagnosis client to conduct diagnosis over the involved tunnel session when so desired, by invoking a separate Diagnostic query for the corresponding Tunnel Session and Tunnel Sender. Keep in mind, however, that multiple end-to-end sessions may all map to one pre- configured tunnel session which may have totally different parameter settings. The tunnel object is defined in the RSVP Tunnel Specification [RSVPTUN], with the following format: draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 12]
INTERNET-DRAFT February 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | class | c-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Session object (for the end-to-end session) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sender Filter-Spec (for the tunnel sender) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SESSION_ASSOC Object Class=192. Ctype 1 specifies IPv4 sessions, Ctype 2 specifies IPv6 sessions, and Ctypes 3 and 4 specify sessions with IPSEC Generalized Port Id for IPv4 and IPv6 respectively. The remaining parts, Tspec, filter spec, and flowspec objects follow the definitions given in RSVP specification. The latter two may be absent (see Section 4.1 on DREQ forwarding). In the case of a SE reservation the filter spec is actually the set of all filter specs that share the reservation. The flowspec describes the actual reservation in place. Also note that the length of these object is varying so the lengths used on the diagram above are not representative. 4. Diagnostic Packet Forwarding Rules 4.1. DREQ Packet Forwarding DREQ packets are forwarded via hop-by-hop unicast from the LAST-HOP address to the Sender address as specified in the diagnostic packet header. Each hop performs the following processing before forwarding the packet to the next hop towards the sender: 1. Compute the routing hop count from the previous RSVP hop. This is done by subtracting the value of the TTL value in the IP header from Send_TTL in RSVP common header. The result is then saved in the D-TTL field of the response data object. 2. If no PATH state exists for the specified session, set R-error = draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 13]
INTERNET-DRAFT February 1999 0x01 in the Response Data object. 3. If the path MTU value is too large, set "MTU too large" error bit, and change the MTU value to the MTU value of the incoming interface for PATH messages for the current router. 4. Attach the response data object to the end of the DREQ packet. If the DREQ packet contains a SELECT object, attach one copy of each of the objects specified in the SELECT. Otherwise attach Tspec, filter spec, and flowspec objects to the response object. Tspec, filter spec, and flowspec objects describe the reservation in place at the Outgoing Interface for the specified session. If no reservation state exists for the specified RSVP session, the response object will contain no filter-spec or flowspec object. If neither PATH nor reservation state exists for the specified RSVP session, then the response object contains none of the Tspec, filter or flow spec object. 5. Increment the RSVP-hop-count field in the diagnostic packet header by one. If the resulting value is equal to that of Max- RSVP-hops, or if the current hop is the sender as identified by the "Source Address" in the RSVP diagnostic header, go to Send_DREP(), and then return. 6. If any error bit is set, change the type field in RSVP common header from DREQ to DREP, recompute the checksum and send the packet back to either the LAST-HOP address (if H = 1), or to the response address directly via unicast (if H = 0). 7. If the resulting DREQ packet size exceeds the MTU limit, minus some margin to hold the address list object as described below, go to Send_DREP(). 8. If no error bit set ,then if the H-bit is set, append the "Incoming Interface Address" to the end of the ROUTE object, increment R-Pointer by one, update the Next-Hop RSVP_HOP object to be the Previous Hop from the Path State and update the packet length field in the RSVP common header accordingly. Finally forward the DREQ packet to the next hop towards the source, after recomputing the checksum. Send_DREP(): draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 14]
INTERNET-DRAFT February 1999 1. If the H flag in the Diagnostic Header header is off, set target=response address given in the DREQ header, else set target = the last address in ROUTE. 2. Make a copy of the DREQ packet and change the type field in RSVP common header from DREQ to DREP. If this host is not the source set the MF flag on. If the ROUTE object is so large such that (size of ROUTE + size of response data object) > path MTU, then set the "route too big" error bit, recompute the checksum, send the response packet and go to 4, else recompute the checksum and send the response packet. 3. If this host is not the source, then trim off all the response data objects from the original DREQ packet, adjust the "Fragment offset" value in the RSVP common header accordingly and forward the modified DREQ packet towards the source, after recomputing the checksum. 4. Return. 4.2. DREP Forwarding When the H flag is off, DREP packets are sent directly to the original requester. When H flag is on, however, they are forwarded hop-by-hop towards the requester, by reversing the route as listed in the Route object. When a router receives a DREP packet, it simply decreases R-pointer by one (address length), and forward the packet to the address pointed by R-pointer in the route list. When the LAST-HOP router receives a DREP packet, it sends the packet to the Response address. 4.3. MTU Selection and Adjustment Because the DREQ packet carries the allowed MTU size of previous hops that the DREP packets will later traverse, this unique feature allows the easy semantic fragmentation as described above. Whenever the DREQ packet grows to approach the size of MTU, it can be trimmed before being forwarded again. When a requester sends a DREQ packet, the path MTU field in the RSVP Diagnostic Packet header can be set to a configured default value. draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 15]
INTERNET-DRAFT February 1999 Whenever a DREQ packet size approaches the specified MTU value, an intermediate RSVP router makes a copy of the packet, converts it to a DREP packet to send back, and then trims off the partial results from DREQ packet and forwards it. It is possible that the original MTU value is chosen larger than the actual MTU value along some portion of the path being traced. Therefore each intermediate RSVP router must check the MTU value when processing a DREQ packet. If the specified MTU value is larger than the MTU of the incoming interface (that the DREQ packet will be forwarded to), the router (1) sets the R-error value, (2) changes the MTU value in the header to the smaller value, and (3) converts the DREQ packet to a DREP and sends it back to the requester. In the rare case where some intermediate routers do not check, or enforce upon, the MTU value carried in the diagnostic packets, it is possible that on the way back to the requester, a DREP packet may encounter a link of smaller MTU. When this happens, the router follows steps (1) and (2) as outlined above, and trims off the extra part of the DREP packet to fit in the smaller MTU of the link. The trimming must be done at response object boundaries. Such trimming of packets results in information loss. However because the requester learns what is the available MTU size, it can either ignore the loss, or otherwise try again with the smaller MTU value. 4.4. Errors If an error condition prevents a DREP packet from being forwarded further, the packet is simply dropped. If an error condition, such as lack of PATH state, prevents a DREQ packet from being forwarded further, the router must change the current packet to DREP type and return it to the response address. 5. Problem Diagnosis by Using RSVP Diagnostic Facility 5.1. Across Firewalls Firewalls may cause problems in diagnostic packet forwarding. Let us look at two different cases. draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 16]
INTERNET-DRAFT February 1999 First, let us assume that the querier resides on a receiving host of the session to be examined. In this case, firewalls should not prevent the forwarding of the diagnostic packets in a hop-by-hop manner, assuming that proper holes have been punched on the firewall to allow hop-by-hop forwarding of other RSVP packets. The querier may start by setting the H flag off, which can give a faster response delivery and reduced overhead at intermediate routers. However if no response is received, the querier may resend the DREQ packet with H flag turned on. If the requester is a third party host and is separated from the LAST-HOP address by a firewall (either the requester is behind a firewall, or the LAST-HOP is a router behind a firewall, or both), at this time we do not know any other solution but to change the LAST- HOP to a node that is on the same side of the firewall as the requester. 5.2. Examination of RSVP Timers One can easily collect information about the current timer value at each RSVP hop along the way. This will be very helpful in situations when the reservation state goes up and down frequently, to find out whether the state changes are due to improper setting of timer values, or K values (when across lossy links), or frequent routing changes. 5.3. Discovering Non-RSVP Clouds The D-TTL field in each response data block shows the number of routing hops between adjacent RSVP routers. Therefore any value greater than one indicates a non-RSVP clouds in between. Together with the arrival timestamps (assuming NTP works), this value can also give some vague, though not necessarily accurate, indication of how big that cloud might be. One might also find out all the intermediate non-RSVP routers by running either unicast or multicast trace route. 5.4. Discovering Reservation Merges The flowspec value in a response data block specifies the amount of resources being reserved for the data stream defined by the filter spec in the same data block. When this value of adjacent response data blocks differs, that is, a downstream router Rd has a smaller value than its immediate upstream router Ru, it indicates a merge of reservation with RSVP request(s) from other down stream interface(s) draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 17]
INTERNET-DRAFT February 1999 at Rd. Further, in case of SE style reservation, one can examine how the different SE scopes get merged at each hop. In particular, if a receiver sends a DREQ packet before sending its own reservation, it can discover (1) how many RSVP hops there are along the path between the specified sender and itself, (2) how many of the hops already have some reservation by other receivers, and (3) possibly a rough prediction of how its reservation request might get merged with other existing ones. 5.5. Error Diagnosis In addition to examining the state of a working reservation, RSVP diagnostic packets are more likely to be invoked when things are not working correctly. For example, a receiver has reserved an adequate pipe for a specified incoming data stream, yet the observed delay or loss ratio is much higher than expected. In this case the receiver can use the diagnostic facility to examine the reservation state at each RSVP hop along the way to find out whether the RSVP state is set up correctly, whether there is any blackhole along the way that caused RSVP message losses, or whether there are non-RSVP clouds, and where they are, that may have caused the performance problem. 5.6. Crossing "Legacy" RSVP Routers Given that this diagnosis function is developed and added to RSVP after a number of RSVP implementations have been in place, it is possible, or even likely, that when performing RSVP diagnosis, one may encounter one or more RSVP-capable routers that do not understand diagnostic packets, thus drop them. When this happens, the invoking client will get no response from its requests. One way to by-pass such "legacy" RSVP routers is running an iteration of RSVP diagnosis by using information from traceroute, or mtrace in case of multicast. When an RSVP diagnostic query times out (see next section), one may first use traceroute to get the list of routers along the path, and then gradually increases the value of Max-RSVP- hops field in the DREQ packet, starting from a low value until one no longer receives a response. One can then try RSVP diagnosis again by starting with the first router (which is further upstream towards the sender) after the unresponding one. draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 18]
INTERNET-DRAFT February 1999 6. Comments on Diagnostic Client Implementation. Following the design principle that routers in the network should not hold more than necessary state, RSVP nodes are responsible only for forwarding Diagnostic packets and filling Response Data Objects. Additional diagnostic functionalities should be carried out by the Diagnostic Clients. Furthermore, if the diagnostic function is invoked from a third-party host, we should not not require that host be running RSVP daemon to perform the function. Below we sketch out the basic functions that a diagnostic client daemon should carry out. 1. Take input from the user about the session to be diagnosed, the last-hop and the sender address, the Max-RSVP-hops, and possibly the SELECT list, create a DREQ packet and send to the LAST-HOP RSVP node using raw IP packet with protocol number 46 (RSVP). The port of the UDP socket that the Diagnostic Client is listening to for replies, should be included in the Response Address Filter-Spec. 2. Set a retransmission timer, waiting for the reply (one or more DREP packets). Listen to the UDP port specified in the Response Address Filter-Spec for responses from the LAST-HOP RSVP node. The LAST-HOP RSVP node upon receiving DREP packets sends them to the the Diagnostic Client as UDP packets, using the port supplied to in the Response Address Filter-Spec. 3. Upon receiving a DREP packet to an outstanding diagnostic request, the client should clear the retransmission timer, check to see if the reply contains the complete result of the requested diagnosis. If so, it should pass the result up to the invoking entity immediately. 4. Reassemble DREP fragments. If the first reply to an outstanding diagnostic request contains only a fragment of the expected result, the client should set up a reassembly timer in a way similar to IP packet reassembly timer. If the timer goes off before all fragments arrive, the client should pass the partial result to the invoking entity. 5. Use retransmission and reassembly timers to gracefully handle packet losses and reply fragment scenarios. In the absence of response to the first diagnostic request, a client should retransmit the request a few times. If all the retransmissions also fail, the client should invoke traceroute or mtrace to obtain the list of hops along the path segment to be diagnosed, and then perform an iteration of diagnosis with increasing hop count as suggested in Section 5.6 in order to cross RSVP-capable draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 19]
INTERNET-DRAFT February 1999 but diagnosis-incapable routers. 6. If all the above efforts fail, the client must notify the invoking entity. 7. Security Considerations RSVP Diagnostics, as any other diagnostic tool, can be a security threat since it can reveal possibly sensitive RSVP state information to unwanted third parties. We feel that the threat is minimal, since as explained in the Introduction Diagnostics messages produce no side-effects and therefore they cannot change RSVP state in the routers. In this respect RSVP Diagnostics is less a security threat than other diagnostic tools and protocols such as SNMP. Furthermore, processing of Diagnostic messages can be disabled if it is felt that is a security threat. 8. Acknowledgments The idea of developing a diagnostic facility for RSVP was first suggested by Mark Handley of UCL. Many thanks to Lee Breslau of Xerox PARC and John Krawczyk of Baynetworks for their valuable comments on the first draft of this memo. Lee Breslau, Bob Braden, and John Krawczyk contributed further comments after March 1996 IETF. Steven Berson provided valuable comments on various drafts of the memo. We would also like to acknowledge Intel for providing a research grant as a partial support for this work. 9. References [RSVPTUN] L. Zhang, A. Terzis, "RSVP Operation Over IP Tunnels ", Internet Draft draft-ietf-rsvp-tunnel-02.txt, November, 1997. 10. Authors' Addresses Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90095 draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 20]
INTERNET-DRAFT February 1999 Phone: 310-825-2695 EMail: lixia@cs.ucla.edu Andreas Terzis UCLA 4677 Boelter Hall Los Angeles, CA 90095 Phone: 310-267-2190 Email: terzis@cs.ucla.edu Subramaniam Vincent draft-ietf-rsvp-diagnostic-msgs-04.txt [Page 21]
