RFC 2745

RSVP Diagnostic Messages

📅 published January 2000, from ietf

RSVP Diagnostic Messages 🎀

Bestie, here are the deets from the top of this RFC 💅

  • RFC: 2745
  • Category: Standards Track 🧚
  • Date: January 2000 📅
  • Authors: A. Terzis (UCLA), B. Braden (ISI), S. Vincent (Cisco Systems), L. Zhang (UCLA) 👑
  • Obsoletes: nothing listed
  • Updates: nothing listed

Status of This Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. 🌸 Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 💖

Copyright (C) The Internet Society (2000). All Rights Reserved. 🔒

Abstract

Okay so this document is all about the RSVP diagnostic facility 🔍, which lets a user collect info about the RSVP state along a path. It covers the functionality, the diagnostic message formats, and the processing rules. Lowkey the whole point ✨

1. Introduction ✨

Okay so in the basic RSVP protocol [RSVP], error messages are the ONLY way an end host gets feedback when something goes wrong while setting up path state or reservation state. 🙈 An error message only carries back info from the failed point, with nothing about the state at the other hops before or after it. And when nothing fails, a host gets zero feedback about the reservation it put in place. Like, it can't tell whether or where or how its request is being merged with everyone else's. That missing info is honestly a big deal for debugging, or for network resource management in general. 😭

So this document is here to fill that gap 🫶. The diagnostic facility can collect and report RSVP state info along the path from a receiver to a specific sender. It uses Diagnostic messages that are independent of other RSVP control messages and produce no side-effects. Translation: they don't change any RSVP state at either nodes or hosts. 🦋 They also aren't an error report. They're more like a collection of the RSVP state info you asked for. Iconic 💅

The RSVP diagnostic facility was designed with these goals:

  • To collect RSVP state information from every RSVP-capable hop along a path defined by path state, either for an existing reservation or before a reservation request is made. More specifically, we want to be able to collect information about flowspecs, refresh timer values, and reservation merging at each hop along the path. 🌈
  • To collect the IP hop count across each non-RSVP cloud. ☁️
  • To avoid diagnostic packet implosion or explosion. 💥

This is specifically NOT a goal (no cap):

  • Checking the resource availability along a path. Such functionality may be useful for future reservation requests, but it would require modifications to existing admission control modules that is beyond the scope of RSVP. 🙅‍♀️

2. Overview 🌸

The diagnostic facility introduces two new RSVP message types: Diagnostic Request (DREQ) and Diagnostic Reply (DREP). 🎀 A DREQ message can be originated by a client in a "requester" host. That host may or may not be a participant of the RSVP session being diagnosed, which is giving very independent energy 💅

Here's how it goes. A client in the requester host invokes the diagnostic facility by generating a DREQ packet and sending it towards the LAST-HOP node. The LAST-HOP node should be on the RSVP path being diagnosed. The DREQ packet specifies the RSVP session and a sender host for that session. ✨ Starting from the LAST-HOP, the DREQ packet collects info hop-by-hop as it's forwarded towards the sender (check Figure 1), until it reaches the ending node. Specifically, each RSVP-capable hop adds a response (DIAG_RESPONSE) object to the DREQ message. That object holds the local RSVP state for the specified session. 🧚

When the DREQ packet reaches the ending node, the message type changes to Diagnostic Reply (DREP), and the completed response gets sent back to the original requester node. 🦋 Partial responses can also come back before the DREQ reaches the ending node. That happens if an error condition along the path, such as "no path state", stops the DREQ from being forwarded any further. And to avoid packet implosion or explosion, all diagnostic packets are forwarded via unicast only. 🙅‍♀️

So generally there are three nodes (hosts and/or routers) involved: the requester node, the starting node, and the ending node, as shown in Figure 1. 🫶 The client that invokes the diagnosis can live directly on the starting node, in which case the first two nodes are the same. The starting node is named "LAST-HOP", meaning the last-hop of the path segment being diagnosed. The LAST-HOP node can be a receiver node or an intermediate node along the path. The ending node is usually the specified sender host. However, the client can limit how long the path segment being diagnosed is by specifying a hop-count limit in the DREQ message. 🍓

                  LAST-HOP                  Ending
     Receiver        node                     node           Sender
         __           __         __            __              __
        |  |---------|  |------>|  |--> ...-->|  |--> ...---->|  |
        |__|         |__| DREQ  |__|   DREQ   |__|   DREQ     |__|
                      ^                         .              |
                      |                         .              |
                      | DREQ                    . DREP         | DREP
                      |                         .              |
                     _|_               DREP     V              V
        Requester   |   | <------------------------------------
        (client)    |___|

                         Figure 1

DREP packets can be unicast from the ending node back to the requester, either directly or hop-by-hop along the reverse of the path the DREQ took to the LAST-HOP, and then on to the requester. 🔥 The direct return is faster and more efficient. The hop-by-hop reverse-path route may be the only choice if the packets have to cross firewalls. 🧱 Hop-by-hop return uses an optional ROUTE object, which gets built incrementally to hold a list of node addresses the DREQ packet has passed through. The ROUTE object is then used in reverse as a source route to forward the DREP hop-by-hop back to the LAST-HOP node. Big brain stuff, honestly 🧠💖

A DREQ message always consists of a single unfragmented IP datagram. 📦 On the other hand, one DREQ message can generate multiple DREP packets, each containing a fragment of the total DREQ message. When the path has a lot of hops, the total length of a DREP message will exceed the MTU size before it reaches the ending node. So the message has to be fragmented. 😩 Relying on IP fragmentation and reassembly can be problematic, though, especially when DREP messages are returned to the requester hop-by-hop. In that case, fragmentation and reassembly would have to happen at every hop, which is a LOT of overhead. 🙈

To avoid that excessive overhead, the requester defines a default path MTU size that gets carried in every DREQ packet. 🎀 If an intermediate node finds that the default MTU size is bigger than the MTU of the incoming interface, it reduces the default MTU size to the MTU of the incoming interface. ✂️ If an intermediate node detects that a DREQ packet's size is larger than the default MTU size, it returns a DREP fragment containing the accumulated responses to the requester, in either manner described above. Then it removes those responses from the DREQ and keeps forwarding it. ➡️ The requester node can reassemble the resulting DREP fragments into a complete DREP message. Periodt 💅

When talking about diagnostic packet handling, this document uses direction terminology that matches the RSVP functional specification [RSVP], relative to the direction of data packet flow. So a DREQ packet enters a node through an "outgoing interface" and is forwarded towards the sender through an "incoming interface". Why? Because DREQ packets travel in the reverse direction to the data flow. 🔄

Notice that DREQ packets can only be forwarded after the RSVP path state has been set up. ⚠️ If no path state exists, you may resort to the traceroute or mtrace facility to examine whether the unicast/multicast routing is working correctly. 🗺️

3. Diagnostic Packet Format 💜

Like other RSVP messages, DREQ and DREP messages consist of an RSVP Common Header followed by a variable set of typed RSVP data objects. The following sequence must be used: 📋

        +-----------------------------------+
        |        RSVP Common Header         |
        +-----------------------------------+
        |         Session object            |
        +-----------------------------------+
        |      Next-Hop RSVP_HOP object     |
        +-----------------------------------+
        |       DIAGNOSTIC object           |
        +-----------------------------------+
        |    (optional) DIAG_SELECT object  |
        +-----------------------------------+
        |    (optional) ROUTE object        |
        +-----------------------------------+
        | zero or more DIAG_RESPONSE objects|
        +-----------------------------------+

The session object identifies the RSVP session whose state info is being collected. 🎯 We'll go through each of the other parts now 🫶

3.1. RSVP Message Common Header 🎀

The RSVP message common header is defined in [RSVP]. DREP and DREQ need the following specific exceptions and extensions. 🧩

Type field: define:

       Type = 8: DREQ     Diagnostic Request

       Type = 9: DREP     Diagnostic Reply

RSVP length:

  • If this is a DREP message and the MF flag in the DIAGNOSTIC object (see below) is set, this field indicates the length of this single DREP fragment, rather than the total length of the complete DREP reply message. That total can't generally be known in advance. 📏

3.2. Next-Hop RSVP_HOP Object 🦋

This RSVP_HOP object carries the LIH of the interface through which the DREQ should be received at the upstream node. This object gets updated hop-by-hop. It's used for the same reasons that a RESV message contains an RSVP_HOP object: to tell logical interfaces apart and avoid problems caused by routing asymmetries and non-RSVP clouds. 🌈

Even though the IP address isn't really used during DREQ processing, the IP address in the RSVP_HOP object should still contain the address of the interface through which the DREQ was sent, for consistency with how the RSVP_HOP object is used in other RSVP messages. 💖

3.3. DIAGNOSTIC Object 🎀

okay so the DIAGNOSTIC object is the one that holds the common diagnostic control info in both DREQ and DREP messages 💅✨

  • IPv4 DIAGNOSTIC object: Class = 30, C-Type = 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Max-RSVP-hops | RSVP-hop-count|         Reserved            |MF|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Request ID                           |
    +---------------+---------------+---------------+---------------+
    |           Path MTU            |     Fragment Offset           |
    +---------------+---------------+---------------+---------------+
    |                         LAST-HOP Address                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                     SENDER_TEMPLATE object                    |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                 Requester FILTER_SPEC object                  |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ngl the IPv4 version is giving clean and organised 🌸 Every IP address in it uses the 4 byte IPv4 format, both in the LAST-HOP Address and in the IPv4 forms of the embedded FILTER_SPEC and RSVP_HOP objects.

  • IPv6 DIAGNOSTIC object: Class = 30, C-Type = 2

The format is the same, except every explicit and embedded IP address is a 16 byte IPv6 address 🦋

The fields go like this 👑

Max-RSVP-hops

An octet specifying the maximum number of RSVP hops over which information will be collected. If an error condition in the middle of the path stops the DREQ packet from reaching the specified ending node, the Max-RSVP-hops field may be used to do an expanding-length search to reach the point just before the problem. If this value is 1, the starting node and the ending node of the query will be the same. If it is zero, there is no hop limit. main character energy for this field 💜

RSVP-hop-count

Records the number of RSVP hops that have been traversed so far. If the starting and ending nodes are the same, this value will be 1 in the resulting DREP message.

Fragment Offset

Indicates where this DREP fragment belongs in the complete DREP message, measured in octets. The first fragment has offset zero. Fragment Offset is also used to determine if a DREQ message containing zero DIAG_RESPONSE objects should be processed at an RSVP capable node 🧚

MF flag

MF means "more fragments" 🙈 The flag must be set to zero (0) in all DREQ messages. It must be set to one (1) in all DREP packets that carry partial results and are returned by intermediate nodes because of the MTU limit. When the DREQ message gets converted to a DREP message in the ending node, the MF flag must remain zero.

the MF flag rules are super specific, so read them twice bestie 🫶

Request ID

Identifies an individual DREQ message and its corresponding DREP message (or all the fragments of the reply message) 🍓

One possible way to define the Request ID would use 16 bits to specify the ID of the process making the query and 16 bits to tell apart different queries from that process.

Path MTU

Specifies a default MTU size in octets for DREP and DREQ messages. This value should not be smaller than the size of the "base" DREQ packet. A "base" DREQ packet is one that contains a Common Header, a Session object, a Next-Hop RSVP_HOP object, a DIAGNOSTIC object, an empty ROUTE object and a single default DIAG_RESPONSE (see below). The assumption here is that a diagnostic packet of this size can always be forwarded without IP fragmentation ✨

LAST-HOP Address

The IP address of the LAST-HOP node. The DREQ message starts collecting information at this node and then proceeds toward the sender 🌈

SENDER_TEMPLATE object

This IPv4/IPv6 SENDER_TEMPLATE object holds the IP address and the port of a sender for the session being diagnosed. The DREQ packet gets forwarded hop-by-hop towards this address 🚀

Requester FILTER_SPEC Object

This IPv4/IPv6 FILTER_SPEC object holds the IP address and the port the request came from, which is also where the DREP message(s) should be sent 💖

3.4. DIAG_SELECT Object 🦋

  • DIAG_SELECT Class = 33, C-Type = 1.

A Diagnostic message may optionally include a DIAG_SELECT object to pick which specific RSVP objects should be reported in a DIAG_RESPONSE object. If there's no DIAG_SELECT object, the DIAG_RESPONSE object the node adds will contain a default set of object types (see DIAG_RESPONSE object below) 🎀

The DIAG_SELECT object holds a list of [Class, C-type] pairs, formatted like this:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    class      |     C-Type    |    class      |     C-Type    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    //                                                             //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    class      |     C-Type    |    class      |     C-Type    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

When a DIAG_SELECT object is included in a DREQ message, each RSVP node along the path adds a DIAG_RESPONSE object containing response objects (see below) whose classes and C-Types match entries in the DIAG_SELECT list, as long as they come from matching path and reservation state. A C-type octet of zero is a 'wildcard' 🌟 It matches any C-Type associated with the class.

Depending on what kind of objects are requested, a node can find the related information in the path or reservation state stored for the session described in the SESSION object. To be specific, info for the RSVP_HOP, SENDER_TEMPLATE, SENDER_TSPEC and ADSPEC objects can be pulled from the node's path state, while info for the FLOWSPEC, FILTER_SPEC, CONFIRM, STYLE and SCOPE objects can be found in the node's reservation state (if it exists) 💅

If the number of [Class, C-Type] pairs is odd, the last two octets of the DIAG_SELECT object must be zero 🙈 A maximum DIAG_SELECT object is one that contains the [Class, C-type] pairs for all the RSVP objects that can be requested in a Diagnostic query. obsessed with how thorough this is 😭

3.5. ROUTE Object 🧚

A diagnostic message may contain a ROUTE object. It records the route of the DREQ message and works as a source route for returning the DREP message(s) hop-by-hop 🍓

  • IPv4 ROUTE object: Class = 31, C-Type = 1.
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             reserved                          |    R-pointer  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                     RSVP Node List                            |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This message signifies how the reply should be returned 🦋 If the ROUTE object isn't in the DREQ packet, DREP packets should be sent to the requester directly. If it is there, DREP packets must be returned hop-by-hop along the reverse path to the LAST-HOP node and then on to the requester node 💖

An empty ROUTE object is one with an empty RSVP Node list where the R-pointer is equal to zero.

RSVP Node List

A list of RSVP node IPv4 addresses. You can work out how many addresses are in this list from the object size ✨

R-pointer

Used in DREP messages only (see Section 4.2 for details). It gets incremented as each hop adds its incoming interface address in the ROUTE object 🌸

  • IPv6 ROUTE object: Class = 31, C-Type = 2

Same deal, except the RSVP Node List contains IPv6 addresses 🌈

In a DREQ message, the RSVP Node List specifies all the RSVP hops between the LAST-HOP address given in the DIAGNOSTIC object and the last RSVP node the DREQ message visited. In a DREP message, the RSVP Node List specifies all the RSVP hops between the LAST-HOP and the node returning that DREP message 🫶

3.6. DIAG_RESPONSE Object 🎀

Okay so every RSVP node slaps a DIAG_RESPONSE object onto each DREQ it receives, before it forwards the message 💅. This is where the node spills its tea, meaning the state it's reporting for itself ✨. It has a fixed-format header and then a variable list of RSVP state objects, which we call "response objects" 🧚.

  • IPv4 DIAG_RESPONSE object: Class = 32, C-Type = 1 🌸
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       DREQ Arrival Time                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Incoming Interface Address                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Outgoing Interface Address                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Previous-RSVP-Hop Router Address              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   D-TTL       |M|R-err|  K    |      Timer value              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                  (optional) TUNNEL object                     |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                       Response objects                      //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • IPv6 DIAG_RESPONSE object: Class = 32, C-Type = 2 🦋

This one has the same layout, except that every explicit and embedded IP address is an IPv6 address 🌈.

The fields are as follows 💜:

DREQ Arrival Time

This is a 32-bit NTP timestamp for when the DREQ message showed up at this node ⏰. The 32-bit form is the middle 32 bits of the full 64-bit form, so you take the low 16 bits of the integer part and the high 16 bits of the fractional part 🤓.

Incoming Interface Address

This is the IP address of the interface where messages from the sender are expected to arrive, or 0 if it's unknown 🙈.

Outgoing Interface Address

This is the IP address of the interface the DREQ message arrived through, and the one tied to messages from the given sender and for the specified session address flow, or 0 if unknown 🦋.

Previous-RSVP-Hop Router Address

This is the IP address this node gets RSVP PATH messages from for this source, or 0 if unknown. It's also the interface the DREQ gets forwarded to 💌.

D-TTL

This is the number of IP hops the DREQ message traveled from the downstream RSVP node to the current node 🛣️.

M flag

This is a single-bit flag that tells you whether the reservation described by the response objects gets merged with reservations from other downstream interfaces when it's forwarded upstream 🔀.

R-error

This is a 3-bit field that shows error conditions at a node. Right now the defined values are 🚨:

    0x00: no error
    0x01: No PATH state
    0x02: packet too big
    0x04: ROUTE object too big

K

This is the refresh timer multiple (defined in [RSVP]) 🔁.

Timer value

This is the local refresh timer value, in seconds ⏱️.

The set of response objects at the end of the DIAG_RESPONSE object is decided by a DIAG_SELECT object, if one is there. If there's no DIAG_SELECT object, the response objects belong to the default list of classes 📋:

   SENDER_TSPEC object      FILTER_SPEC object      FLOWSPEC object
   STYLE object

Any C-Type that's in the local RSVP state will be used 🙌. These response objects can be in any order, but they must all be at the end of the DIAG_RESPONSE object 🎯.

A default DIAG_RESPONSE object is just one that has the default list of classes described above ✨.

3.7. TUNNEL Object 🚇

The optional TUNNEL object should be inserted when a DREQ message arrives at an RSVP node that acts as a tunnel exit point 🕳️.

The TUNNEL object gives the mapping between the end-to-end RSVP session being diagnosed and the RSVP session over the tunnel 🗺️. This mapping lets the diagnosis client run diagnosis over the tunnel session too, by sending a separate Diagnostic query for the matching Tunnel Session and Tunnel Sender 🔍.

Heads up though: multiple end-to-end sessions can all map to one pre-configured tunnel session, and that tunnel session may have totally different parameter settings 🙃.

The tunnel object is defined in the RSVP Tunnel Specification [RSVPTUN] 📖.

4. Diagnostic Packet Forwarding Rules 🚦

4.1. DREQ Packet Forwarding 📮

DREQ messages get forwarded hop-by-hop via unicast, from the LAST-HOP address to the Sender address, as specified in the DIAGNOSTIC object 🚀. If an RSVP capable node that isn't the LAST-HOP node receives a DREQ message that has no DIAG_RESPONSE objects and a zero Fragment Offset, the node should forward the DREQ packet towards the LAST-HOP without doing any of the processing below 🙅‍♀️. The reason is that those conditions only apply to nodes downstream of the LAST-HOP, where no information should be collected 🫶.

Processing starts when a DREQ message, DREQ_in, arrives at a node 🎬:

  1. Create a new DIAG_RESPONSE object. Compute the IP hop count from the previous RSVP hop by subtracting the TTL value in the IP header from Send_TTL in the RSVP common header. Save the result in the D-TTL field of the DIAG_RESPONSE object 🧮.
  2. Set the DREQ Arrival Time and the Outgoing Interface Address in the DIAG_RESPONSE object. If this node is the LAST-HOP, the Outgoing Interface Address field in the DIAG_RESPONSE object gets one of these values, depending on the session being diagnosed 👑:
    • If the session is a unicast session, the Outgoing Interface Address field holds the address of the interface that LAST-HOP uses to send PATH messages and data to the receiver specified by the session address 📬.
    • Otherwise, if it's a multicast session and there's at least one receiver for this session, LAST_HOP should use the address of one of its local interfaces that's used to reach one of the receivers 📡.
    • Otherwise, the Outgoing Interface Address should be zero 0️⃣.
  3. Increment the RSVP-hop-count field in the DIAGNOSTIC message object by one ➕.
  4. If no PATH state exists for the specified session, set R-error = 0x01 (No PATH state) and goto step 7 🙈.
  5. Set the rest of the fields in the DIAG_RESPONSE object. If DREQ_in contains a DIAG_SELECT object, the response object classes are the ones specified in the DIAG_SELECT. Otherwise, they're SENDER_TSPEC, STYLE, and FLOWSPEC objects 🎁. If no reservation state exists for the specified RSVP session, the DIAG_RESPONSE object won't contain any FLOWSPEC, FILTER_SPEC or STYLE object 🫥. If there's neither PATH nor reservation state for the specified RSVP session, then no response objects get appended to the DIAG_RESPONSE object 💤.
  6. If RSVP-hop-count is less than Max-RSVP-hops and this node is not the sender, then the DREQ is eligible for forwarding. Set the Path MTU to the min of the Path MTU and the MTU size of the incoming interface for the sender being diagnosed 📏.
  7. If the size of DREQ_in, plus the size of the new DIAG_RESPONSE object, plus the size of an IP address (if a ROUTE object exists and R-error = 0) is larger than Path MTU, then the new diagnostic message will be too large to be forwarded or returned without fragmentation. Set the "packet too big" (0x02) error bit in DIAG_RESPONSE and goto Step SD1 in Send_DREP (below) 💥.
  8. If the "No PATH state" (0x01) error bit is set, or if RSVP-hop-count is equal to Max-RSVP-hops, or if this node is the sender, then the DREQ can't be forwarded any further. Goto Step 10 🛑.
  9. Forward the DREQ towards the sender, like this 🏃‍♀️. If a ROUTE object exists, append the "Incoming Interface Address" to the end of the ROUTE object and increment R-Pointer by one. Update the Next-Hop RSVP_HOP object, append the new DIAG_RESPONSE object to the list of DIAG_RESPONSE objects, and update the message length field in the RSVP common header to match. Finally, recompute the checksum, forward DREQ_in to the next hop towards the sender, and return 💌.
  10. Turn the DREQ into a DREP and send it back to the requester, like this 🔄. Append the DIAG_RESPONSE object to the end of DREQ_in and update the packet length. If a ROUTE object is in the message, decrement the R-pointer and set the target address to the last address in the ROUTE object. Otherwise, set the target address to the requester address. Change the Type Field in the Common header from DREQ to DREP. Finally, recompute the checksum, send the DREP to the target address, and return 🏁. Note that the MF bit must be off in this case 🙅.

Send_DREP:

This sequence gets entered if the DREQ message, with the new DIAG_RESPONSE object added, is too large to be forwarded towards the sender or, if it's not eligible for forwarding, too large to be returned as a DREP 🧳.

SD1. Make a copy of DREQ_in and change the message type field from DREQ to DREP. Trim all DIAG_RESPONSE objects from DREQ_in and adjust the Fragment Offset. The DREP message contains the DIAG_RESPONSE objects that the earlier nodes accumulated 📦.

SD2. Send the DREP message towards the requester, like this 📨. If a ROUTE object is in the DREP message, decrement the R-pointer and set the target address to the last address in the ROUTE object. Otherwise, set the target address to the requester address. Set the MF bit, recompute the checksum, and send the DREP message back to the target address 🔙.

SD3. If the reduced size of DREQ_in, plus the size of DIAG_RESPONSE, plus the size of an IP address (if a ROUTE object exists) is smaller than or equal to Path MTU, then return to Step 8 of the main DREQ processing sequence above 🥰.

SD4. If a ROUTE object exists, replace the ROUTE object in DREQ_in with an empty ROUTE object and turn on the "ROUTE object too big" (0x04) error bit in the DIAG_RESPONSE. In either case, return to Step 8 of the main DREQ processing sequence above 🫠.

4.2. DREP Forwarding 🎁

When a ROUTE object is present, DREP messages get forwarded hop-by-hop towards the requester, by reversing the route listed in the ROUTE object 🔁. Otherwise, DREP messages get sent directly to the original requester 🎯.

When a node receives a DREP message, it just decreases R-pointer by one (the address length), recomputes the checksum, and forwards the message to the address the R-pointer points to in the route list 👉. If a node that isn't the LAST-HOP receives a DREP packet where R-pointer is equal to zero, it must send it directly to the requester 📬.

When the LAST-HOP node receives a DREP message, it sends the message to the requester 💖.

4.3. MTU Selection and Adjustment ✨

okay so the DREQ carries the allowed MTU size of the previous hops that the DREP messages will later travel through, and that's what makes this unique feature so good at easy semantic fragmentation, as we covered above 😭🫶. Whenever a DREQ starts getting close to the Path MTU, it can be trimmed before it gets forwarded again 💅

When a requester sends a DREQ, the Path MTU field in the DIAGNOSTIC object can be set to a configured default value 🎀. The original Path MTU might end up bigger than the actual MTU somewhere along the path being traced, which is a bit of a plot twist 🙈. So each intermediate RSVP node must check the MTU value when it processes a DREQ. If the specified MTU value is larger than the MTU of the incoming interface (the one the DREQ will be forwarded to), the node changes the MTU value in the header to the smaller value 🦋

Whenever the size of a DREQ becomes larger than the Path MTU value, an intermediate RSVP node makes a copy of the message and converts it to a DREP message to send back 💜. Then it trims off the partial results from the DREQ. If the DREQ still can't be forwarded upstream because of a large ROUTE object, the "ROUTE object too big" is set and the ROUTE object gets trimmed 😭. Once the ROUTE object is trimmed, the DREP(s) will come back hop-by-hop up to this node and then get forwarded straight to the requester address 🚀

Even if all of the steps above are followed, there are still a few cases where fragmentation at the IP layer will happen 🌸. For example, non-RSVP hops with smaller MTUs may exist before the LAST-HOP is reached. Or, if the response is sent directly back to the requester (instead of hop by hop), the DREP might take a different route to the requester than the DREQ took from the requester 💀. Another case is when there's a link with an MTU smaller than the minimum Path MTU value defined in Section 3.3 🧚

4.4. Errors ✨

If an error condition stops a DREP message from being forwarded any further, the message is simply dropped 🥀

If an error condition, such as lack of PATH state, stops a DREQ message from being forwarded any further, the node has to change the current message to DREP type and return it to the response address 👑

5. Problem Diagnosis by Using RSVP Diagnostic Facility 🔍

5.1. Across Firewalls 🧱

Firewalls can cause problems for diagnostic message forwarding, so let's look at two different cases 👀

First, let's assume the querier is on a receiving host of the session being examined. In this case, firewalls should not block the forwarding of diagnostic messages in a hop-by-hop manner, as long as proper holes have been punched in the firewall to allow hop-by-hop forwarding of other RSVP messages 🫶. The querier can start by leaving out the ROUTE object, which can mean faster response delivery and less overhead at intermediate nodes ⚡ However, if no response comes back, the querier can resend the DREQ message with a ROUTE object, specifying that a hop-by-hop reply should be sent 🔁

If the requester is a third-party host and is separated from the LAST-HOP address by a firewall (the requester is behind a firewall, the LAST-HOP is a node behind a firewall, or both), then at this point we don't know any other solution except to change the LAST-HOP to a node that's on the same side of the firewall as the requester 😤

5.2. Examination of RSVP Timers ⏰

You can easily collect information about the current timer value at each RSVP hop along the way 🍓. This is super helpful when the reservation state keeps going up and down, because it tells you whether the state changes are due to improper timer values, K values (when you're across lossy links), or frequent routing changes 🤔

5.3. Discovering Non-RSVP Clouds ☁️

The D-TTL field in each DIAG_RESPONSE object shows the number of routing hops between adjacent RSVP nodes 🛣️. So any value greater than one means there's a non-RSVP cloud in between ✨. Together with the arrival timestamps (assuming NTP works), this value can also give a vague, though not necessarily accurate, idea of how big that cloud might be 🌫️. You can also find all the intermediate non-RSVP nodes by running either unicast or multicast trace route 🗺️

5.4. Discovering Reservation Merges 🌀

The flowspec value in a DIAG_RESPONSE object tells you how much resource is being reserved for the data stream defined by the filter spec in the same data block 💰. When this value differs between adjacent DIAG_RESPONSE objects, meaning a downstream node Rd has a smaller value than its immediate upstream node Ru, it's a sign of a reservation merging with RSVP request(s) from other downstream interface(s) at Rd 💫. Also, with SE style reservation, you can see how the different SE scopes get merged at each hop 🧩

Here's the big one: if a receiver sends a DREQ message before sending its own reservation, it can figure out (1) how many RSVP hops there are along the path between the specified sender and itself, (2) how many of those hops already have some reservation from other receivers, and (3) possibly a rough prediction of how its reservation request might get merged with the existing ones 🔮

5.5. Error Diagnosis 🚨

Diagnostic messages are even more useful when things aren't working correctly, not just when you're checking a working reservation 😩. For example, a receiver has reserved an adequate pipe for an incoming data stream, but the observed delay or loss ratio is way higher than expected 😵. In that case, the receiver can use the diagnostic facility to examine the reservation state at each RSVP hop along the way. That tells it whether the RSVP state is set up correctly, whether there's a black hole along the way causing RSVP message losses, or whether there are non-RSVP clouds (and where they are) that might be causing the performance problem 🕵️‍♀️

5.6. Crossing "Legacy" RSVP Routers 🧓

This diagnosis facility was developed and added to RSVP after a bunch of RSVP implementations were already out there, so it's possible, or even likely, that you'll run into one or more RSVP-capable nodes that don't understand diagnostic messages and just drop them 🙃. When that happens, the invoking client gets no response to its requests 😶

One way to get around these "legacy" RSVP nodes is to run RSVP diagnosis repeatedly, guided by info from traceroute (or mtrace, if it's multicast) 🧭. When an RSVP diagnostic query times out (see the next section), you can first use traceroute to get the list of nodes along the path. Then gradually increase the value of the Max-RSVP-hops field in the DREQ message, starting from a low value, until you no longer get a response 📈. After that, you can try RSVP diagnosis again starting with the first node after the unresponsive one (the one that's further upstream towards the sender) 💖

There are two problems with the method above in the case of unicast sessions 🙅‍♀️. Both are related to the fact that traceroute info gives the path from the requester to the sender. The first problem is that the LAST-HOP might not be on the path from the requester to the sender. In that case, we can only get info from the portion of the path from the LAST-HOP to the sender that intersects with the path from the requester to the sender. If routers that aren't on the intersection of the two paths don't have PATH state for the session being diagnosed, they'll reply with R-error=0x01 🥺. The requester can work around this by sending a DREQ to every router on the path (from itself to the sender) until it reaches the first router that belongs to the path from the sender to the LAST-HOP 🛤️

The second problem is that traceroute gives the path from the requester to the sender, which, because of routing asymmetries, might be different from the path the traffic from the sender to the LAST-HOP uses 🔀. There's (at least) one case where this asymmetry will make the diagnosis fail, and here it is 👇

                             Downstream Path                Sender
                             __         __            __       __
Receiver             +------|  |<------|  |<-- ...---|  |-----|  |
   __          __   /       |__|       |__|          |__|     |__|
  |  |--....--|X |_/                    ^
  |__|        |__| \     Router B       |
             Black  \        __         |
             Hole    +----->|  |---->---+
                            |__| Upstream Path

                          Router A

                          Figure 2

Here, the first hop upstream of the black hole is different on the upstream path and the downstream path 😱. Traceroute will show router A as the previous hop (instead of router B, which is the right one). Sending a DREQ to router A will get A responding with R-error 0x01 (No PATH State) 💔. If the two paths converge again, the requester can use the solution proposed above to get any (partial) info from the rest of the path ✨

We don't have any complete solutions for the problematic scenarios described here yet 🥲

6. Comments on Diagnostic Client Implementation ✨

okay so the big design vibe here is that RSVP nodes should not hold more state than they absolutely need 💅 so RSVP nodes are only responsible for forwarding Diagnostic messages and filling in DIAG_RESPONSE objects 🎀. Any extra diagnostic functionality gets handled by the diagnostic clients. And if the diagnosis is kicked off from a third-party host, that host doesn't need to be running an RSVP daemon 🧚 iconic, right? Here's the basic stuff a diagnostic client daemon should be doing:

  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 DIAG_SELECT list. Then create a DREQ message and send it to the LAST-HOP RSVP node using a raw IP message with protocol number 46 (RSVP) 📮 If the user specified that the response should be sent hop-by-hop, include an empty ROUTE object in the DREQ message sent. Set the Path_MTU to the smaller of the user request and the MTU of the link through which the DREQ will be sent.

The port of the UDP socket on which the Diagnostic Client is listening for replies should be included in the Requester FILTER_SPEC object.

  1. Set a retransmission timer while waiting for the reply (one or more DREP messages) ⏰ Listen to the specified UDP port for responses from the LAST-HOP RSVP node.

The LAST-HOP RSVP node, upon receiving DREP messages, sends them to the Diagnostic Client as UDP packets, using the port supplied in the Requester FILTER_SPEC object.

  1. Upon receiving a DREP message to an outstanding diagnostic request, the client should clear the retransmission timer and check whether the reply contains the complete result of the requested diagnosis. If it does, the client should pass the result up to the invoking entity immediately ✨
  2. 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, similar to the IP packet reassembly timer. If that timer goes off before all the fragments arrive, the client should pass the partial result to the invoking entity.
  3. Use retransmission and reassembly timers to gracefully handle packet losses and reply fragment scenarios 🫶

In the absence of a 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 get the list of hops along the path segment to be diagnosed. Then it should perform an iteration of diagnosis with increasing hop count, as suggested in Section 5.6, so it can cross RSVP-capable but diagnosis-incapable nodes 🦋

  1. If all of the above efforts fail, the client must notify the invoking entity 😭

7. Security Considerations 🔥

RSVP Diagnostics, like any other diagnostic tool, can be a security threat, since it can reveal possibly sensitive RSVP state information to unwanted third parties. This is a real concern, bestie, so take it seriously 💀

We feel that the threat is minimal. As explained in the Introduction, Diagnostics messages produce no side-effects, so they cannot change RSVP state in the nodes. In this respect, RSVP Diagnostics is less of 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 it is a security threat. So there's an off switch if you need one 🔒

8. Acknowledgments 🫶

The idea of developing a diagnostic facility for RSVP was first suggested by Mark Handley of ACIRI, so he gets the first shoutout 🎉 Many thanks to Lee Breslau of AT&T Labs and John Krawczyk of Nortel Networks for their valuable comments on the first draft of this memo. Lee Breslau, Bob Braden, and John Krawczyk contributed further comments after the March 1996 IETF. Steven Berson provided valuable comments on various drafts of the memo. Tim Gleeson contributed an extensive list of editorial comments. We would also like to acknowledge Intel for providing a research grant as partial support for this work. Subramaniam Vincent did most of this work while a graduate research assistant at the USC Information Sciences Institute (ISI) 👑

9. References 📚

  • [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997.
  • [RSVPTUN] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.

10. Authors' Addresses 🎀

Andreas Terzis
UCLA
4677 Boelter Hall
Los Angeles, CA 90095

Phone:    310-267-2190
EMail:    terzis@cs.ucla.edu


Bob Braden
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292

Phone:    310 822-1511
EMail:    braden@isi.edu


Subramaniam Vincent
Cisco Systems
275, E Tasman Drive, MS SJC04/2/1
San Jose, CA 95134

Phone:    408 525 3474
EMail:    svincent@cisco.com


Lixia Zhang
UCLA
4531G Boelter Hall
Los Angeles, CA  90095

Phone:    310-825-2695
EMail:    lixia@cs.ucla.edu

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. 💜

📦 where this page comes from