draft-ietf-rsvp-diagnostic-msgs-05.txt   draft-ietf-rsvp-diagnostic-msgs-06.txt 
INTERNET-DRAFT Lixia Zhang INTERNET-DRAFT Andreas Terzis
Expires: May 1999 Andreas Terzis Expires: August 1999 UCLA
<draft-ietf-rsvp-diagnostic-msgs-05.txt> UCLA <draft-ietf-rsvp-diagnostic-msgs-06.txt> Bob Braden
Subramaniam Vincent
Cisco
Bob Braden
ISI ISI
November 1998 Subramaniam Vincent
Cisco Systems
Lixia Zhang
UCLA
February 1999
RSVP Diagnostic Messages RSVP Diagnostic Messages
<draft-ietf-rsvp-diagnostic-msgs-05.txt> <draft-ietf-rsvp-diagnostic-msgs-06.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with all
documents of the Internet Engineering Task Force (IETF), its areas, provisions of Section 10 of RFC2026.
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference material
material or to cite them other than as "work in progress". or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited. The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract Abstract
This document specifies the RSVP diagnostic facility, which allows a This document specifies the RSVP diagnostic facility, which allows a
user to collect information about the RSVP state along the path. user to collect information about the RSVP state along the path. This
This specification describes the functionality, diagnostic message specification describes the functionality, diagnostic message formats,
formats, and processing rules. and processing rules.
Changes
A summary of the changes from the previous version (05) of this document
follows:
- Added text in the Overview Section, to explain the role of the
LAST-HOP node. Section 4.1 was also updated with rules for DREQ
processing at RSVP nodes downstream of the LAST-HOP.
- The Next-Hop RSVP_HOP object was moved out of the DIAGNOSTIC
object. It's new place is directly after the Session object and
before the DIAGNOSTIC object. This was done to simplify implementa-
tion and to comply with object order in other RSVP messages. The IP
address of this RSVP_HOP object now carries the address of the
interface from which the DREQ is sent. While the IP address is not
(currently) used, this was done to conform with the use of RSVP_HOP
objects in other RSVP messages.
- A minimum value for the Path MTU field is defined.
- In the description of the DIAG_SELECT object, new text is added
explaining where the information requested by object types can be
collected from.
- The text explaining the use of the Previous RSVP-Hop Router Address
in the DIAG_RESPONSE object was changed. The previous version
incorrectly said that this address was the address of the interface
through which the DREQ would be forwarded. It is actually the
address *to* which the DREQ message will be forwarded.
- In the DIAGNOSTIC object, the LAST-HOP IP address was moved in
front of the SENDER_TEMPLATE.
- The H bit was removed. The existence of the ROUTE object signifies
whether the DREQ should be returned hop-by-hop.
- The "MTU too big" error was renamed to "packet too big" to reflect
more closely the situation under which it is generated.
- Section 4.1 (DREQ Packet Forwarding) was revamped
- The Send_DREP() section was rewritten
- Section 4.2 (DREP Forwarding) was updated.
- Section 4.3 (MTU Selection and Adjustment) was updated.
1. Introduction 1. Introduction
In the basic RSVP protocol [RSVP], error messages are the only means In the basic RSVP protocol [RSVP], error messages are the only means for
for an end host to receive feedback regarding a failure in setting up an end host to receive feedback regarding a failure in setting up either
either path state or reservation state. An error message carries path state or reservation state. An error message carries back only the
back only the information from the failed point, without any information from the failed point, without any information about the
information about the state at other hops before or after the state at other hops before or after the failure. In the absence of
failure. In the absence of failures, a host receives no feedback failures, a host receives no feedback regarding the details of a reser-
regarding the details of a reservation that has been put in place, vation that has been put in place, such as whether, or where, or how,
such as whether, or where, or how, its own reservation request is its own reservation request is being merged with that of others. Such
being merged with that of others. Such missing information can be missing information can be highly desirable for debugging purpose, or
highly desirable for debugging purpose, or for network resource
management in general.
This document specifies the RSVP diagnostic facility, which is for network resource management in general.
designed to fill this information gap. The diagnostic facility can
be used to collect and report RSVP state information along the path This document specifies the RSVP diagnostic facility, which is designed
from a receiver to a specific sender. It uses Diagnostic messages to fill this information gap. The diagnostic facility can be used to
that are independent of other RSVP control messages and produce no collect and report RSVP state information along the path from a receiver
side-effects; that is, they do not change any RSVP state at either to a specific sender. It uses Diagnostic messages that are independent
nodes or hosts. Similarly, they provide not an error report but of other RSVP control messages and produce no side-effects; that is,
rather a collection of requested RSVP state information. they do not change any RSVP state at either nodes or hosts. Similarly,
they provide not an error report but rather a collection of requested
RSVP state information.
The RSVP diagnostic facility was designed with the following goals: The RSVP diagnostic facility was designed with the following goals:
- To collect RSVP state information from every RSVP-capable hop
along a path defined by path state, either for an existing - To collect RSVP state information from every RSVP-capable hop along
reservation or before a reservation request is made. More a path defined by path state, either for an existing reservation or
specifically, we want to be able to collect information about before a reservation request is made. More specifically, we want
flowspecs, refresh timer values, and reservation merging at each to be able to collect information about flowspecs, refresh timer
hop along the path. values, and reservation merging at each hop along the path.
- To collect the IP hop count across each non-RSVP cloud. - To collect the IP hop count across each non-RSVP cloud.
- To avoid diagnostic packet implosion or explosion. - To avoid diagnostic packet implosion or explosion.
The following is specifically identified as a non-goal: The following is specifically identified as a non-goal:
- Checking the resource availability along a path. Such - Checking the resource availability along a path. Such functional-
functionality may be useful for future reservation requests, but ity may be useful for future reservation requests, but it would
it would require modifications to existing admission control require modifications to existing admission control modules that is
modules that is beyond the scope of RSVP. beyond the scope of RSVP.
2. Overview 2. Overview
The diagnostic facility introduces two new RSVP message types: The diagnostic facility introduces two new RSVP message types: Diagnos-
Diagnostic Request (DREQ) and Diagnostic Reply (DREP). A DREQ tic Request (DREQ) and Diagnostic Reply (DREP). A DREQ message can be
message can be originated by a client in a "requester" host, which originated by a client in a "requester" host, which may or may not be a
may or may not be a participant of the RSVP session to be diagnosed. participant of the RSVP session to be diagnosed. A client in the
A client in the requester host invokes the RSVP diagnostic facility requester host invokes the RSVP diagnostic facility by generating a DREQ
by generating a DREQ packet and sending it to the starting node, packet and sending it towards the LAST-HOP node, which should be on the
which should be on the RSVP path to be diagnosed. This DREQ packet RSVP path to be diagnosed. This DREQ packet specifies the RSVP session
specifies the RSVP session and a sender host for that session. The and a sender host for that session. Starting from the LAST-HOP, the DREQ
DREQ packet collects information hop-by-hop as it is forwarded packet collects information hop-by-hop as it is forwarded towards the
towards the sender (see Figure 1), until it reaches the ending node. sender (see Figure 1), until it reaches the ending node. Specifically,
Specifically, each RSVP-capable hop adds to the DREQ message a each RSVP-capable hop adds to the DREQ message a response
response (DIAG_RESPONSE) object containing local RSVP state for the (DIAG_RESPONSE) object containing local RSVP state for the specified
specified RSVP session. When the DREQ packet reaches the ending RSVP session.
node, the message type is changed to Diagnostic Reply (DREP) and the
completed response is sent to the original requester node. Partial
responses may also be returned before the DREQ packet reaches the
ending node if an error condition along the path, such as "no path
state", prevents further forwarding of the DREQ packet. To avoid
packet implosion or explosion, all diagnostic packets are forwarded
via unicast only.
Thus, there are generally three nodes (hosts and/or routers) involved When the DREQ packet reaches the ending node, the message type is
in performing the diagnostic function: the requester node, the
starting node, and the ending node, as shown in Figure 1. It is changed to Diagnostic Reply (DREP) and the completed response is sent to
possible that the client invoking the diagnosis function may reside the original requester node. Partial responses may also be returned
directly on the starting node, in which case that the first two nodes before the DREQ packet reaches the ending node if an error condition
are the same. The starting node is named "LAST-HOP", meaning the along the path, such as "no path state", prevents further forwarding of
last-hop of the path segment to be diagnosed. The LAST-HOP node can the DREQ packet. To avoid packet implosion or explosion, all diagnostic
be either a receiver node or an intermediate node along the path. packets are forwarded via unicast only.
The ending node is usually the specified sender host. However, the
client can limit the length of the path segment to be diagnosed by Thus, there are generally three nodes (hosts and/or routers) involved in
specifying a hop-count limit in the DREQ message. performing the diagnostic function: the requester node, the starting
node, and the ending node, as shown in Figure 1. It is possible that
the client invoking the diagnosis function may reside directly on the
starting node, in which case that the first two nodes are the same. The
starting node is named "LAST-HOP", meaning the last-hop of the path seg-
ment to be diagnosed. The LAST-HOP node can be either a receiver node
or an intermediate node along the path. The ending node is usually the
specified sender host. However, the client can limit the length of the
path segment to be diagnosed by specifying a hop-count limit in the DREQ
message.
LAST-HOP Ending LAST-HOP Ending
Receiver node node Sender Receiver node node Sender
__ __ __ __ __ __ __ __ __ __
| |---------| |------>| |--> ...-->| |--> ...---->| | | |---------| |------>| |--> ...-->| |--> ...---->| |
|__| |__| DREQ |__| DREQ |__| DREQ |__| |__| |__| DREQ |__| DREQ |__| DREQ |__|
^ . | ^ . |
| . | | . |
| DREQ . DREP | DREP | DREQ . DREP | DREP
| . | | . |
_|_ DREP V V _|_ DREP V V
Requester | | <------------------------------------ Requester | | <------------------------------------
(client) |___| (client) |___|
Figure 1 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
taken by the DREQ message to the LAST-HOP, and thence to the
requester. The direct return is faster and more efficient, but the
hop-by-hop reverse-path route may be the only choice if the packets
have to cross firewalls. Hop-by-hop return is accomplished using an
optional ROUTE object, which is built incrementally to contain a list
of node addresses that 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.
A DREQ message always consists of a single unfragmented IP datagram. DREP packets can be unicast from the ending node back to the requester
On the other hand, one DREQ message can generate multiple DREP either directly or hop-by-hop along the reverse of the path taken by the
packets, each containing a fragment of the total DREQ message. When DREQ message to the LAST-HOP, and thence to the requester. The direct
the path consists of many hops, the total length of a DREP message return is faster and more efficient, but the hop-by-hop reverse-path
will exceed the MTU size before reaching the sender; thus, the route may be the only choice if the packets have to cross firewalls.
message has to be fragmented. Relying on IP fragmentation and Hop-by-hop return is accomplished using an optional ROUTE object, which
reassembly, however, can be problematic, especially when DREP is built incrementally to contain a list of node addresses that the DREQ
messages are returned to the requester hop-by-hop, in which case packet has passed through. The ROUTE object is then used in reverse as
fragmentation/reassembly would have to be performed at every hop. To a source route to forward the DREP hop-by-hop back to the LAST-HOP node.
avoid such excessive overhead, we let the requester define a default
path MTU size that is carried in every DREQ packet. If an A DREQ message always consists of a single unfragmented IP datagram. On
intermediate node finds that the default MTU size is bigger than the the other hand, one DREQ message can generate multiple DREP packets,
MTU of the outgoing link, it returns the DREQ packet with the each containing a fragment of the total DREQ message. When the path
corresponding error bit set. If an intermediate node detects that a consists of many hops, the total length of a DREP message will exceed
DREQ packet size has reached the MTU size, it returns to the the MTU size before reaching the sender; thus, the message has to be
requester (in either manner described above) a DREP fragment fragmented. Relying on IP fragmentation and reassembly, however, can be
containing accumulated responses. It then removes these responses problematic, especially when DREP messages are returned to the requester
hop-by-hop, in which case fragmentation/reassembly would have to be per-
formed at every hop. To avoid such excessive overhead, we let the
requester define a default path MTU size that is carried in every DREQ
packet. If an intermediate node finds that the default MTU size is big-
ger than the MTU of the incoming interface, it reduces the default MTU
size to the MTU size of the incoming interface. If an intermediate node
detects that a DREQ packet size is larger than the default MTU size, it
returns to the requester (in either manner described above) a DREP frag-
ment containing accumulated responses. It then removes these responses
from the DREQ and continues to forward it. The requester node can from the DREQ and continues to forward it. The requester node can
reassemble the resulting DREP fragments into a complete DREP message. reassemble the resulting DREP fragments into a complete DREP message.
When discussing diagnostic packet handling, this document uses When discussing diagnostic packet handling, this document uses direction
direction terminology that is consistent with the RSVP functional terminology that is consistent with the RSVP functional specification
specification [RSVP], relative to the direction of data packet flow. [RSVP], relative to the direction of data packet flow. Thus, a DREQ
Thus, a DREQ packet enters a node through an "outgoing interface" and packet enters a node through an "outgoing interface" and is forwarded
is forwarded towards the sender through an "incoming interface", towards the sender through an "incoming interface", because DREQ packets
because DREQ packets travel in the reverse direction to the data travel in the reverse direction to the data flow.
flow.
Notice that DREQ packets can be forwarded only after the RSVP path Notice that DREQ packets can be forwarded only after the RSVP path state
state has been set up. If no path state exists, one may resort to has been set up. If no path state exists, one may resort to the tracer-
the traceroute or mtrace facility to examine whether the oute or mtrace facility to examine whether the unicast/multicast routing
unicast/multicast routing is working correctly. is working correctly.
3. Diagnostic Packet Format 3. Diagnostic Packet Format
Like other RSVP messages, DREQ and DREP messages consist of an RSVP Like other RSVP messages, DREQ and DREP messages consist of an RSVP Com-
Common Header followed by a variable set of typed RSVP data objects. mon Header followed by a variable set of typed RSVP data objects. The
The following sequence must be used: following sequence must be used:
+-----------------------------------+ +-----------------------------------+
| RSVP Common Header | | RSVP Common Header |
+-----------------------------------+ +-----------------------------------+
| Session object | | Session object |
+-----------------------------------+ +-----------------------------------+
| Next-Hop RSVP_HOP object |
+-----------------------------------+
| DIAGNOSTIC object | | DIAGNOSTIC object |
+-----------------------------------+ +-----------------------------------+
| (optional) DIAG_SELECT object | | (optional) DIAG_SELECT object |
+-----------------------------------+ +-----------------------------------+
| (optional) ROUTE object | | (optional) ROUTE object |
+-----------------------------------+ +-----------------------------------+
| zero or more DIAG_RESPONSE objects| | zero or more DIAG_RESPONSE objects|
+-----------------------------------+ +-----------------------------------+
The session object identifies the RSVP session for which the state The session object identifies the RSVP session for which the state
information is being collected. We describe each of the other parts. information is being collected. We describe each of the other parts.
3.1. RSVP Message Common Header 3.1. RSVP Message Common Header
The RSVP message common header is defined in [RSVP]. The following The RSVP message common header is defined in [RSVP]. The following spe-
specific exceptions and extensions are needed for DREP and DREQ. cific exceptions and extensions are needed for DREP and DREQ.
Type field: define: Type field: define:
Type = 8: DREQ Diagnostic Request Type = 8: DREQ Diagnostic Request
Type = 9: DREP Diagnostic Reply Type = 9: DREP Diagnostic Reply
RSVP length: RSVP length:
If this is a DREP message and the MF flag in the DIAGNOSE object 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 (see below) is set, this field indicates the length of this single
DREP fragment rather than the total length of the complete DREP DREP fragment rather than the total length of the complete DREP reply
reply message (which cannot generally be known in advance). message (which cannot generally be known in advance).
3.2. DIAGNOSTIC Object 3.2. Next-Hop RSVP_HOP Object
A DIAGNOSTIC object contains the common diagnostic control This RSVP_HOP object carries the LIH of the interface through which the
information in both DREQ and DREP messages. DREQ should be received at the upstream node. This object is updated
hop-by hop. It is used for the same reasons that a RESV message contains
an RSVP_HOP object: to distinguish logical interfaces and avoid problems
caused by routing asymmetries and non-RSVP clouds.
While the IP address is not really used during DREQ processing we
decided, for consistency with the use of RSVP_HOP object in other RSVP
messages, the IP address in the RSVP_HOP object to contain the address
of the interface through which a DREQ was sent.
3.3. DIAGNOSTIC Object
A DIAGNOSTIC object contains the common diagnostic control information
in both DREQ and DREP messages.
o IPv4 DIAGNOSTIC object: Class = 30, C-Type = 1 o IPv4 DIAGNOSTIC object: Class = 30, C-Type = 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-RSVP-hops | RSVP-hop-count| Reserved |H|MF| | Max-RSVP-hops | RSVP-hop-count| Reserved |MF|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID | | Request ID |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Path MTU | Fragment offset | | Path MTU | Fragment Offset |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| |
| SENDER_TEMPLATE object |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAST-HOP Address | | LAST-HOP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Requester FILTER_SPEC object | | SENDER_TEMPLATE object |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Next-Hop RSVP_HOP Object | | Requester FILTER_SPEC object |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here all IP addresses use the 4 byte IPv4 format, both explicitly in Here all IP addresses use the 4 byte IPv4 format, both explicitly in the
the LAST-HOP Address and by using the IPv4 forms of the embedded LAST-HOP Address and by using the IPv4 forms of the embedded FILTER_SPEC
FILTER_SPEC and RSVP_HOP objects. and RSVP_HOP objects.
o IPv6 DIAGNOSTIC object: Class = 30, C-Type = 2 o IPv6 DIAGNOSTIC object: Class = 30, C-Type = 2
The format is the same, except all explicit and embedded IP addresses The format is the same, except all explicit and embedded IP addresses
are 16 byte IPv6 addresses. are 16 byte IPv6 addresses.
The fields are as follows: The fields are as follows:
Max-RSVP-hops Max-RSVP-hops
An octet specifying the maximum number of RSVP hops over which infor-
An octet specifying the maximum number of RSVP hops over which mation will be collected. If an error condition in the middle of the
information will be collected. If an error condition in the path prevents the DREQ packet from reaching the specified ending
middle of the path prevents the DREQ packet from reaching the node, the Max-RSVP-hops field may be used to perform an expanding-
specified ending node, the Max-RSVP-hops field may be used to length search to reach the point just before the problem. If this
perform an expanding-length search to reach the point just before value is 1, the starting node and the ending node of the query will
the problem. If this value is 1, the LAST-HOP node and the ending be the same. If it is zero, there is no hop limit.
node will be the same. If it is zero, there is no hop limit.
RSVP-hop-count RSVP-hop-count
Records the number of RSVP hops that have been traversed so far. Records the number of RSVP hops that have been traversed so far. If
If LAST-HOP and ending nodes are the same, this value will be 1 in the starting and ending nodes are the same, this value will be 1 in
the resulting DREP message. the resulting DREP message.
Fragment Offset Fragment Offset
Indicates where this DREP fragment belongs in the complete DREP Indicates where this DREP fragment belongs in the complete DREP mes-
message, measured in octets. The first fragment has offset zero. sage, measured in octets. The first fragment has offset zero. Frag-
Ignored in a DREQ message. ment Offset is used to determine if a DREQ message containing zero
DIAG_RESPONSE objects should be processed at an RSVP capable node.
H flag
Indicates how the reply should be returned. When H = 0, DREP
packets should be sent to the response address directly. If H =
1, DREP packets must be returned hop-by-hop along the reverse path
to the LAST-HOP node and thence to the requester node.
MF flag MF flag
Flag means "more fragments". It must be set to zero (0) in all Flag means "more fragments". It must be set to zero (0) in all DREQ
DREQ messages. It must be set to one (1) in all DREP packets that messages. It must be set to one (1) in all DREP packets that carry
carry partial results and are returned by intermediate nodes due partial results and are returned by intermediate nodes due to the MTU
to the MTU limit. When the DREQ message is converted to a DREP limit. When the DREQ message is converted to a DREP message in the
message in the ending node, the MF flag must remain zero. ending node, the MF flag must remain zero.
Request ID Request ID
Identifies an individual DREQ message and the corresponding DREP Identifies an individual DREQ message and the corresponding DREP mes-
message (or all the fragments of the reply message). sage (or all the fragments of the reply message).
One possible way to defining the Request ID would use 16 bits to One possible way to defining the Request ID would use 16 bits to
specify the ID of the process making the query and 16 bits to specify the ID of the process making the query and 16 bits to distin-
distinguish different queries from this process. guish different queries from this process.
Path MTU Path MTU
Specifies a default MTU size in octets for DREP and DREQ messages. 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 made here is that a diagnostic packet of this size can
always be forwarded without being fragmented.
SENDER_TEMPLATE object LAST-HOP Address
This IPv4/IPv6 SENDER_TEMPLATE object contains the IP address and The IP address of the LAST-HOP node. The DREQ message starts col-
the port of a sender for the session being diagnosed. The DREQ lecting information at this node and proceeds toward the sender.
packet is forwarded hop-by-hop towards this address.
LAST-HOP Address SENDER_TEMPLATE object
The IP address of the LAST-HOP node. The DREQ message starts This IPv4/IPv6 SENDER_TEMPLATE object contains the IP address and the
collecting information at this node and proceeds toward the port of a sender for the session being diagnosed. The DREQ packet is
sender. forwarded hop-by-hop towards this address.
Requester FILTER_SPEC Object Requester FILTER_SPEC Object
This IPv4/IPv6 FILTER_SPEC object contains the IP address and the This IPv4/IPv6 FILTER_SPEC object contains the IP address and the
port from which the request originated and to which the DREP port from which the request originated and to which the DREP mes-
message(s) should be sent. sage(s) should be sent.
Next-Hop RSVP_HOP Object
An RSVP_HOP object carrying the IP address and LIH of the
interface through which the DREQ will be received. This object is
updated hop-by hop. It is used for the same reasons that a RESV
message contains an RSVP_HOP object: to distinguish logical
interfaces and avoid problems caused by routing asymmetries.
3.3. DIAG_SELECT Object 3.4. DIAG_SELECT Object
o DIAG_SELECT Class = 33, C-Type = 0. o DIAG_SELECT Class = 33, C-Type = 0.
A Diagnostic message may optionally contain a DIAG_SELECT object to A Diagnostic message may optionally contain a DIAG_SELECT object to
specify which specific RSVP objects should be reported in a specify which specific RSVP objects should be reported in a
DIAG_RESPONSE object. In the absence of a DIAG_SELECT object, the DIAG_RESPONSE object. In the absence of a DIAG_SELECT object, the
DIAG_RESPONSE object added by the node will contain a default set of DIAG_RESPONSE object added by the node will contain a default set of
object types (see DIAG_RESPONSE object below). object types (see DIAG_RESPONSE object below).
The DIAG_SELECT object contains a list of [Class, C-type] pairs, in The DIAG_SELECT object contains a list of [Class, C-type] pairs, in the
the following format: following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| class | C-Type | class | C-Type | | class | C-Type | class | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// // // //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 When a DIAG_SELECT object is included in a DREQ message, each RSVP node
node along the path will add a DIAG_RESPONSE object containing along the path will add a DIAG_RESPONSE object containing response
response objects (see below) whose classes and C-Types match entries objects (see below) whose classes and C-Types match entries in the
in the DIAG_SELECT list (and are from matching path and reservation DIAG_SELECT list (and are from matching path and reservation state). A
state). A C-type octet of zero is a 'wildcard', matching any C-Type C-type octet of zero is a 'wildcard', matching any C-Type associated
associated with the associated class. with the associated class.
Depending on the type of objects requested, a node can find the associ-
ated information in the path or reservation state stored for the session
described in the SESSION object. Specifically, information for the
RSVP_HOP,SENDER_TEMPLATE, SENDER_TSPEC, ADSPEC and FILTER_SPEC objects
can be extracted from the node's path state, while information for the
FLOWSPEC, CONFIRM, STYLE and SCOPE 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 of If the number of [Class, C-Type] pairs is odd, the last two octets of
the DIAG_SELECT object must be zero. 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.
3.4. ROUTE Object 3.5. ROUTE Object
A diagnostic message may contain a ROUTE object, which is used to A diagnostic message may contain a ROUTE object, which is used to record
record the route of the DREQ message and as a source route for the route of the DREQ message and as a source route for returning the
returning the DREP message(s) hop-by-hop. DREP message(s) hop-by-hop.
o IPv4 ROUTE object: Class = 31, C-Type = 1. o IPv4 ROUTE object: Class = 31, C-Type = 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | R-pointer | | reserved | R-pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ RSVP Node List | + RSVP Node List |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message signifies how the reply should be returned. If it does not
exist in the DREQ packet then DREP packets should be sent to the
response address directly. If it does exist, DREP packets must be
returned hop-by-hop along the reverse path to the LAST-HOP node and
thence to 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 List RSVP Node List
A list of RSVP node IPv4 addresses. The number of addresses in A list of RSVP node IPv4 addresses. The number of addresses in this
this list can be computed from the object size. list can be computed from the object size.
R-pointer R-pointer
Used in DREP messages only (see Section 4.2 for details), but it is
Used in DREP messages only (see Section 4.2 for details), but it incremented as each hop adds its incoming interface address in the
is incremented as each hop adds its incoming interface address in ROUTE object.
the ROUTE object.
o IPv6 ROUTE object: Class = 31, C-Type = 2 o IPv6 ROUTE object: Class = 31, C-Type = 2
The same, except RSVP Node List contains IPv6 addresses. The same, except RSVP Node List contains IPv6 addresses.
In a DREQ message, RSVP Node List specifies all RSVP hops between the In a DREQ message, RSVP Node List specifies all RSVP hops between the
LAST-HOP address specified in the DIAGNOSTIC object, and the last LAST-HOP address specified in the DIAGNOSTIC object, and the last RSVP
RSVP node the DREQ message has visited. In a DREP message, RSVP Node node the DREQ message has visited. In a DREP message, RSVP Node List
List specifies all RSVP hops between the LAST-HOP and the node that specifies all RSVP hops between the LAST-HOP and the node that returns
returns this DREP message. this DREP message.
3.5. DIAG_RESPONSE Object 3.6. DIAG_RESPONSE Object
Each RSVP node attaches DIAG_RESPONSE object to each DREQ message it Each RSVP node attaches DIAG_RESPONSE object to each DREQ message it
receives, before forwarding the message. The DIAG_RESPONSE object receives, before forwarding the message. The DIAG_RESPONSE object con-
contains the state to be reported for this node. It has a fixed- tains the state to be reported for this node. It has a fixed-format
format header and then a variable list of RSVP state objects, or header and then a variable list of RSVP state objects, or "response
"response objects". objects".
o IPv4 DIAG_RESPONSE object: Class = 32, C-Type = 1. o IPv4 DIAG_RESPONSE object: Class = 32, C-Type = 1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DREQ Arrival Time | | DREQ Arrival Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming Interface Address | | Incoming Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outgoing Interface Address | | Outgoing Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 39 skipping to change at page 12, line 7
| (optional) TUNNEL object | | (optional) TUNNEL object |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Response objects // // Response objects //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o IPv6 DIAG_RESPONSE object: Class = 32, C-Type = 2. o IPv6 DIAG_RESPONSE object: Class = 32, C-Type = 2.
This object has the same format, except that all explicit and This object has the same format, except that all explicit and embedded
embedded IP addresses are IPv6 addresses. IP addresses are IPv6 addresses.
The fields are as follows: The fields are as follows:
DREQ Arrival Time DREQ Arrival Time
A 32-bit NTP timestamp specifying the time the DREQ message A 32-bit NTP timestamp specifying the time the DREQ message arrived
arrived at this node. The 32-bit form of an NTP timestamp at this node. The 32-bit form of an NTP timestamp consists of the
consists of the middle 32 bits of the full 64-bit form, that is, middle 32 bits of the full 64-bit form, that is, the low 16 bits of
the low 16 bits of the integer part and the high 16 bits of the the integer part and the high 16 bits of the fractional part.
fractional part.
Incoming Interface Address Incoming Interface Address
Specifies the IP address of the interface on which messages from Specifies the IP address of the interface on which messages from the
the sender are expected to arrive, or 0 if unknown. sender are expected to arrive, or 0 if unknown.
Outgoing Interface Address Outgoing Interface Address
Specifies the IP address of the interface through which the DREQ Specifies the IP address of the interface through which the DREQ mes-
message arrived and to which messages from the given sender and sage arrived and to which messages from the given sender and for the
for the specified session address flow, or 0 if unknown. specified session address flow, or 0 if unknown.
Previous-RSVP-Hop Router Address Previous-RSVP-Hop Router Address
Specifies the node from which this node receives RSVP PATH Specifies the IP address from which this node receives RSVP PATH mes-
messages for this source, or 0 if unknown. This is also the sages for this source, or 0 if unknown. This is also the interface
interface through which the DREQ will be forwarded. to which the DREQ will be forwarded.
D-TTL D-TTL
The number of IP hops this DREQ message traveled from the down- The number of IP hops this DREQ message traveled from the down-stream
stream RSVP node to the current node. RSVP node to the current node.
M flag M flag
A single-bit flag which indicates whether the reservation A single-bit flag which indicates whether the reservation described
described by the response objects, is merged with reservations by the response objects, is merged with reservations from other down-
from other downstream interfaces when being forwarded upstream. stream interfaces when being forwarded upstream.
R-error R-error
A 3-bit field that indicates error conditions at a node. A 3-bit field that indicates error conditions at a node. Currently
Currently defined values are: defined values are:
0x00: no error 0x00: no error
0x01: no PATH state 0x01: No PATH state
0x02: MTU too big 0x02: packet too big
0x04: ROUTE object too big 0x04: ROUTE object too big
K K
The refresh timer multiple (defined in RSVP spec). The refresh timer multiple (defined in [RSVP]).
Timer value Timer value
The local refresh timer value in seconds. The local refresh timer value in seconds.
The set of response objects to be included at the end of the The set of response objects to be included at the end of the
DIAG_RESPONSE object is determined by a DIAG_SELECT object, if one is DIAG_RESPONSE object is determined by a DIAG_SELECT object, if one is
present. If no DIAG_SELECT object is present, the response objects present. If no DIAG_SELECT object is present, the response objects
belong to the default list of classes: belong to the default list of classes:
SENDER_TSPEC object FILTER_SPEC object SENDER_TSPEC object FILTER_SPEC object FLOWSPEC object
FLOWSPEC object STYLE object STYLE object
Any C-Type present in the local RSVP state will be used. These Any C-Type present in the local RSVP state will be used. These response
response objects may be in any order but they must all be at the end objects may be in any order but they must all be at the end of the
of the DIAG_RESPONSE object. DIAG_RESPONSE object.
3.6. TUNNEL Object A default DIAG_RESPONSE object is one containing the default list of
classes described above.
3.7. TUNNEL Object
The optional TUNNEL object should be inserted when a DREQ message The optional TUNNEL object should be inserted when a DREQ message
arrives at an RSVP node that acts as a tunnel exit point. arrives at an RSVP node that acts as a tunnel exit point.
The TUNNEL object provides mapping between the end-to-end RSVP The TUNNEL object provides mapping between the end-to-end RSVP session
session that is being diagnosed and the RSVP session over the tunnel. that is being diagnosed and the RSVP session over the tunnel. This map-
This mapping information allows the diagnosis client to conduct ping information allows the diagnosis client to conduct diagnosis over
diagnosis over the involved tunnel session, by invoking a separate the involved tunnel session, by invoking a separate Diagnostic query for
Diagnostic query for the corresponding Tunnel Session and Tunnel the corresponding Tunnel Session and Tunnel Sender. Keep in mind, how-
Sender. Keep in mind, however, that multiple end-to-end sessions may ever, that multiple end-to-end sessions may all map to one pre-config-
all map to one pre-configured tunnel session that may have totally ured tunnel session that may have totally different parameter settings.
different parameter settings.
The tunnel object is defined in the RSVP Tunnel Specification The tunnel object is defined in the RSVP Tunnel Specification [RSVPTUN].
[RSVPTUN].
4. Diagnostic Packet Forwarding Rules 4. Diagnostic Packet Forwarding Rules
4.1. DREQ Packet Forwarding 4.1. DREQ Packet Forwarding
DREQ messages are forwarded hop-by-hop via unicast from the LAST-HOP DREQ messages are forwarded hop-by-hop via unicast from the LAST-HOP
address to the Sender address, as specified in the DIAGNOSTIC object. address to the Sender address, as specified in the DIAGNOSTIC object.
At each hop, the following processing is performed before the DREQ If an RSVP capable node, other than the LAST-HOP node, receives a DREQ
message is forwarded to the next hop towards the sender: message that contains no DIAG_RESPONSE objects and has a zero Fragment
Offset, the node should forward the DREQ packet towards the LAST-HOP
without doing any of the processing mentioned below. The reason is that
such conditions apply only for nodes downstream of the LAST-HOP where no
information should be collected.
1. Compute the IP hop count from the previous RSVP hop. This is Processing begins when a DREQ message, DREQ_in, arrives at a node. The
done by subtracting the value of the TTL value in the IP header following processing is performed before DREQ_in is forwarded:
from Send_TTL in the RSVP common header. Save the result in the
D-TTL field of the DIAG_RESPONSE object.
2. If no PATH state exists for the specified session, set R-error = 1. Create a new DIAG_RESPONSE object. Compute the IP hop count from
0x01 in the DIAG_RESPONSE object. the previous RSVP hop. This is done by subtracting the value of 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.
3. If the path MTU value is too large, set "MTU too large" error 2. Set the DREQ Arrival Time and the Outgoing Interface Address in the
bit, and change the MTU value to the MTU value of the incoming DIAG_RESPONSE object. If this node is the LAST-HOP, then the Out-
interface for the sender. going Interface Address field in the DIAG_RESPONSE object contains
the following value depending on the session being diagnosed.
4. Attach the DIAG_RESPONSE object to the end of the DREQ message, * If the session in question is a unicast session, then the Out-
and append response objects that describe the reservation in going Interface Address field contains the address of the
place at the Outgoing Interface for the specified session. interface LAST-HOP uses to send PATH messages and data to the
receiver specified by the session address.
If the DREQ message contains a DIAG_SELECT object, the response * Otherwise, if it is a multicast session and there is at least
object classes are those specified in the DIAG_SELECT; one receiver for this session, LAST_HOP should use the address
otherwise, they are SENDER_TSPEC, FILTER_SPEC, STYLE, and of one of local interfaces used to reach one of the receivers.
FLOWSPEC objects. If no reservation state exists for the
specified RSVP session, the DIAG_RESPONSE object will contain no
FILTER_SPEC or FLOWSPEC or STYLE object. If neither PATH nor
reservation state exists for the specified RSVP session, then no
response objects will be appended to the DIAG_RESPONSE object.
5. Increment the RSVP-hop-count field in the diagnostic message * Otherwise Outgoing Interface Address should be zero.
header by one.
If the resulting value is equal to Max-RSVP-hops, or if the If no PATH state exists for the specified session, set R-error =
current hop is the sender as identified by the Sender 0x01 (No PATH state).
FILTER_SPEC object field in the DIAGNOSTIC object, go to
Send_DREP(), and then return.
6. If any error bit is set, change the type field in RSVP common 3. Increment the RSVP-hop-count field in the DIAGNOSTIC message object
header from DREQ to DREP, recompute the checksum, and send the by one.
message back to the requester. It is sent either hop-by-hop to
the LAST-HOP address (if H = 1), or directly to the requester
address (if H = 0).
7. If the resulting DREQ message size exceeds the MTU limit, minus 4. If the "No PATH state" bit is set, goto Send_DREP.
some margin to hold the address list object as described below,
go to Send_DREP().
8. If no error bit set, then if the H-bit is set, append the 5. Set the rest of the fields in the DIAG_RESPONSE object. If DREQ_in
"Incoming Interface Address" to the end of the ROUTE object, contains a DIAG_SELECT object, the response object classes are
increment R-Pointer by one, update the Next-Hop RSVP_HOP object those specified in the DIAG_SELECT; otherwise, they are
to be the Previous Hop from the Path State and update the SENDER_TSPEC, FILTER_SPEC, STYLE, and FLOWSPEC objects. If no
message length field in the RSVP common header accordingly. reservation state exists for the specified RSVP session, the
Finally, forward the DREQ message to the next hop towards the DIAG_RESPONSE object will contain no FILTER_SPEC or FLOWSPEC or
source, after recomputing the checksum. STYLE object. If neither PATH nor reservation state exists for the
specified RSVP session, then no response objects will be appended
to the DIAG_RESPONSE object.
Send_DREP(): 6. If RSVP-hop-count is equal to Max-RSVP-hops or this node is the
sender, go to Send_DREP.
1. If the H flag is off in the DIAGNOSTIC object, set 7. If the Path MTU value is larger than the MTU size of the incoming
target=response address given in the DREQ header, else set interface for the sender being diagnosed, change the Path MTU value
target = the last address in ROUTE. to the MTU value of the incoming interface.
2. Make a copy of the DREQ message and change the type field in 8. If the size of DREQ_in plus the size of the new DIAG_RESPONSE
RSVP common header from DREQ to DREP. If this host is not the object plus the size of an IP address ,if a ROUTE object exists, is
source, set the MF flag on. larger than Path MTU set the "packet too big" (0x02) error bit in
DIAG_RESPONSE, goto Send_DREP.
If the ROUTE object is so large such that (size of ROUTE + size 9. If a ROUTE object exists, append the "Incoming Interface Address"
of DIAG_RESPONSE object) > path MTU, then set the "route too to the end of the ROUTE object, increment R-Pointer by one, update
big" error bit, recompute the checksum, send the response the Next-Hop RSVP_HOP object, append the new DIAG_RESPONSE object
message and go to 4, else recompute the checksum and send the to the list of DIAG_RESPONSE object and update the message length
response message. field in the RSVP common header accordingly. Finally, forward
DREQ_in to the next hop towards the sender, after recomputing the
checksum. Return.
3. If this host is not the source, then trim off all the Send_DREP:
DIAG_RESPONSE objects from the original DREQ message, adjust the
"Fragment offset" value in the RSVP common header accordingly,
recompute the checksum, and forward the modified DREQ message
towards the source.
4. Return. 1. 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, is
larger than Path MTU set the "packet too big" (0x02) error bit in
DIAG_RESPONSE, otherwise goto step 11.
2. Make a copy of DREQ_in and change the type field in RSVP common
header from DREQ to DREP. Trim all DIAG_RESPONSE objects from
DREQ_in and adjust the Fragment Offset.
3. If a ROUTE object is present in the DREP message, decrement the R-
pointer and set target address to the last address in the ROUTE
object, otherwise set target address to the requester address. Set
the MF bit, recompute the checksum and send the DREP message back
to the target address.
4. If the 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 Path
MTU goto Step 9.
5. Make a copy of DREQ_in and change the type field in RSVP common
header from DREQ to DREP. If a ROUTE object exists, replace the
ROUTE object in DREQ_in with an empty ROUTE object. Turn on the
"ROUTE object too big" (0x04) error bit in the DIAG_RESPONSE.
6. 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, goto Step
8.
7. If a ROUTE object exists, append the "Incoming Interface Address"
to the end of the ROUTE object, increment R-Pointer by one, update
the Next-Hop RSVP_HOP object, append the new DIAG_RESPONSE object
to the list of DIAG_RESPONSE object, update the message length
field in the RSVP common header accordingly and adjust the Fragment
Offset. Finally, forward DREQ_in to the next hop towards the
sender, after recomputing the checksum.
8. Append the DIAG_RESPONSE object to the end of DREP. Set target
address to the requester address. Turn on the MF bit. Update the
packet length, recompute the checksum in the DREP message and send
it towards the target address. Return
9. 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, goto Step
11.
10. If a ROUTE object exists, append the "Incoming Interface Address"
to the end of the ROUTE object, increment R-Pointer by one, update
the Next-Hop RSVP_HOP object, append the new DIAG_RESPONSE object
to the list of DIAG_RESPONSE object and update the message length
field in the RSVP common header accordingly. Finally, forward
DREQ_in to the next hop towards the sender, after recomputing the
checksum. Return.
11. Append the DIAG_RESPONSE object to the end of DREQ_in. If a ROUTE
object is present in the message, decrement the R-pointer and set
target address to the last address in the ROUTE object, otherwise
set target address to the requester address. Change the Type Field
in the Common header from DREQ to DREP.Update the packet length,
recompute the checksum in the DREP message and send it towards the
target address. The MF bit in this case must be off.
4.2. DREP Forwarding 4.2. DREP Forwarding
When the H flag is off, DREP messages are sent directly to the When a ROUTE object is present, DREP messages are forwarded hop-by-hop
original requester. When H flag is on, however, they are forwarded towards the requester, by reversing the route as listed in the ROUTE
hop-by-hop towards the requester, by reversing the route as listed in object. Otherwise, DREP messages are sent directly to the original
the Route object. requester.
When a node receives a DREP message, it simply decreases R-pointer by When a node receives a DREP message, it simply decreases R-pointer by
one (address length), and forwards the message to the address pointed one (address length), recomputes the checksum and forwards the message
by R-pointer in the route list. to the address pointed by R-pointer in the route list. If 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 message When the LAST-HOP node receives a DREP message, it sends the message to
to the Response address. the requester.
4.3. MTU Selection and Adjustment 4.3. MTU Selection and Adjustment
Because the DREQ message carries the allowed MTU size of previous Because the DREQ message carries the allowed MTU size of previous hops
hops that the DREP messages will later traverse, this unique feature that the DREP messages will later traverse, this unique feature allows
allows the easy semantic fragmentation as described above. Whenever the easy semantic fragmentation as described above. Whenever the DREQ
the DREQ message grows to approach the size of MTU, it can be trimmed message approaches the size of Path MTU, it can be trimmed before being
before being forwarded again. forwarded again.
When a requester sends a DREQ message, the path MTU field in the RSVP When a requester sends a DREQ message, the Path MTU field in the DIAG-
Diagnostic Packet header can be set to a configured default value. NOSTIC object can be set to a configured default value. It is possible
that the original Path MTU value is chosen larger than the actual MTU
value along some portion of the path being traced. Therefore each
intermediate RSVP node must check the MTU value when processing a DREQ
message. If the specified MTU value is larger than the MTU of the
incoming interface (that the DREQ message will be forwarded to), the
node changes the MTU value in the header to the smaller value.
Whenever a DREQ message size approaches the specified MTU value, an Whenever a DREQ message size becomes larger than the Path MTU value, an
intermediate RSVP node makes a copy of the message, converts it to a intermediate RSVP node makes a copy of the message, converts it to a
DREP message to send back, and then trims off the partial results DREP message to send back, and then trims off the partial results from
from DREQ message and forwards it. the DREQ message. If in this case also the DREQ cannot be forwarded
upstream due to a large ROUTE object, the "ROUTE object too big" is set
It is possible that the original MTU value is chosen larger than the and the ROUTE object is trimmed. As a result of the ROUTE object trim-
actual MTU value along some portion of the path being traced. ming, DREP(s) will come hop-by-hop up to this node and will then immedi-
Therefore each intermediate RSVP node must check the MTU value when ately forwarded to the requester address.
processing a DREQ message. If the specified MTU value is larger than
the MTU of the incoming interface (that the DREQ message will be
forwarded to), the node
(1) sets the R-error value,
(2) changes the MTU value in the header to the smaller value, and
(3) converts the DREQ message to a DREP and sends it back to the
requester.
In the rare case where some intermediate nodes do not check, or Even if the steps shown above are followed there are a few cases where
enforce upon, the MTU value carried in the diagnostic messages, it is fragmentation at the IP layer will happen. For example, non-RSVP hops
possible that on the way back to the requester, a DREP message may with smaller MTUs may exist before LAST-HOP is reached, or if the
encounter a link of smaller MTU. response is sent directly back to requester (as opposed to hop by hop)
the DREP may take a different route to the requester than the DREQ took
When this happens, the node follows steps (1) and (2) as outlined from the requester. Another case is when there exists a link with MTU
above, and trims off the extra part of the DREP message to fit in the smaller than the minimum Path MTU value defined in Section 3.2.
smaller MTU of the link. The trimming must be done at response
object boundaries. Such trimming of messages results in information
loss. However because the requester learns what is the available MTU
size, it can either ignore the loss, or otherwise try again with the
smaller MTU value.
4.4. Errors 4.4. Errors
If an error condition prevents a DREP message from being forwarded If an error condition prevents a DREP message from being forwarded fur-
further, the message is simply dropped. ther, the message is simply dropped.
If an error condition, such as lack of PATH state, prevents a DREQ If an error condition, such as lack of PATH state, prevents a DREQ mes-
message from being forwarded further, the node must change the sage from being forwarded further, the node must change the current mes-
current message to DREP type and return it to the response address. sage to DREP type and return it to the response address.
5. Problem Diagnosis by Using RSVP Diagnostic Facility 5. Problem Diagnosis by Using RSVP Diagnostic Facility
5.1. Across Firewalls 5.1. Across Firewalls
Firewalls may cause problems in diagnostic message forwarding. Let Firewalls may cause problems in diagnostic message forwarding. Let us
us look at two different cases. look at two different cases.
First, let us assume that the querier resides on a receiving host of First, let us assume that the querier resides on a receiving host of the
the session to be examined. In this case, firewalls should not session to be examined. In this case, firewalls should not prevent the
prevent the forwarding of the diagnostic messages in a hop-by-hop forwarding of the diagnostic messages in a hop-by-hop manner, assuming
manner, assuming that proper holes have been punched on the firewall that proper holes have been punched on the firewall to allow hop-by-hop
to allow hop-by-hop forwarding of other RSVP messages. The querier forwarding of other RSVP messages. The querier may start by not includ-
may start by setting the H flag off, which can give a faster response ing a ROUTE object, which can give a faster response delivery and
delivery and reduced overhead at intermediate nodes. However if no reduced overhead at intermediate nodes. However if no response is
response is received, the querier may resend the DREQ message with H received, the querier may resend the DREQ message with a ROUTE object,
flag turned on. specifying that a hop-by-hop reply should be sent.
If the requester is a third party host and is separated from the If the requester is a third party host and is separated from the LAST-
LAST-HOP address by a firewall (either the requester is behind a HOP address by a firewall (either the requester is behind a firewall, or
firewall, or the LAST-HOP is a node behind a firewall, or both), at the LAST-HOP is a node behind a firewall, or both), at this time we do
this time we do not know any other solution but to change the LAST- not know any other solution but to change the LAST-HOP to a node that is
HOP to a node that is on the same side of the firewall as the on the same side of the firewall as the requester.
requester.
5.2. Examination of RSVP Timers 5.2. Examination of RSVP Timers
One can easily collect information about the current timer value at One can easily collect information about the current timer value at each
each RSVP hop along the way. This will be very helpful in situations RSVP hop along the way. This will be very helpful in situations when
when the reservation state goes up and down frequently, to find out the reservation state goes up and down frequently, to find out whether
whether the state changes are due to improper setting of timer the state changes are due to improper setting of timer values, or K val-
values, or K values (when across lossy links), or frequent routing ues (when across lossy links), or frequent routing changes.
changes.
5.3. Discovering Non-RSVP Clouds 5.3. Discovering Non-RSVP Clouds
The D-TTL field in each DIAG_RESPONSE object shows the number of The D-TTL field in each DIAG_RESPONSE object shows the number of routing
routing hops between adjacent RSVP nodes. Therefore any value hops between adjacent RSVP nodes. Therefore any value greater than one
greater than one indicates a non-RSVP clouds in between. Together indicates a non-RSVP clouds in between. Together with the arrival
with the arrival timestamps (assuming NTP works), this value can also timestamps (assuming NTP works), this value can also give some vague,
give some vague, though not necessarily accurate, indication of how though not necessarily accurate, indication of how big that cloud might
big that cloud might be. One might also find out all the be. One might also find out all the intermediate non-RSVP nodes by run-
intermediate non-RSVP nodes by running either unicast or multicast ning either unicast or multicast trace route.
trace route.
5.4. Discovering Reservation Merges 5.4. Discovering Reservation Merges
The flowspec value in a DIAG_RESPONSE object specifies the amount of The flowspec value in a DIAG_RESPONSE object specifies the amount of
resources being reserved for the data stream defined by the filter resources being reserved for the data stream defined by the filter spec
spec in the same data block. When this value of adjacent in the same data block. When this value of adjacent DIAG_RESPONSE
DIAG_RESPONSE objects differs, that is, a downstream node Rd has a objects differs, that is, a downstream node Rd has a smaller value than
smaller value than its immediate upstream node Ru, it indicates a its immediate upstream node Ru, it indicates a merge of reservation with
merge of reservation with RSVP request(s) from other down stream RSVP request(s) from other down stream interface(s) at Rd. Further, in
interface(s) at Rd. Further, in case of SE style reservation, one case of SE style reservation, one can examine how the different SE
can examine how the different SE scopes get merged at each hop. scopes get merged at each hop.
In particular, if a receiver sends a DREQ message before sending its In particular, if a receiver sends a DREQ message before sending its own
own reservation, it can discover (1) how many RSVP hops there are reservation, it can discover (1) how many RSVP hops there are along the
along the path between the specified sender and itself, (2) how many path between the specified sender and itself, (2) how many of the hops
of the hops already have some reservation by other receivers, and (3) already have some reservation by other receivers, and (3) possibly a
possibly a rough prediction of how its reservation request might get rough prediction of how its reservation request might get merged with
merged with other existing ones. other existing ones.
5.5. Error Diagnosis 5.5. Error Diagnosis
In addition to examining the state of a working reservation, RSVP In addition to examining the state of a working reservation, RSVP diag-
diagnostic messages are more likely to be invoked when things are not nostic messages are more likely to be invoked when things are not work-
working correctly. For example, a receiver has reserved an adequate ing correctly. For example, a receiver has reserved an adequate pipe
pipe for a specified incoming data stream, yet the observed delay or for a specified incoming data stream, yet the observed delay or loss
loss ratio is much higher than expected. In this case the receiver ratio is much higher than expected. In this case the receiver can use
can use the diagnostic facility to examine the reservation state at the diagnostic facility to examine the reservation state at each RSVP
each RSVP hop along the way to find out whether the RSVP state is set hop along the way to find out whether the RSVP state is set up cor-
up correctly, whether there is any blackhole along the way that rectly, whether there is any blackhole along the way that caused RSVP
caused RSVP message losses, or whether there are non-RSVP clouds, and message losses, or whether there are non-RSVP clouds, and where they
where they are, that may have caused the performance problem. are, that may have caused the performance problem.
5.6. Crossing "Legacy" RSVP Routers 5.6. Crossing "Legacy" RSVP Routers
Since this diagnosis facility was developed and added to RSVP after a Since this diagnosis facility was developed and added to RSVP after a
number of RSVP implementations were in place, it is possible, or even number of RSVP implementations were in place, it is possible, or even
likely, that when performing RSVP diagnosis, one may encounter one or likely, that when performing RSVP diagnosis, one may encounter one or
more RSVP-capable nodes that do not understand diagnostic messages more RSVP-capable nodes that do not understand diagnostic messages and
and drop them. When this happens, the invoking client will get no drop them. When this happens, the invoking client will get no response
response from its requests. from its requests.
One way to by-pass such "legacy" RSVP nodes is to perform RSVP One way to by-pass such "legacy" RSVP nodes is to perform RSVP diagnosis
diagnosis repeatedly, guided by information from traceroute, or repeatedly, guided by information from traceroute, or mtrace in case of
mtrace in case of multicast. When an RSVP diagnostic query times out multicast. When an RSVP diagnostic query times out (see next section),
(see next section), one may first use traceroute to get the list of one may first use traceroute to get the list of nodes along the path,
nodes along the path, and then gradually increase the value of Max- and then gradually increase the value of Max-RSVP-hops field in the DREQ
RSVP-hops field in the DREQ message, starting from a low value until message, starting from a low value until one no longer receives a
one no longer receives a response. One can then try RSVP diagnosis response. One can then try RSVP diagnosis again by starting with the
again by starting with the first node (which is further upstream first node (which is further upstream towards the sender) after the
towards the sender) after the unresponding one. unresponding one.
There are two problem with the method mentioned above in the case of There are two problem with the method mentioned above in the case of
unicast sessions. Both problems are related to the fact that unicast sessions. Both problems are related to the fact that traceroute
traceroute information provides the path from the requester to the information provides the path from the requester to the sender. The
sender. The first problem is that the LAST_HOP may not on the path first problem is that the LAST-HOP may not on the path from the
from the requester to the sender. In this case we can get information requester to the sender. In this case we can get information only from
only from the portion of the path from the LAST_HOP to the sender the portion of the path from the LAST-HOP to the sender which intersects
which intersects with the path from the requester to the sender. If with the path from the requester to the sender. If routers that are not
routers that are not on the intersection of the two paths don't have on the intersection of the two paths don't have PATH state for the ses-
PATH state for the session being diagnosed then they will reply with sion being diagnosed then they will reply with R-error=0x01. The
R-error=0x01. The requester can overcome this problem by sending a requester can overcome this problem by sending a DREQ to every router on
DREQ to every router on the path (from itself to the sender) until it the path (from itself to the sender) until it reaches the first router
reaches the first router that belongs to the path from the sender to that belongs to the path from the sender to the LAST-HOP.
the LAST_HOP.
The second problem is that traceroute provides the path from the The second problem is that traceroute provides the path from the
requester to the sender which, due to routing asymmetries, may be requester to the sender which, due to routing asymmetries, may be dif-
different than the path traffic from the sender to the LAST_HOP uses. ferent than the path traffic from the sender to the LAST-HOP uses. There
There are (at least) one case where this asymmetry will cause the is (at least) one case where this asymmetry will cause the diagnosis to
diagnosis to fail. We present this case below. fail. We present this case below.
Downstream Path Sender Downstream Path Sender
__ __ __ __ __ __ __ __
Receiver +------| |<------| |<-- ...---| |-----| | Receiver +------| |<------| |<-- ...---| |-----| |
__ __ / |__| |__| |__| |__| __ __ / |__| |__| |__| |__|
| |--....--|X |_/ ^ | |--....--|X |_/ ^
|__| |__| Router B | |__| |__| \ Router B |
Black __ | Black \ __ |
Hole +----->| |---->---+ Hole +----->| |---->---+
|__| Upstream Path |__| Upstream Path
Router A Router A
Figure 2 Figure 2
Here the first hop upstream of the black hole is different on the Here the first hop upstream of the black hole is different on the
upstream path and the downstream path. Traceroute will indicate upstream path and the downstream path. Traceroute will indicate router A
router A as the previous hop (instead of router B which is the right as the previous hop (instead of router B which is the right one). Send-
one). Sending a DREQ to router A will result in A responding with R- ing a DREQ to router A will result in A responding with R-error 0x01 (No
error 0x01 (No PATH State). If the two paths converge again then the PATH State). If the two paths converge again then the requester can use
requester can use the solution proposed above to get any (partial) the solution proposed above to get any (partial) information from the
information from the rest of the path. rest of the path.
We don't have, for the moment, any complete solutions for the We don't have, for the moment, any complete solutions for the problem-
problematic scenarios described here. atic scenarios described here.
6. Comments on Diagnostic Client Implementation. 6. Comments on Diagnostic Client Implementation.
Following the design principle that nodes in the network should not Following the design principle that nodes in the network should not hold
hold more than necessary state, RSVP nodes are responsible only for more than necessary state, RSVP nodes are responsible only for forward-
forwarding Diagnostic messages and filling DIAG_RESPONSE objects. ing Diagnostic messages and filling DIAG_RESPONSE objects. Additional
Additional diagnostic functionality should be carried out by the diagnostic functionality should be carried out by the diagnostic
diagnostic clients. Furthermore, if the diagnostic function is clients. Furthermore, if the diagnostic function is invoked from a
invoked from a third-party host, we should not require that host be third-party host, we should not require that host be running RSVP daemon
running RSVP daemon to perform the function. Below we sketch out the to perform the function. Below we sketch out the basic functions that a
basic functions that a diagnostic client daemon should carry out. diagnostic client daemon should carry out.
1. Take input from the user about the session to be diagnosed, the 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 last-hop and the sender address, the Max-RSVP-hops, and possibly
the DIAG_SELECT list, create a DREQ message and send to the the DIAG_SELECT list, create a DREQ message and send to the LAST-
LAST-HOP RSVP node using raw IP message with protocol number 46 HOP RSVP node using raw IP message with protocol number 46 (RSVP).
(RSVP). The port of the UDP socket on which the Diagnostic If the user specified that the response should be sent hop-by-hop
Client is listening for replies should be included in the include an empty ROUTE object to the DREQ message sent. Set the
Requester FILTER_SPEC object. Path_MTU to the smaller of the user request and the MTU of the link
through which the DREQ will be sent.
2. Set a retransmission timer, waiting for the reply (one or more The port of the UDP socket on which the Diagnostic Client is
DREP messages). Listen to the specified UDP port for responses listening for replies should be included in the Requester FIL-
from the LAST-HOP RSVP node. TER_SPEC object.
The LAST-HOP RSVP node, upon receiving DREP messages, sends them 2. Set a retransmission timer, waiting for the reply (one or more DREP
to the the Diagnostic Client as UDP packets, using the port messages). Listen to the specified UDP port for responses from the
supplied in the Requester FILTER_SPEC object. LAST-HOP RSVP node.
3. Upon receiving a DREP message to an outstanding diagnostic The LAST-HOP RSVP node, upon receiving DREP messages, sends them to
request, the client should clear the retransmission timer, check the the Diagnostic Client as UDP packets, using the port supplied
to see if the reply contains the complete result of the in the Requester FILTER_SPEC object.
requested diagnosis. If so, it should pass the result up to the
invoking entity immediately. 3. Upon receiving a DREP message to an outstanding diagnostic request,
the client should clear the retransmission timer, check to see if
the reply contains the complete result of the requested diagnosis.
If so, it should pass the result up to the invoking entity immedi-
ately.
4. Reassemble DREP fragments. If the first reply to an outstanding 4. Reassemble DREP fragments. If the first reply to an outstanding
diagnostic request contains only a fragment of the expected diagnostic request contains only a fragment of the expected result,
result, the client should set up a reassembly timer in a way the client should set up a reassembly timer in a way similar to IP
similar to IP packet reassembly timer. If the timer goes off packet reassembly timer. If the timer goes off before all frag-
before all fragments arrive, the client should pass the partial ments arrive, the client should pass the partial result to the
result to the invoking entity. invoking entity.
5. Use retransmission and reassembly timers to gracefully handle 5. Use retransmission and reassembly timers to gracefully handle
packet losses and reply fragment scenarios. packet losses and reply fragment scenarios.
In the absence of response to the first diagnostic request, a In the absence of response to the first diagnostic request, a
client should retransmit the request a few times. If all the client should retransmit the request a few times. If all the
retransmissions also fail, the client should invoke traceroute retransmissions also fail, the client should invoke traceroute or
or mtrace to obtain the list of hops along the path segment to mtrace to obtain the list of hops along the path segment to be
be diagnosed, and then perform an iteration of diagnosis with diagnosed, and then perform an iteration of diagnosis with increas-
increasing hop count as suggested in Section 5.6 in order to ing hop count as suggested in Section 5.6 in order to cross RSVP-
cross RSVP-capable but diagnosis-incapable nodes. capable but diagnosis-incapable nodes.
6. If all the above efforts fail, the client must notify the 6. If all the above efforts fail, the client must notify the invoking
invoking entity. entity.
7. Security Considerations 7. Security Considerations
RSVP Diagnostics, as any other diagnostic tool, can be a security RSVP Diagnostics, as any other diagnostic tool, can be a security threat
threat since it can reveal possibly sensitive RSVP state information since it can reveal possibly sensitive RSVP state information to
to unwanted third parties. unwanted third parties.
We feel that the threat is minimal, since as explained in the We feel that the threat is minimal, since as explained in the Introduc-
Introduction Diagnostics messages produce no side-effects and tion Diagnostics messages produce no side-effects and therefore they
therefore they cannot change RSVP state in the nodes. In this respect
RSVP Diagnostics is less a security threat than other diagnostic
tools and protocols such as SNMP.
Furthermore, processing of Diagnostic messages can be disabled if it cannot change RSVP state in the nodes. In this respect RSVP Diagnostics
is felt that is a security threat. is less a security threat than other diagnostic tools and protocols such
as SNMP.
Furthermore, processing of Diagnostic messages can be disabled if it is
felt that is a security threat.
8. Acknowledgments 8. Acknowledgments
The idea of developing a diagnostic facility for RSVP was first The idea of developing a diagnostic facility for RSVP was first sug-
suggested by Mark Handley of UCL. Many thanks to Lee Breslau of gested by Mark Handley of UCL. Many thanks to Lee Breslau of Xerox PARC
Xerox PARC and John Krawczyk of Baynetworks for their valuable and John Krawczyk of Baynetworks for their valuable comments on the
comments on the first draft of this memo. Lee Breslau, Bob Braden, first draft of this memo. Lee Breslau, Bob Braden, and John Krawczyk
and John Krawczyk contributed further comments after March 1996 IETF. contributed further comments after March 1996 IETF. Steven Berson pro-
Steven Berson provided valuable comments on various drafts of the vided valuable comments on various drafts of the memo. We would also
memo. We would also like to acknowledge Intel for providing a like to acknowledge Intel for providing a research grant as a partial
research grant as a partial support for this work. Subramaniam support for this work. Subramaniam Vincent did most of this work while a
Vincent did most of this work while a graduate research assistant at graduate research assistant at the USC Information Sciences Institute
the USC Information Sciences Institute (ISI). (ISI).
9. References 9. References
[RSVPTUN] A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang. "RSVP [RSVP] Braden, R. Ed. et al, "Resource ReserVation Protocol -- Version 1
Operation Over IP Tunnels ", Internet Draft draft-ietf-rsvp-tunnel- Functional Specification", RFC 2205, September 1997.
03.txt, August, 1998.
10. Authors' Addresses
Lixia Zhang [RSVPTUN] A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang. "RSVP Opera-
UCLA tion Over IP Tunnels ", Internet Draft. draft-ietf-rsvp-tunnel-02.txt,
4531G Boelter Hall February, 1999.
Los Angeles, CA 90095
Phone: 310-825-2695 10. Authors' Addresses
EMail: lixia@cs.ucla.edu
Andreas Terzis Andreas Terzis
UCLA UCLA
4677 Boelter Hall 4677 Boelter Hall
Los Angeles, CA 90095 Los Angeles, CA 90095
Phone: 310-267-2190 Phone: 310-267-2190
Email: terzis@cs.ucla.edu 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 Subramaniam Vincent
Cisco Systems Cisco Systems
275, E Tasman Drive, MS SJC04/2/1 275, E Tasman Drive, MS SJC04/2/1
San Jose, CA 95134. San Jose, CA 95134.
Phone: 408 525 3474 Phone: 408 525 3474
Email: svincent@cisco.com Email: svincent@cisco.com
Bob Braden Lixia Zhang
USC Information Sciences Institute UCLA
4676 Admiralty Way 4531G Boelter Hall
Marina del Rey, CA 90292 Los Angeles, CA 90095
Phone: 310 822-1511 Phone: 310-825-2695
EMail: braden@isi.edu EMail: lixia@cs.ucla.edu
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/