As per Relevance of the word diagnostic, we have this rfc below:
Network Working Group A.
Request for Comments: 2745
Category: Standards Track B.
S.
Cisco
L.
January 2000
RSVP Diagnostic
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document specifies the RSVP diagnostic facility, which allows
user to collect information about the RSVP state along a path.
specification describes the functionality, diagnostic
formats, and processing rules
1.
In the basic RSVP protocol [RSVP], error messages are the only
for an end host to receive feedback regarding a failure in setting
either path state or reservation state. An error message
back only the information from the failed point, without
information about the state at other hops before or after
failure. In the absence of failures, a host receives no
regarding the details of a reservation that has been put in place
such as whether, or where, or how, its own reservation request
being merged with that of others. Such missing information can
highly desirable for debugging purposes, or for network
management in general
Terzis, et al. Standards Track [Page 1]
RFC 2745 RSVP Diagnostic Messages January 2000
This document specifies the RSVP diagnostic facility, which
designed to fill this information gap. The diagnostic facility
be used to collect and report RSVP state information along the
from a receiver to a specific sender. It uses Diagnostic
that are independent of other RSVP control messages and produce
side-effects; that is, they do not change any RSVP state at
nodes or hosts. Similarly, they provide not an error report
rather a collection of requested RSVP state information
The RSVP diagnostic facility was designed with the following goals
- To collect RSVP state information from every RSVP-capable
along a path defined by path state, either for an
reservation or before a reservation request is made.
specifically, we want to be able to collect information
flowspecs, refresh timer values, and reservation merging at
hop along the path
- To collect the IP hop count across each non-RSVP cloud
- To avoid diagnostic packet implosion or explosion
The following is specifically identified as a non-goal
- Checking the resource availability along a path.
functionality may be useful for future reservation requests,
it would require modifications to existing admission
modules that is beyond the scope of RSVP
2.
The diagnostic facility introduces two new RSVP message types
Diagnostic Request (DREQ) and Diagnostic Reply (DREP). A
message can be originated by a client in a "requester" host,
may or may not be a participant of the RSVP session to be diagnosed
A client in the requester host invokes the RSVP diagnostic
by generating a DREQ packet and sending it towards the LAST-HOP node
which should be on the RSVP path to be diagnosed. This DREQ
specifies the RSVP session and a sender host for that session
Starting from the LAST-HOP, the DREQ packet collects
hop-by-hop as it is forwarded towards the sender (see Figure 1),
until it reaches the ending node. Specifically, each RSVP-
hop adds to the DREQ message a response (DIAG_RESPONSE)
containing local RSVP state for the specified RSVP session
Terzis, et al. Standards Track [Page 2]
RFC 2745 RSVP Diagnostic Messages January 2000
When the DREQ packet reaches the ending node, the message type
changed to Diagnostic Reply (DREP) and the completed response is
to the original requester node. Partial responses may also
returned before the DREQ packet reaches the ending node if an
condition along the path, such as "no path state", prevents
forwarding of the DREQ packet. To avoid packet implosion
explosion, all diagnostic packets are forwarded via unicast only
Thus, there are generally three nodes (hosts and/or routers)
in performing the diagnostic function: the requester node,
starting node, and the ending node, as shown in Figure 1. It
possible that the client invoking the diagnosis function may
directly on the starting node, in which case that the first two
are the same. The starting node is named "LAST-HOP", meaning
last-hop of the path segment to be diagnosed. The LAST-HOP node
be either a receiver node or an intermediate node along the path
The ending node is usually the specified sender host. However,
client can limit the length of the path segment to be diagnosed
specifying a hop-count limit in the DREQ message
LAST-HOP
Receiver node node
__ __ __ __ __
| |---------| |------>| |--> ...-->| |--> ...---->| |
|__| |__| DREQ |__| DREQ |__| DREQ |__|
^ . |
| . |
| DREQ . DREP |
| . |
_|_ DREP V
Requester | | <------------------------------------
(client) |___|
Figure 1
DREP packets can be unicast from the ending node back to
requester either directly or hop-by-hop along the reverse of the
taken by the DREQ message to the LAST-HOP, and thence to
requester. The direct return is faster and more efficient, but
hop-by-hop reverse-path route may be the only choice if the
have to cross firewalls. Hop-by-hop return is accomplished using
optional ROUTE object, which is built incrementally to contain a
of node addresses that the DREQ packet has passed through. The
object is then used in reverse as a source route to forward the
hop-by-hop back to the LAST-HOP node
Terzis, et al. Standards Track [Page 3]
RFC 2745 RSVP Diagnostic Messages January 2000
A DREQ message always consists of a single unfragmented IP datagram
On the other hand, one DREQ message can generate multiple
packets, each containing a fragment of the total DREQ message.
the path consists of many hops, the total length of a DREP
will exceed the MTU size before reaching the ending node; thus,
message has to be fragmented. Relying on IP fragmentation
reassembly, however, can be problematic, especially when
messages are returned to the requester hop-by-hop, in which
fragmentation/reassembly would have to be performed at every hop.
avoid such excessive overhead, we let the requester define a
path MTU size that is carried in every DREQ packet. If
intermediate node finds that the default MTU size is bigger than
MTU of the incoming interface, it reduces the default MTU size to
MTU size of the incoming interface. If an intermediate node
that a DREQ packet size is larger than the default MTU size,
returns to the requester (in either manner described above) a
fragment containing accumulated responses. It then removes
responses from the DREQ and continues to forward it. The
node can reassemble the resulting DREP fragments into a complete
message
When discussing diagnostic packet handling, this document
direction terminology that is consistent with the RSVP
specification [RSVP], relative to the direction of data packet flow
Thus, a DREQ packet enters a node through an "outgoing interface"
is forwarded towards the sender through an "incoming interface",
because DREQ packets travel in the reverse direction to the
flow
Notice that DREQ packets can be forwarded only after the RSVP
state has been set up. If no path state exists, one may resort
the traceroute or mtrace facility to examine whether
unicast/multicast routing is working correctly
3. Diagnostic Packet
Like other RSVP messages, DREQ and DREP messages consist of an
Common Header followed by a variable set of typed RSVP data objects
The following sequence must be used
Terzis, et al. Standards Track [Page 4]
RFC 2745 RSVP Diagnostic Messages January 2000
+-----------------------------------+
| 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 for which the
information is being collected. We describe each of the other parts
3.1. RSVP Message Common
The RSVP message common header is defined in [RSVP]. The
specific exceptions and extensions are needed for DREP and DREQ
Type field: define
Type = 8: DREQ Diagnostic
Type = 9: DREP Diagnostic
RSVP length
If this is a DREP message and the MF flag in the DIAGNOSTIC
(see below) is set, this field indicates the length of this
DREP fragment rather than the total length of the complete
reply message (which cannot generally be known in advance).
3.2. Next-Hop RSVP_HOP
This RSVP_HOP object carries the LIH of the interface through
the DREQ should be received at the upstream node. This object
updated hop-by hop. It is used for the same reasons that a
message contains an RSVP_HOP object: to distinguish
interfaces and avoid problems caused by routing asymmetries and non
RSVP clouds
Terzis, et al. Standards Track [Page 5]
RFC 2745 RSVP Diagnostic Messages January 2000
While the IP address is not really used during DREQ processing,
consistency with the use of the RSVP_HOP object in other
messages, the IP address in the RSVP_HOP object to contain
address of the interface through which the DREQ was sent
3.3. DIAGNOSTIC
A DIAGNOSTIC object contains the common diagnostic
information in both DREQ and DREP messages
o 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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here all IP addresses use the 4 byte IPv4 format, both explicitly
the LAST-HOP Address and by using the IPv4 forms of the
FILTER_SPEC and RSVP_HOP objects
o IPv6 DIAGNOSTIC object: Class = 30, C-Type = 2
The format is the same, except all explicit and embedded IP
are 16 byte IPv6 addresses
The fields are as follows
Max-RSVP-
An octet specifying the maximum number of RSVP hops over
information will be collected. If an error condition in
middle of the path prevents the DREQ packet from reaching
specified ending node, the Max-RSVP-hops field may be used
perform an expanding-length search to reach the point just
Terzis, et al. Standards Track [Page 6]
RFC 2745 RSVP Diagnostic Messages January 2000
the problem. If this value is 1, the starting node and the
node of the query will be the same. If it is zero, there is
hop limit
RSVP-hop-
Records the number of RSVP hops that have been traversed so far
If the starting and ending nodes are the same, this value will
1 in the resulting DREP message
Fragment
Indicates where this DREP fragment belongs in the complete
message, measured in octets. The first fragment has offset zero
Fragment Offset is used also to determine if a DREQ
containing zero DIAG_RESPONSE objects should be processed at
RSVP capable node
MF
Flag means "more fragments". It must be set to zero (0) in
DREQ messages. It must be set to one (1) in all DREP packets
carry partial results and are returned by intermediate nodes
to the MTU limit. When the DREQ message is converted to a
message in the ending node, the MF flag must remain zero
Request
Identifies an individual DREQ message and the corresponding
message (or all the fragments of the reply message).
One possible way to define the Request ID would use 16 bits
specify the ID of the process making the query and 16 bits
distinguish different queries from this process
Path
Specifies a default MTU size in octets for DREP and DREQ messages
This value should not be smaller than the size of the "base"
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 (
below). The assumption made here is that a diagnostic packet
this size can always be forwarded without IP fragmentation
Terzis, et al. Standards Track [Page 7]
RFC 2745 RSVP Diagnostic Messages January 2000
LAST-HOP
The IP address of the LAST-HOP node. The DREQ message
collecting information at this node and proceeds toward
sender
SENDER_TEMPLATE
This IPv4/IPv6 SENDER_TEMPLATE object contains the IP address
the port of a sender for the session being diagnosed. The
packet is forwarded hop-by-hop towards this address
Requester FILTER_SPEC
This IPv4/IPv6 FILTER_SPEC object contains the IP address and
port from which the request originated and to which the
message(s) should be sent
3.4. DIAG_SELECT
o DIAG_SELECT Class = 33, C-Type = 1.
A Diagnostic message may optionally contain a DIAG_SELECT object
specify which specific RSVP objects should be reported in
DIAG_RESPONSE object. In the absence of a DIAG_SELECT object,
DIAG_RESPONSE object added by the node will contain a default set
object types (see DIAG_RESPONSE object below).
The DIAG_SELECT object contains a list of [Class, C-type] pairs,
the following format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| class | C-Type | class | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| class | C-Type | class | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a DIAG_SELECT object is included in a DREQ message, each
node along the path will add a DIAG_RESPONSE object
response objects (see below) whose classes and C-Types match
in the DIAG_SELECT list (and are from matching path and
state). A C-type octet of zero is a 'wildcard', matching any C-
associated with the associated class
Terzis, et al. Standards Track [Page 8]
RFC 2745 RSVP Diagnostic Messages January 2000
Depending on the type of objects requested, a node can find
associated information in the path or reservation state stored
the session described in the SESSION object. Specifically
information for the RSVP_HOP,SENDER_TEMPLATE, SENDER_TSPEC,
objects can be extracted from the node's path state,
information for the FLOWSPEC, FILTER_SPEC, CONFIRM, STYLE and
objects can be found in the node's reservation state (if existent).
If the number of [Class, C-Type] pairs is odd, the last two octets
the DIAG_SELECT object must be zero. A maximum DIAG_SELECT object
one that contains the [Class, C-type] pairs for all the RSVP
that can be requested in a Diagnostic query
3.5. ROUTE
A diagnostic message may contain a ROUTE object, which is used
record the route of the DREQ message and as a source route
returning the DREP message(s) hop-by-hop
o IPv4 ROUTE object: Class = 31, C-Type = 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | R-pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ RSVP Node List |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message signifies how the reply should be returned. If it
not exist in the DREQ packet then DREP packets should be sent to
requester directly. If it does exist, DREP packets must be
hop-by-hop along the reverse path to the LAST-HOP node and thence
the requester node
An empty ROUTE object is one that has an empty RSVP Node list and R
pointer is equal to zero
RSVP Node
A list of RSVP node IPv4 addresses. The number of addresses
this list can be computed from the object size
R-
Used in DREP messages only (see Section 4.2 for details), but
is incremented as each hop adds its incoming interface address
the ROUTE object
Terzis, et al. Standards Track [Page 9]
RFC 2745 RSVP Diagnostic Messages January 2000
o IPv6 ROUTE object: Class = 31, C-Type = 2
The same, except RSVP Node List contains IPv6 addresses
In a DREQ message, RSVP Node List specifies all RSVP hops between
LAST-HOP address specified in the DIAGNOSTIC object, and the
RSVP node the DREQ message has visited. In a DREP message, RSVP
List specifies all RSVP hops between the LAST-HOP and the node
returns this DREP message
3.6. DIAG_RESPONSE
Each RSVP node attaches a DIAG_RESPONSE object to each DREQ
it receives, before forwarding the message. The DIAG_RESPONSE
contains the state to be reported for this node. It has a fixed
format header and then a variable list of RSVP state objects,
"response objects".
o 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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o IPv6 DIAG_RESPONSE object: Class = 32, C-Type = 2.
This object has the same format, except that all explicit
embedded IP addresses are IPv6 addresses
The fields are as follows
Terzis, et al. Standards Track [Page 10]
RFC 2745 RSVP Diagnostic Messages January 2000
DREQ Arrival
A 32-bit NTP timestamp specifying the time the DREQ
arrived at this node. The 32-bit form of an NTP
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
fractional part
Incoming Interface
Specifies the IP address of the interface on which messages
the sender are expected to arrive, or 0 if unknown
Outgoing Interface
Specifies the IP address of the interface through which the
message arrived and to which messages from the given sender
for the specified session address flow, or 0 if unknown
Previous-RSVP-Hop Router
Specifies the IP address from which this node receives RSVP
messages for this source, or 0 if unknown. This is also
interface to which the DREQ will be forwarded
D-
The number of IP hops this DREQ message traveled from the down
stream RSVP node to the current node
M
A single-bit flag which indicates whether the
described by the response objects is merged with reservations
other down-stream interfaces when being forwarded upstream
R-
A 3-bit field that indicates error conditions at a node.
defined values are
0x00: no
0x01: No PATH
0x02: packet too
0x04: ROUTE object too
Terzis, et al. Standards Track [Page 11]
RFC 2745 RSVP Diagnostic Messages January 2000
The refresh timer multiple (defined in [RSVP]).
Timer
The local refresh timer value in seconds
The set of response objects to be included at the end of
DIAG_RESPONSE object is determined by a DIAG_SELECT object, if one
present. If no DIAG_SELECT object is present, the response
belong to the default list of classes
SENDER_TSPEC object FILTER_SPEC object FLOWSPEC
STYLE
Any C-Type present in the local RSVP state will be used.
response objects may be in any order but they must all be at the
of the DIAG_RESPONSE object
A default DIAG_RESPONSE object is one containing the default list
classes described above
3.7. TUNNEL
The optional TUNNEL object should be inserted when a DREQ
arrives at an RSVP node that acts as a tunnel exit point
The TUNNEL object provides the mapping between the end-to-end
session that is being diagnosed and the RSVP session over the tunnel
This mapping information allows the diagnosis client to
diagnosis over the involved tunnel session, by invoking a
Diagnostic query for the corresponding Tunnel Session and
Sender. Keep in mind, however, that multiple end-to-end sessions
all map to one pre-configured tunnel session that may have
different parameter settings
The tunnel object is defined in the RSVP Tunnel
[RSVPTUN].
4. Diagnostic Packet Forwarding
4.1. DREQ Packet
DREQ messages are forwarded hop-by-hop via unicast from the LAST-
address to the Sender address, as specified in the DIAGNOSTIC object
If an RSVP capable node, other than the LAST-HOP node, receives
DREQ message that contains no DIAG_RESPONSE objects and has a
Terzis, et al. Standards Track [Page 12]
RFC 2745 RSVP Diagnostic Messages January 2000
Fragment Offset, the node should forward the DREQ packet towards
LAST-HOP without doing any of the processing mentioned below.
reason is that such conditions apply only for nodes downstream of
LAST-HOP where no information should be collected
Processing begins when a DREQ message, DREQ_in, arrives at a node
1. Create a new DIAG_RESPONSE object. Compute the IP hop
from the previous RSVP hop. This is done by subtracting
value of the TTL value in the IP header from Send_TTL in
RSVP common header. Save the result in the D-TTL field of
DIAG_RESPONSE object
2. Set the DREQ Arrival Time and the Outgoing Interface
in the DIAG_RESPONSE object. If this node is the LAST-HOP
then the Out- going Interface Address field in
DIAG_RESPONSE object contains the following value depending
the session being diagnosed
* If the session in question is a unicast session, then
Out-going Interface Address field contains the address
the interface LAST-HOP uses to send PATH messages and
to the receiver specified by the session address
* Otherwise, if it is a multicast session and there is
least one receiver for this session, LAST_HOP should use
address of one of local interfaces used to reach one of
receivers
* Otherwise Outgoing Interface Address should be zero
3. Increment the RSVP-hop-count field in the DIAGNOSTIC
object by one
4. If no PATH state exists for the specified session, set R-
= 0x01 (No PATH state) and goto step 7.
5. Set the rest of the fields in the DIAG_RESPONSE object.
DREQ_in contains a DIAG_SELECT object, the response
classes are those specified in the DIAG_SELECT; otherwise
they are SENDER_TSPEC, STYLE, and FLOWSPEC objects. If
reservation state exists for the specified RSVP session,
DIAG_RESPONSE object will contain no FLOWSPEC, FILTER_SPEC
STYLE object. If neither PATH nor reservation state exists
the specified RSVP session, then no response objects will
appended to the DIAG_RESPONSE object
Terzis, et al. Standards Track [Page 13]
RFC 2745 RSVP Diagnostic Messages January 2000
6. If RSVP-hop-count is less than Max-RSVP-hops and this node
not the sender, then the DREQ is eligible for forwarding;
the Path MTU to the min of the Path MTU and the MTU size
the incoming interface for the sender being diagnosed
7. If the size of DREQ_in plus the size of the new DIAG_
object plus the size of an IP address (if a ROUTE
exists and R-error= 0) is larger than Path MTU, then the
diagnostic message will be too large to be forwarded
returned without fragmentation; set the "packet too big
(0x02) error bit in DIAG_RESPONSE and goto Step SD1
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
sender, then the DREQ cannot be forwarded further; goto
10.
9. Forward the DREQ towards the sender, as follows. If a
object exists, append the "Incoming Interface Address" to
end of the ROUTE object and increment R-Pointer by one
Update the Next-Hop RSVP_HOP object, append the
DIAG_RESPONSE object to the list of DIAG_RESPONSE object,
update the message length field in the RSVP common
accordingly. Finally, recompute the checksum, forward DREQ_
to the next hop towards the sender, and return
10. Turn the DREQ into a DREP and return to the requester,
follows. Append the DIAG_RESPONSE object to the end
DREQ_in and update the packet length. If a ROUTE object
present in the message, decrement the R-pointer and set
address to the last address in the ROUTE object, otherwise
target address to the requester address. Change the Type
in the Common header from DREQ to DREP. Finally,
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 is entered if the DREQ message augmented with the
DIAG_RESPONSE object is too large to be forwarded towards the
or, if it is not eligible for forwarding, too large to be returned
a DREP
SD1. Make a copy of DREQ_in and change the message type field
DREQ to DREP. Trim all DIAG_RESPONSE objects from DREQ_in
adjust the Fragment Offset. The DREP message contains
DIAG_RESPONSE objects accumulated by prior nodes
Terzis, et al. Standards Track [Page 14]
RFC 2745 RSVP Diagnostic Messages January 2000
SD2. Send the DREP message towards the requester, as follows. If
ROUTE object is present in the DREP message, decrement the R
pointer and set target address to the last address in the
object, otherwise set target address to the requester address
Set the MF bit, recompute the checksum and send the DREP
back to the target address
SD3. If the reduced size of DREQ_in plus the size of DIAG_
plus the size of an IP address (if a ROUTE object exists)
smaller than or equal to Path MTU, then return to Step 8 of
main DREQ processing sequence above
SD4. If a ROUTE object exists, replace the ROUTE object in DREQ_
with an empty ROUTE object and turn on the "ROUTE object
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
When a ROUTE object is present, DREP messages are forwarded hop-by
hop towards the requester, by reversing the route as listed in
ROUTE object. Otherwise, DREP messages are sent directly to
original requester
When a node receives a DREP message, it simply decreases R-pointer
one (address length), recomputes the checksum and forwards
message to the address pointed to by R-pointer in the route list.
a node, other than 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
to the requester
4.3. MTU Selection and
Because the DREQ message carries the allowed MTU size of
hops that the DREP messages will later traverse, this unique
allows easy semantic fragmentation as described above. Whenever
DREQ message approaches the size of Path MTU, it can be
before being forwarded again
When a requester sends a DREQ message, the Path MTU field in
DIAGNOSTIC object can be set to a configured default value. It
possible that the original Path MTU value is chosen larger than
actual MTU value along some portion of the path being traced
Therefore each intermediate RSVP node must check the MTU value
processing a DREQ message. If the specified MTU value is larger
Terzis, et al. Standards Track [Page 15]
RFC 2745 RSVP Diagnostic Messages January 2000
the MTU of the incoming interface (that the DREQ message will
forwarded to), the node changes the MTU value in the header to
smaller value
Whenever a DREQ message size becomes larger than the Path MTU value
an intermediate RSVP node makes a copy of the message, converts it
a DREP message to send back, and then trims off the partial
from the DREQ message. If in this case also the DREQ cannot
forwarded upstream due to a large ROUTE object, the "ROUTE object
big" is set and the ROUTE object is trimmed. As a result of the
object trimming, DREP(s) will come hop-by-hop up to this node
will then immediately be forwarded to the requester address
Even if the steps shown above are followed there are a few
where fragmentation at the IP layer will happen. For example, non
RSVP hops with smaller MTUs may exist before LAST-HOP is reached,
if the response is sent directly back to requester (as opposed to
by hop) the DREP may take a different route to the requester than
DREQ took from the requester. Another case is when there exists
link with MTU smaller than the minimum Path MTU value defined
Section 3.3.
4.4.
If an error condition prevents a DREP message from being
further, the message is simply dropped
If an error condition, such as lack of PATH state, prevents a
message from being forwarded further, the node must change
current message to DREP type and return it to the response address
5. Problem Diagnosis by Using RSVP Diagnostic
5.1. Across
Firewalls may cause problems in diagnostic message forwarding.
us look at two different cases
First, let us assume that the querier resides on a receiving host
the session to be examined. In this case, firewalls should
prevent the forwarding of the diagnostic messages in a hop-by-
manner, assuming that proper holes have been punched on the
to allow hop-by-hop forwarding of other RSVP messages. The
may start by not including a ROUTE object, which can give a
response delivery and reduced overhead at intermediate nodes
However if no response is received, the querier may resend the
message with a ROUTE object, specifying that a hop-by-hop
should be sent
Terzis, et al. Standards Track [Page 16]
RFC 2745 RSVP Diagnostic Messages January 2000
If the requester is a third party host and is separated from
LAST-HOP address by a firewall (either the requester is behind
firewall, or the LAST-HOP is a node behind a firewall, or both),
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
requester
5.2. Examination of RSVP
One can easily collect information about the current timer value
each RSVP hop along the way. This will be very helpful in
when the reservation state goes up and down frequently, to find
whether the state changes are due to improper setting of
values, or K values (when across lossy links), or frequent
changes
5.3. Discovering Non-RSVP
The D-TTL field in each DIAG_RESPONSE object shows the number
routing hops between adjacent RSVP nodes. Therefore any
greater than one indicates a non-RSVP cloud in between.
with the arrival timestamps (assuming NTP works), this value can
give some vague, though not necessarily accurate, indication of
big that cloud might be. One might also find out all
intermediate non-RSVP nodes by running either unicast or
trace route
5.4. Discovering Reservation
The flowspec value in a DIAG_RESPONSE object specifies the amount
resources being reserved for the data stream defined by the
spec in the same data block. When this value of
DIAG_RESPONSE objects differs, that is, a downstream node Rd has
smaller value than its immediate upstream node Ru, it indicates
merge of reservation with RSVP request(s) from other down
interface(s) at Rd. Further, in case of SE style reservation,
can examine how the different SE scopes get merged at each hop
In particular, if a receiver sends a DREQ message before sending
own reservation, it can discover (1) how many RSVP hops there
along the path between the specified sender and itself, (2) how
of the hops already have some reservation by other receivers, and (3)
possibly a rough prediction of how its reservation request might
merged with other existing ones
Terzis, et al. Standards Track [Page 17]
RFC 2745 RSVP Diagnostic Messages January 2000
5.5. Error
In addition to examining the state of a working reservation,
diagnostic messages are more likely to be invoked when things are
working correctly. For example, a receiver has reserved an
pipe for a specified incoming data stream, yet the observed delay
loss ratio is much higher than expected. In this case the
can use the diagnostic facility to examine the reservation state
each RSVP hop along the way to find out whether the RSVP state is
up correctly, whether there is any black-hole along the way
caused RSVP message losses, or whether there are non-RSVP clouds,
where they are, that may have caused the performance problem
5.6. Crossing "Legacy" RSVP
Since this diagnosis facility was developed and added to RSVP after
number of RSVP implementations were in place, it is possible, or
likely, that when performing RSVP diagnosis, one may encounter one
more RSVP-capable nodes that do not understand diagnostic
and drop them. When this happens, the invoking client will get
response from its requests
One way to by-pass such "legacy" RSVP nodes is to perform
diagnosis repeatedly, guided by information from traceroute,
mtrace in case of multicast. When an RSVP diagnostic query times
(see next section), one may first use traceroute to get the list
nodes along the path, and then gradually increase the value of Max
RSVP-hops field in the DREQ message, starting from a low value
one no longer receives a response. One can then try RSVP
again by starting with the first node (which is further
towards the sender) after the unresponding one
There are two problem with the method mentioned above in the case
unicast sessions. Both problems are related to the fact
traceroute information provides the path from the requester to
sender. The first problem is that the LAST-HOP may not be on the
from the requester to the sender. In this case we can get
only from the portion of the path from the LAST-HOP to the
which intersects with the path from the requester to the sender.
routers that are not on the intersection of the two paths don't
PATH state for the session being diagnosed then they will reply
R-error=0x01. The requester can overcome this problem by sending
DREQ to every router on the path (from itself to the sender) until
reaches the first router that belongs to the path from the sender
the LAST-HOP
Terzis, et al. Standards Track [Page 18]
RFC 2745 RSVP Diagnostic Messages January 2000
The second problem is that traceroute provides the path from
requester to the sender which, due to routing asymmetries, may
different than the path traffic from the sender to the LAST-HOP uses
There is (at least) one case where this asymmetry will cause
diagnosis to fail. We present this case below
Downstream Path
__ __ __ __
Receiver +------| |<------| |<-- ...---| |-----| |
__ __ / |__| |__| |__| |__|
| |--....--|X |_/ ^
|__| |__| \ Router B |
Black \ __ |
Hole +----->| |---->---+
|__| Upstream
Router
Figure 2
Here the first hop upstream of the black hole is different on
upstream path and the downstream path. Traceroute will
router A as the previous hop (instead of router B which is the
one). Sending a DREQ to router A will result in A responding with R
error 0x01 (No PATH State). If the two paths converge again then
requester can use the solution proposed above to get any (partial
information from the rest of the path
We don't have, for the moment, any complete solutions for
problematic scenarios described here
6. Comments on Diagnostic Client Implementation
Following the design principle that nodes in the network should
hold more than necessary state, RSVP nodes are responsible only
forwarding Diagnostic messages and filling DIAG_RESPONSE objects
Additional diagnostic functionality should be carried out by
diagnostic clients. Furthermore, if the diagnostic function
invoked from a third-party host, we should not require that host
running an RSVP daemon to perform the function. Below we sketch
the basic functions that a diagnostic client daemon should carry out
1. Take input from the user about the session to be diagnosed,
last-hop and the sender address, the Max-RSVP-hops,
possibly the DIAG_SELECT list, create a DREQ message and
to the LAST-HOP RSVP node using raw IP message with
number 46 (RSVP). If the user specified that the
should be sent hop-by-hop include an empty ROUTE object to
Terzis, et al. Standards Track [Page 19]
RFC 2745 RSVP Diagnostic Messages January 2000
DREQ message sent. Set the Path_MTU to the smaller of the
request and the MTU of the link through which the DREQ will
sent
The port of the UDP socket on which the Diagnostic Client
listening for replies should be included in the
FILTER_SPEC object
2. Set a retransmission timer, waiting for the reply (one or
DREP messages). Listen to the specified UDP port for
from the LAST-HOP RSVP node
The LAST-HOP RSVP node, upon receiving DREP messages,
them to the Diagnostic Client as UDP packets, using the
supplied in the Requester FILTER_SPEC object
3. Upon receiving a DREP message to an outstanding
request, the client should clear the retransmission timer
check to see if the reply contains the complete result of
requested diagnosis. If so, it should pass the result up
the invoking entity immediately
4. Reassemble DREP fragments. If the first reply to
outstanding diagnostic request contains only a fragment of
expected result, the client should set up a reassembly timer
a way similar to IP packet reassembly timer. If the timer
off before all fragments arrive, the client should pass
partial result to the invoking entity
5. Use retransmission and reassembly timers to gracefully
packet losses and reply fragment scenarios
In the absence of response to the first diagnostic request,
client should retransmit the request a few times. If all
retransmissions also fail, the client should invoke
or mtrace to obtain the list of hops along the path segment
be diagnosed, and then perform an iteration of diagnosis
increasing hop count as suggested in Section 5.6 in order
cross RSVP-capable but diagnosis-incapable nodes
6. If all the above efforts fail, the client must notify
invoking entity
Terzis, et al. Standards Track [Page 20]
RFC 2745 RSVP Diagnostic Messages January 2000
7. Security
RSVP Diagnostics, as any other diagnostic tool, can be a
threat since it can reveal possibly sensitive RSVP state
to unwanted third parties
We feel that the threat is minimal, since as explained in
Introduction Diagnostics messages produce no side-effects
therefore they cannot change RSVP state in the nodes. In this
RSVP Diagnostics is less a security threat than other
tools and protocols such as SNMP
Furthermore, processing of Diagnostic messages can be disabled if
is felt that is a security threat
8.
The idea of developing a diagnostic facility for RSVP was
suggested by Mark Handley of ACIRI. Many thanks to Lee Breslau
AT&T Labs and John Krawczyk of Nortel Networks for their
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
memo. Tim Gleeson contributed an extensive list of
comments. We would also like to acknowledge Intel for providing
research grant as a partial support for this work.
Vincent did most of this work while a graduate research assistant
the USC Information Sciences Institute (ISI).
9.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin
"Resource ReserVation Protocol -- Version 1
Specification", RFC 2205, September 1997.
[RSVPTUN] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang
"RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
Terzis, et al. Standards Track [Page 21]
RFC 2745 RSVP Diagnostic Messages January 2000
10. Authors'
Andreas
4677 Boelter
Los Angeles, CA 90095
Phone: 310-267-2190
EMail: terzis@cs.ucla.
Bob
USC Information Sciences
4676 Admiralty
Marina del Rey, CA 90292
Phone: 310 822-1511
EMail: braden@isi.
Subramaniam
Cisco
275, E Tasman Drive, MS SJC04/2/1
San Jose, CA 95134
Phone: 408 525 3474
EMail: svincent@cisco.
Lixia
4531G Boelter
Los Angeles, CA 90095
Phone: 310-825-2695
EMail: lixia@cs.ucla.
Terzis, et al. Standards Track [Page 22]
RFC 2745 RSVP Diagnostic Messages January 2000
10. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Terzis, et al. Standards Track [Page 23]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
