RSVP Diagnostic Messages
Extracted elements (26)
Additional diagnostic logic (reassembly, retransmission, iterative hop-count expansion) is placed in diagnostic clients rather than RSVP nodes, following the principle that network nodes should not hold more state than necessary. Third-party hosts running the diagnostic client are not required to run an RSVP daemon.
Application-layer fragmentation is used instead of IP fragmentation to avoid reassembly overhead at every hop when DREP messages are returned hop-by-hop. The requester sets a Path MTU carried in every DREQ; intermediate nodes shrink it and trigger semantic fragmentation when the accumulated message would exceed it.
Diagnostic messages are explicitly designed to produce no side-effects and not change any RSVP state at nodes or hosts. This makes them safer than SNMP for state inspection, and distinguishes them from error messages which convey only failure-point information.
DREQ packets can only be forwarded after RSVP path state has been set up. If no path state exists, the user must resort to traceroute or mtrace to diagnose whether unicast or multicast routing is functioning correctly.
Firewalls may block direct DREP delivery. Including an empty ROUTE object in a DREQ causes DREP packets to traverse the same firewall holes used by other RSVP messages via hop-by-hop reverse routing. When a third-party requester is separated from LAST-HOP by a firewall, no current solution is known other than relocating LAST-HOP to the requester's side of the firewall.
Legacy RSVP routers that predate the diagnostic facility will silently drop DREQ messages. The recommended workaround is to use traceroute or mtrace to enumerate hops, then issue repeated DREQ queries with increasing Max-RSVP-hops values to isolate and bypass the unresponsive node.
A DREQ message MUST always consist of a single unfragmented IP datagram. One DREQ may generate multiple DREP packets, each carrying a fragment of the total response, reassembled by the requester.
All diagnostic packets MUST be forwarded via unicast only, to avoid packet implosion or explosion at multicast branch points.
Each intermediate RSVP node must check the Path MTU in a DREQ; if the specified MTU exceeds the MTU of the incoming interface (toward the sender), the node reduces the Path MTU field to the smaller value before forwarding.
If an error condition prevents a DREP from being forwarded further, the message is simply dropped. If an error condition prevents a DREQ from being forwarded further, the node must convert the DREQ to a DREP and return it to the requester address.
If an RSVP-capable node other than the LAST-HOP receives a DREQ containing no DIAG_RESPONSE objects and a zero Fragment Offset, it should forward the DREQ toward the LAST-HOP without processing, because such nodes are downstream of LAST-HOP where no state should be collected.
The MF flag MUST be set to zero in all DREQ messages. It MUST be set to one in all DREP packets carrying partial results returned by intermediate nodes due to the MTU limit. When the ending node converts a DREQ to a DREP, the MF flag must remain zero.
When a ROUTE object is present, a node receiving a DREP must decrement R-pointer by one address length, recompute the checksum, and forward the DREP to the address now pointed to by R-pointer. If a non-LAST-HOP node receives a DREP where R-pointer equals zero, it must send it directly to the requester.
In the absence of a DIAG_SELECT object, each node appends a default DIAG_RESPONSE containing SENDER_TSPEC, FILTER_SPEC, FLOWSPEC, and STYLE objects. Reservation-state objects (FLOWSPEC, FILTER_SPEC, STYLE) are omitted if no reservation state exists for the session.
The Next-Hop RSVP_HOP object in a DREQ carries the LIH of the interface through which the DREQ should be received at the upstream node, updated hop-by-hop. It serves the same role as in RESV messages: distinguishing logical interfaces and handling routing asymmetries and non-RSVP clouds.
The optional TUNNEL object is inserted into DIAG_RESPONSE when a DREQ arrives at an RSVP node acting as a tunnel exit point. It provides the mapping between the end-to-end RSVP session and the tunnel RSVP session, enabling a client to issue a separate diagnostic query for the tunnel segment.
The R-error field in DIAG_RESPONSE is a 3-bit flags field indicating per-hop error conditions: 0x00 (no error), 0x01 (No PATH state), 0x02 (packet too big), 0x04 (ROUTE object too big). Multiple bits may be set simultaneously.
Two new RSVP message types are introduced: DREQ (Diagnostic Request, Type=8) and DREP (Diagnostic Reply, Type=9). A DREQ travels hop-by-hop from the LAST-HOP node toward the sender, collecting per-hop RSVP state; the ending node converts it to a DREP and returns the completed response to the requester.
Processing of Diagnostic messages can be administratively disabled on individual RSVP nodes if the potential for information disclosure is deemed an unacceptable security risk in a given deployment.
RSVP Diagnostics can disclose sensitive RSVP state information—including flowspecs, timer values, and reservation-merge topology—to unauthorized third parties. The risk is considered lower than SNMP because diagnostic messages cannot modify RSVP state.
DREQ processing follows a 10-step algorithm: (1) create DIAG_RESPONSE with D-TTL computed from IP TTL vs Send_TTL; (2) set arrival time and interface addresses; (3) increment RSVP-hop-count; (4) set R-error=0x01 if no PATH state; (5) populate response objects per DIAG_SELECT or defaults; (6) update Path MTU to min of current value and incoming interface MTU; (7) goto Send_DREP if augmented size exceeds Path MTU; (8) check termination; (9) forward DREQ updating ROUTE and DIAG_RESPONSE list; (10) convert to DREP and return.
The Send_DREP sub-procedure handles oversized messages: SD1 copies DREQ to DREP and trims accumulated DIAG_RESPONSE objects from DREQ, adjusting Fragment Offset; SD2 sets MF=1 and sends DREP toward requester via ROUTE or direct; SD3 returns to main step 8 if trimmed DREQ now fits Path MTU; SD4 trims ROUTE object and sets R-error=0x04 if DREQ still exceeds Path MTU.
The DIAG_SELECT object (Class=33, C-Type=1) carries a list of [Class, C-Type] pairs packed two per 32-bit word; a C-Type value of zero is a wildcard matching any C-Type for the given class. If the pair count is odd, the final two octets must be zero.
The IPv4 DIAG_RESPONSE object (Class=32, C-Type=1) encodes: DREQ Arrival Time (32-bit NTP timestamp, middle 32 bits of 64-bit NTP form), Incoming Interface Address, Outgoing Interface Address, Previous-RSVP-Hop Router Address, D-TTL (8 bits), M flag (1 bit), R-error (3 bits), K refresh multiplier (4 bits), Timer value (16 bits), an optional TUNNEL object, and variable-length response objects.
The IPv4 DIAGNOSTIC object (Class=30, C-Type=1) encodes: Max-RSVP-hops (8 bits), RSVP-hop-count (8 bits), MF flag (1 bit), Request-ID (32 bits), Path MTU (16 bits), Fragment Offset (16 bits), LAST-HOP Address (32 bits), an embedded SENDER_TEMPLATE object, and an embedded Requester FILTER_SPEC object. IPv6 uses C-Type=2 with 128-bit addresses.
The IPv4 ROUTE object (Class=31, C-Type=1) contains a reserved field, an R-pointer byte indicating the current reply-route position, and a variable-length RSVP Node List of IPv4 addresses. IPv6 uses C-Type=2 with 128-bit addresses. An empty ROUTE object has an empty node list and R-pointer equal to zero.