draft-ietf-rsvp-diagnostic-msgs-04.txt   draft-ietf-rsvp-diagnostic-msgs-05.txt 
INTERNET-DRAFT Lixia Zhang INTERNET-DRAFT Lixia Zhang
<draft-ietf-rsvp-diagnostic-msgs-04.txt> Andreas Terzis Expires: May 1999 Andreas Terzis
Expiration: February 1999 UCLA <draft-ietf-rsvp-diagnostic-msgs-05.txt> UCLA
Subramaniam Vincent Subramaniam Vincent
Cisco
August 1998 Bob Braden
ISI
November 1998
RSVP Diagnostic Messages RSVP Diagnostic Messages
<draft-ietf-rsvp-diagnostic-msgs-04.txt> <draft-ietf-rsvp-diagnostic-msgs-05.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. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. 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
skipping to change at page 1, line 33 skipping to change at page 1, line 35
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress".
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 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). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet Draft expires in February, 1999.
Abstract Abstract
This document specifies the RSVP diagnosis facility. As the This document specifies the RSVP diagnostic facility, which allows a
deployment of RSVP is spreading out, it becomes clear that a method user to collect information about the RSVP state along the path.
for collecting information about the RSVP state along the path is This specification describes the functionality, diagnostic message
needed. This specification describes the functionality, diagnostic formats, and processing rules.
message formats, and processing rules.
1. Introduction 1. Introduction
In the original design of the RSVP protocol, error messages are the In the basic RSVP protocol [RSVP], error messages are the only means
only means for the end hosts to receive feedback information for an end host to receive feedback regarding a failure in setting up
regarding a specific request that has failed, a failure in setting up either path state or reservation state. An error message carries
either a PATH state or reservation state. In the absence of back only the information from the failed point, without any
failures, one receives no feedback regarding the details of a information about the state at other hops before or after the
reservation that has been put in place, such as whether, or where, or failure. In the absence of failures, a host receives no feedback
how, one's own reservation request is merged with that of others. In regarding the details of a reservation that has been put in place,
case of a failure, the error message carries back only the such as whether, or where, or how, its own reservation request is
information from the failed point, without any information about the being merged with that of others. Such missing information can be
state at other hops before or after the failure. Such missing highly desirable for debugging purpose, or for network resource
information, however, can be highly desirable for debugging purpose, management in general.
or for network resource management in general.
This document specifies RSVP diagnostic messages that allows one to
collect information of RSVP state along the path from a receiver to a
specific sender. Diagnostic messages are independent from any other
RSVP control messages and produce no side-effects. That is, they do
not change any RSVP state at either routers or hosts. Similarly,
they do not represent an error report but a collection of RSVP state
information as requested.
We have the following design goals in mind:
- To be able to collect RSVP state information at every hop along This document specifies the RSVP diagnostic facility, which is
the path where the PATH state has been set up, either for an designed to fill this information gap. The diagnostic facility can
existing reservation or before a reservation request is made; be used to collect and report RSVP state information along the path
here the "hop" means RSVP-capable routers. from a receiver to a specific sender. It uses Diagnostic messages
that are independent of other RSVP control messages and produce no
side-effects; that is, 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.
More specifically, we want to be able to collect information The RSVP diagnostic facility was designed with the following goals:
about flowspec, refresh timer values, and reservation merging at - To collect RSVP state information from every RSVP-capable hop
each hop along the path. along a path defined by path state, either for an existing
reservation or before a reservation request is made. More
specifically, we want to be able to collect information about
flowspecs, refresh timer values, and reservation merging at each
hop along the path.
- To be able to collect the routing hop count for each non-RSVP - To collect the IP hop count across each non-RSVP cloud.
cloud.
- To avoid diagnostic packet implosion or explosion. - To avoid diagnostic packet implosion or explosion.
The following are specifically identified as non-goals: 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
functionality may be useful for future reservation requests, but functionality may be useful for future reservation requests, but
would require modifications to existing admission control module it would require modifications to existing admission control
which is beyond the scope of RSVP. modules that is beyond the scope of RSVP.
2. Overview 2. Overview
We define two types of RSVP diagnostic packets, diagnostic request The diagnostic facility introduces two new RSVP message types:
(DREQ) and reply (DREP). This diagnostic tool can be invoked by a Diagnostic Request (DREQ) and Diagnostic Reply (DREP). A DREQ
client from any host that may or may not be a participant of the RSVP message can be originated by a client in a "requester" host, which
session to be diagnosed. Thus generally speaking three nodes are may or may not be a participant of the RSVP session to be diagnosed.
involved in performing the diagnostic function: the requester, the A client in the requester host invokes the RSVP diagnostic facility
starting and the ending nodes of the diagnosis, as shown in Figure 1. by generating a DREQ packet and sending it to the starting node,
It is possible that the client invoking the diagnosis function may which should be on the RSVP path to be diagnosed. This DREQ packet
reside directly on the LAST-HOP, in which case that the first two specifies the RSVP session and a sender host for that session. The
nodes are the the same. The starting node of the diagnosis is named DREQ packet collects information hop-by-hop as it is forwarded
"LAST-HOP", meaning the last-hop of the path segment to be diagnosed, towards the sender (see Figure 1), until it reaches the ending node.
which can be either the receiving end or an intermediate router along Specifically, each RSVP-capable hop adds to the DREQ message a
a reserved path. The ending node is the sender host in general, response (DIAG_RESPONSE) object containing local RSVP state for the
although one can also limit the length of the path segment to be specified RSVP session. When the DREQ packet reaches the ending
diagnosed by specifying a hop-count limit for the diagnosis messages. node, the message type is changed to Diagnostic Reply (DREP) and the
To avoid packet implosion or explosion, all diagnostic packets are completed response is sent to the original requester node. Partial
forwarded via unicast only. 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.
A client invokes RSVP diagnostic functions by generating a DREQ Thus, there are generally three nodes (hosts and/or routers) involved
packet and sending to the LAST-HOP node which should be on the RSVP in performing the diagnostic function: the requester node, the
path to be diagnosed. This DREQ packet specifies the RSVP session starting node, and the ending node, as shown in Figure 1. It is
and a sender host to that session. The DREQ packet starts collecting possible that the client invoking the diagnosis function may reside
information at the LAST-HOP node and proceeds toward the sender (see directly on the starting node, in which case that the first two nodes
Figure 1). are the same. The starting node is named "LAST-HOP", meaning the
last-hop of the path segment 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.
Receiver LAST-HOP Sender LAST-HOP Ending
__ __ __ __ __ __ __ Receiver node node Sender
| |---------| |------>| |-->| |-->| |-->| |---->| | __ __ __ __ __
|__| |__| DREQ |__| |__| |__| |__| |__| | |---------| |------>| |--> ...-->| |--> ...---->| |
^ |__| |__| DREQ |__| DREQ |__| DREQ |__|
| RSVP routers ^ . |
| | . |
|request | DREQ . DREP | DREP
_|_ | . |
| | Requester _|_ DREP V V
|___| Requester | | <------------------------------------
(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.
Each RSVP-capable router receiving the DREQ packet adds to the packet A DREQ message always consists of a single unfragmented IP datagram.
a response data object containing the router's RSVP state for the On the other hand, one DREQ message can generate multiple DREP
specified RSVP session, and then forwards the request via unicast to packets, each containing a fragment of the total DREQ message. When
the router that it believes to be the previous hop for the given the path consists of many hops, the total length of a DREP message
sender. Each subsequent RSVP router attaches its own response data will exceed the MTU size before reaching the sender; thus, the
object to the end of the DREQ packet, then forwards via unicast to message has to be fragmented. Relying on IP fragmentation and
the previous hop. When the DREQ packet reaches the sender, the reassembly, however, can be problematic, especially when DREP
sender changes the packet type to Diagnostic Reply (DREP) and sends messages are returned to the requester hop-by-hop, in which case
the completed response to the original requester. Partial response fragmentation/reassembly would have to be performed at every hop. To
may also be returned before the DREQ packet reaches the sender if any avoid such excessive overhead, we let the requester define a default
error condition along the path, such as "no path state", prevents path MTU size that is carried in every DREQ packet. If an
further forwarding of the DREQ packet, or if the specified hop-count intermediate node finds that the default MTU size is bigger than the
for the diagnosis has been reached. MTU of the outgoing link, it returns the DREQ packet with the
corresponding error bit set. If an intermediate node detects that a
DREP packets can be unicast back to the requester either directly, or DREQ packet size has reached the MTU size, it returns to the
in a hop-by-hop manner by reversing the exact path that the DREQ requester (in either manner described above) a DREP fragment
packet has taken. The former is faster and more efficient, but the containing accumulated responses. It then removes these responses
latter may be the only choice if the packets have to cross firewalls, from the DREQ and continues to forward it. The requester node can
due to the way that firewalls operate. reassemble the resulting DREP fragments into a complete DREP message.
To facilitate the latter case, a DREQ packet may optionally carry a
ROUTE object, which is a list of router addresses that the DREQ
packet has passed through on the way to the sender; this ROUTE object
is built incrementally as the DREQ packet passes through the
intermediate routers. The DREP packet can then be returned to the
requester by reversing the path.
When the path consists of many hops, it is possible that the total
length of a DREP packet will exceed the path MTU size before reaching
the sender, thus the packet has to be fragmented. Relying on IP
fragmentation and reassembly, however, can be problematic, especially
when DREP packets are returned to the requester hop-by-hop, in which
case fragmentation/reassembly would have to be performed at every
hop. To avoid such excessive overhead, we let the requester define a
default path MTU size which is carried in every DREQ packet. If an
intermediate router finds that the default MTU size is bigger than
that of the outgoing link, it returns the DREQ packet with the
corresponding error bit set. If an intermediate router detects that
a DREQ packet size reaches the MTU size, it sends a partial DREP,
consisting of the collected responses back, to the requester and then
continues to forward the trimmed DREQ packet to the next hop towards
the sender.
Through out this document we use the word "DREQ packet", rather the When discussing diagnostic packet handling, this document uses
word "message" to call a diagnostic request since it always consists direction terminology that is consistent with the RSVP functional
of a single packet. On the other hand, one DREQ packet can generate specification [RSVP], relative to the direction of data packet flow.
multiple DREP packets, each containing a fragment of the total reply. Thus, a DREQ packet enters a node through an "outgoing interface" and
Furthermore, when discussing diagnostic packet handling, the is forwarded towards the sender through an "incoming interface",
terminology used refers to the direction of data packet flow, thus because DREQ packets travel in the reverse direction to the data
"outgoing interface" of a router is the interface a DREQ packet comes
from. THE DREQ then gets forwarded to an "incoming interface",
because DREQ packets travel in the reverse direction of the data
flow. flow.
Notice that one can forward DREQ packets only after the RSVP PATH Notice that DREQ packets can be forwarded only after the RSVP path
state has been set up. If no PATH state exists, one may resort to state has been set up. If no path state exists, one may resort to
the traceroute or mtrace facility to examine whether the the traceroute or mtrace facility to examine whether the
unicast/multicast routing is working correctly. unicast/multicast routing is working correctly.
3. Diagnostic Packet Format 3. Diagnostic Packet Format
A diagnostic packet consists of the following parts: Like other RSVP messages, DREQ and DREP messages consist of an RSVP
Common Header followed by a variable set of typed RSVP data objects.
The following sequence must be used:
+-----------------------------------+ +-----------------------------------+
| RSVP common header | | RSVP Common Header |
+-----------------------------------+ +-----------------------------------+
| Diagnostic packet header object | | Session object |
+-----------------------------------+ +-----------------------------------+
| session object | | DIAGNOSTIC object |
+-----------------------------------+ +-----------------------------------+
| (optional) SELECT object | | (optional) DIAG_SELECT object |
+-----------------------------------+ +-----------------------------------+
| (optional) ROUTE object | | (optional) ROUTE object |
+-----------------------------------+ +-----------------------------------+
| zero or more Response Object | | zero or more DIAG_RESPONSE objects|
+-----------------------------------+ +-----------------------------------+
The session object identifies the RSVP session for which the state
information is being collected. We describe each of the other parts.
3.1. RSVP Message Common Header 3.1. RSVP Message Common Header
In the RSVP message common header, The RSVP message common header is defined in [RSVP]. The following
specific exceptions and extensions are needed for DREP and DREQ.
0 1 2 3 Type field: define:
+-------------+-------------+-------------+-------------+
| Vers | Flags| Type | RSVP Checksum |
+-------------+-------------+-------------+-------------+
| Send_TTL | reserved | RSVP Length |
+-------------+-------------+-------------+-------------+
The Flags field is unused for now and must be set to zero. Type = 8: DREQ Diagnostic Request
Type = 8: DREQ Type = 9: DREP Diagnostic Reply
Type = 9: DREP RSVP length:
The RSVP Checksum is the 16-bit one's complement of the one's
complement sum of the whole diagnosis message (including this
header). For computing the checksum, the checksum field is set to
zero. When receiving packets, the checksum MUST be verified before
processing a packet.
Send_TTL: the TTL value that a router puts in the IP packet header If this is a DREP message and the MF flag in the DIAGNOSE object
when forwarding the DREQ packet to the previous hop. (see below) is set, this field indicates the length of this single
DREP fragment rather than the total length of the complete DREP
reply message (which cannot generally be known in advance).
RSVP length: the total length of this diagnostic packet in bytes, 3.2. DIAGNOSTIC Object
including the common header. If this is a DREP packet and the MF
flag in the diagnostic packet header (see below) is set, this length
field indicate the length of this single DREP fragment, rather than
the total length of the the complete DREP reply (which may not be
known in advance).
3.2. RSVP Diagnostic Packet Header Object A DIAGNOSTIC object contains the common diagnostic control
information in both DREQ and DREP messages.
Both DREQ and DREP headers are a concatenation of Diagnostic Packet o IPv4 DIAGNOSTIC object: Class = 30, C-Type = 1
Header Object and an RSVP Session object, as defined below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-RSVP-hops | RSVP-hop-count| Reserved |H|MF| | Max-RSVP-hops | RSVP-hop-count| Reserved |H|MF|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Request ID |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| path MTU | Fragment offset | | Path MTU | Fragment offset |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
| Sender Filter-Spec | | SENDER_TEMPLATE object |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAST-HOP Address | | LAST-HOP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Response Address Filter-Spec | | Requester FILTER_SPEC object |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Next-Hop RSVP_HOP Object | | Next-Hop RSVP_HOP Object |
| | | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Followed by RSVP Session Object |
| |
Length is the length of this diagnostic header object. Here all IP addresses use the 4 byte IPv4 format, both explicitly in
the LAST-HOP Address and by using the IPv4 forms of the embedded
FILTER_SPEC and RSVP_HOP objects.
Class = 30. o IPv6 DIAGNOSTIC object: Class = 30, C-Type = 2
C-type field is used to distinguish between IPv4 (C-type = 1) and The format is the same, except all explicit and embedded IP addresses
IPv6 (Ctype = 2). In the IPv6 case addresses will be 16 bytes each. are 16 byte IPv6 addresses.
Max-RSVP-hops specifies the maximum number of RSVP hops that the The fields are as follows:
requester wants to collect information from. In case an error
condition in the middle of the path prevents the DREQ packet from
reaching the specified sender, one may use this field to perform an
expanding-length search to reach the point just before the problem.
The fragment offset field indicates where in the total reply this Max-RSVP-hops
fragment belongs. The fragment offset is measured in octets. The
first fragment has offset zero.
RSVP-hop-count field records the number of RSVP hops that have been An octet specifying the maximum number of RSVP hops over which
traversed so far. information will be collected. If an error condition in the
middle of the path prevents the DREQ packet from reaching the
specified ending node, the Max-RSVP-hops field may be used to
perform an expanding-length search to reach the point just before
the problem. If this value is 1, the LAST-HOP node and the ending
node will be the same. If it is zero, there is no hop limit.
The H flag indicates how the reply should be returned. When H = 0, RSVP-hop-count
DREP packets should be sent to the response address directly. If H =
1, DREP packets must be returned to the LAST-HOP address in a hop-
by-hop way. The node specified by the LAST-HOP address then forwards
DREP packets to the response address.
The MF flag means "more fragments". It must be set to zero (0) on Records the number of RSVP hops that have been traversed so far.
all DREQ packets, and set to one (1) on all DREP packets that carry If LAST-HOP and ending nodes are the same, this value will be 1 in
partial results and are returned by intermediate routers due to the the resulting DREP message.
MTU limit. When the sender converts a DREQ packet to DREP, the MF
flag remains zero. An intermediate router may also converts a DREQ
packet to DREP when the DREQ packet has traversed the specified
number of Max-RSVP-hops, in which case the MF flag remains zero.
Message ID identifies an individual DREQ packet and the corresponding Fragment Offset
reply (or all the fragments of the reply). A possible way of using
the message ID is the 16 bits to specify the ID of the process doing
the query and the low 16 bits to be the sequence number of the query.
This way processes on the same machine can distinguish between each
other's replies and between different copies of the same query.
The path MTU is a 16-bit field that specifies a default MTU size, in Indicates where this DREP fragment belongs in the complete DREP
number of bytes, that all diagnostic packets must fit within. message, measured in octets. The first fragment has offset zero.
Ignored in a DREQ message.
Sender Filter-Spec is the IP address plus the port of the sender H flag
being traced. The DREQ packet proceeds hop-by-hop towards this
address.
LAST-HOP address is the IP address of the last hop at the receiving Indicates how the reply should be returned. When H = 0, DREP
end for the path being traced. The DREQ packet starts collecting packets should be sent to the response address directly. If H =
information at this node and proceeds toward the sender. 1, DREP packets must be returned hop-by-hop along the reverse path
to the LAST-HOP node and thence to the requester node.
Response Address Filter-Spec contains the IP address and the port to MF flag
which the DREP packet(s) should be sent. This Response Address
Filter-Spec specifies the process originating the request.
The Next-Hop RSVP_HOP object carries the IP address of the interface Flag means "more fragments". It must be set to zero (0) in all
to which the DREQ must be forwarded to. This object is updated on a DREQ messages. It must be set to one (1) in all DREP packets that
hop by hop basis, and is used for the same reasons that a RESV carry partial results and are returned by intermediate nodes due
message contains an RSVP_HOP object. That is, to distinguish logical to the MTU limit. When the DREQ message is converted to a DREP
message in the ending node, the MF flag must remain zero.
Request ID
Identifies an individual DREQ message and the corresponding DREP
message (or all the fragments of the reply message).
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
distinguish different queries from this process.
Path MTU
Specifies a default MTU size in octets for DREP and DREQ messages.
SENDER_TEMPLATE object
This IPv4/IPv6 SENDER_TEMPLATE object contains the IP address and
the port of a sender for the session being diagnosed. The DREQ
packet is forwarded hop-by-hop towards this address.
LAST-HOP Address
The IP address of the LAST-HOP node. The DREQ message starts
collecting information at this node and proceeds toward the
sender.
Requester FILTER_SPEC Object
This IPv4/IPv6 FILTER_SPEC object contains the IP address and the
port from which the request originated and to which the DREP
message(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. interfaces and avoid problems caused by routing asymmetries.
The session object identifies the RSVP session for which the state 3.3. DIAG_SELECT Object
information is being collected.
Optionally, the diagnostic packet may contain a SELECT object which o DIAG_SELECT Class = 33, C-Type = 0.
carries a list of [Class, C-type] pairs, each pair specifies one type
of RSVP object the diagnosis invoking client wants to examine. When
a SELECT object is included in the DREQ packet, each RSVP router
along the way should attach to the response object each type of the
objects specified in the SELECT list. In the absence of a SELECT
object, the router will attach a set of default objects.
The SELECT object has the following format: A Diagnostic message may optionally contain a DIAG_SELECT object to
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 added by the node will contain a default set of
object types (see DIAG_RESPONSE object below).
The DIAG_SELECT object contains a list of [Class, C-type] pairs, in
the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type | | class | C-Type | class | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| class | c-type | class | c-type | // //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................... | | class | C-Type | class | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field represents the total length of the object in number When a DIAG_SELECT object is included in a DREQ message, each RSVP
of bytes. node along the path will add a DIAG_RESPONSE object containing
response objects (see below) whose classes and C-Types match entries
in the DIAG_SELECT list (and are from matching path and reservation
state). A C-type octet of zero is a 'wildcard', matching any C-Type
associated with the associated class.
Class = 33 If the number of [Class, C-Type] pairs is odd, the last two octets of
the DIAG_SELECT object must be zero.
C-type field is not used at the moment and must be set to zero. 3.4. ROUTE Object
The object payload part carries a list of [Class, C-type] pairs. In A diagnostic message may contain a ROUTE object, which is used to
case where the requested number of objects is an odd number, the last record the route of the DREQ message and as a source route for
two bytes must be set to zero. returning the DREP message(s) hop-by-hop.
Optionally, the diagnostic packet may also contain a ROUTE object, as o IPv4 ROUTE object: Class = 31, C-Type = 1.
defined below. The ROUTE object is to be used to return DREP packets
hop-by-hop.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | R-pointer | | reserved | R-pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ List of RSVP routers | + RSVP Node List |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field represents the total length of the object in number
of bytes, from which the number of addresses in the RSVP router list
can be easily computed.
Class = 31. RSVP Node List
C-type field is used to distinguish between IPv4 (C-type = 1) and A list of RSVP node IPv4 addresses. The number of addresses in
IPv6 (Ctype = 2) ROUTE object. this list can be computed from the object size.
R-pointer is used in DREP packets only (see Section 4.2 for details), R-pointer
but is incremented as each hop adds its incoming interface address in
Used in DREP messages only (see Section 4.2 for details), but it
is incremented as each hop adds its incoming interface address in
the ROUTE object. the ROUTE object.
In a DREQ packet, the List of RSVP routers lists all the RSVP hops o IPv6 ROUTE object: Class = 31, C-Type = 2
between the LAST-HOP address, as specified in the Diagnostic packet
header object, and the last RSVP router the DREQ packet has visited.
In a DREP packet, List of RSVP routers lists all the RSVP hops
between the LAST-HOP and the router that returns this DREP packet.
3.3. Response Data Object The same, except RSVP Node List contains IPv6 addresses.
When receiving a DREQ packet, each RSVP router attaches a "response In a DREQ message, RSVP Node List specifies all RSVP hops between the
data" object to it before forwarding on. The response data object is LAST-HOP address specified in the DIAGNOSTIC object, and the last
defined as follows: RSVP node the DREQ message has visited. In a DREP message, RSVP Node
List specifies all RSVP hops between the LAST-HOP and the node that
returns this DREP message.
3.5. DIAG_RESPONSE Object
Each RSVP node attaches DIAG_RESPONSE object to each DREQ message it
receives, before forwarding the message. The DIAG_RESPONSE object
contains the state to be reported for this node. It has a fixed-
format header and then a variable list of RSVP state objects, or
"response objects".
o IPv4 DIAG_RESPONSE object: Class = 32, C-Type = 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | C-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DREQ Arrival Time | | DREQ Arrival Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming Interface Address | | Incoming Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outgoing Interface Address | | Outgoing Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous-RSVP-Hop Router Address | | Previous-RSVP-Hop Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reservation style | | D-TTL |M|R-err| K | Timer value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| D-TTL |M|R-err| K | timer value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| (TUNNEL object) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Tspec object |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| filter spec object | | (optional) TUNNEL object |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| flowspec object | // Response objects //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class = 32. o IPv6 DIAG_RESPONSE object: Class = 32, C-Type = 2.
Ctype 1 and 2 specify whether this is an IPv4 or IPv6 response data, This object has the same format, except that all explicit and
respectively. embedded IP addresses are IPv6 addresses.
DREQ Arrival Time is a 32-bit NTP timestamp specifying the arrival The fields are as follows:
time of the DREQ packet at this router. The 32-bit form of an NTP
timestamp consists of the middle 32 bits of the full 64-bit form;
that is, the low 16 bits of the integer part and the high 16 bits of
the fractional part.
Incoming Interface Address specifies the IP address of the interface DREQ Arrival Time
on which packets from the sender, as defined in the Diagnostic Packet
Header, are expected to arrive, or 0 if unknown.
Outgoing Interface Address specifies the IP address of the interface A 32-bit NTP timestamp specifying the time the DREQ message
from which the DREQ packet comes, and to which packets from the given arrived at this node. The 32-bit form of an NTP timestamp
sender and for the specified session address flow, or 0 if unknown. consists of the middle 32 bits of the full 64-bit form, that is,
the low 16 bits of the integer part and the high 16 bits of the
fractional part.
Previous-RSVP-Hop Router Address specifies the router from which this Incoming Interface Address
router receives RSVP PATH messages for this source, or 0 if unknown.
Notice that the response object format as shown above assumes IPv4 Specifies the IP address of the interface on which messages from
addresses of 4-byte each; in case of IPv6 (indicated by C-type = 2), the sender are expected to arrive, or 0 if unknown.
these three addresses will be 16 bytes each.
Reservation style is the 4-byte value of RSVP Style Object as defined Outgoing Interface Address
in the RSVP specification.
D-TTL contains the routing hop count this DREQ packet traveled from Specifies the IP address of the interface through which the DREQ
the down-stream RSVP router to the current router. message arrived and to which messages from the given sender and
for the specified session address flow, or 0 if unknown.
M is a single-bit flag which indicates whether the reservation, as Previous-RSVP-Hop Router Address
described by the objects below, is merged with reservations from
other downstream interfaces when being forwarded upstream. Specifies the node from which this node receives RSVP PATH
messages for this source, or 0 if unknown. This is also the
interface through which the DREQ will be forwarded.
D-TTL
The number of IP hops this DREQ message traveled from the down-
stream RSVP node to the current node.
M flag
A single-bit flag which indicates whether the reservation
described by the response objects, is merged with reservations
from other downstream interfaces when being forwarded upstream.
R-error
A 3-bit field that indicates error conditions at a node.
Currently defined values are:
R-error is a 3-bit field that indicates error conditions at a router.
Currently defined values are
0x00: no error 0x00: no error
0x01: no PATH state 0x01: no PATH state
0x02: MTU too big 0x02: MTU too big
0x04: ROUTE object too big 0x04: ROUTE object too big
K is the refresh timer parameter defined in RSVP, and timer value is K
the local refresh timer value in seconds.
The next part, TUNNEL object, is an optional one which should be The refresh timer multiple (defined in RSVP spec).
inserted when a DREQ packet arrives at an RSVP router that acts as a
tunnel exit point. The TUNNEL object provides mapping between the
end-to-end RSVP session that is being diagnosed and the RSVP session
over the tunnel. This mapping information allows the diagnosis client
to conduct diagnosis over the involved tunnel session when so
desired, by invoking a separate Diagnostic query for the
corresponding Tunnel Session and Tunnel Sender. Keep in mind,
however, that multiple end-to-end sessions may all map to one pre-
configured tunnel session which may have totally different parameter
settings.
The tunnel object is defined in the RSVP Tunnel Specification Timer value
[RSVPTUN], with the following format: The local refresh timer value in seconds.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The set of response objects to be included at the end of the
| length | class | c-type | DIAG_RESPONSE object is determined by a DIAG_SELECT object, if one is
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ present. If no DIAG_SELECT object is present, the response objects
| | belong to the default list of classes:
| Session object (for the end-to-end session) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Filter-Spec (for the tunnel sender) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SESSION_ASSOC Object SENDER_TSPEC object FILTER_SPEC object
FLOWSPEC object STYLE object
Class=192. Ctype 1 specifies IPv4 sessions, Ctype 2 specifies IPv6 Any C-Type present in the local RSVP state will be used. These
sessions, and Ctypes 3 and 4 specify sessions with IPSEC Generalized response objects may be in any order but they must all be at the end
Port Id for IPv4 and IPv6 respectively. of the DIAG_RESPONSE object.
The remaining parts, Tspec, filter spec, and flowspec objects follow 3.6. TUNNEL Object
the definitions given in RSVP specification. The latter two may be
absent (see Section 4.1 on DREQ forwarding). In the case of a SE
reservation the filter spec is actually the set of all filter specs
that share the reservation. The flowspec describes the actual
reservation in place.
Also note that the length of these object is varying so the lengths The optional TUNNEL object should be inserted when a DREQ message
used on the diagram above are not representative. arrives at an RSVP node that acts as a tunnel exit point.
The TUNNEL object provides mapping between the end-to-end RSVP
session that is being diagnosed and the RSVP session over the tunnel.
This mapping information allows the diagnosis client to conduct
diagnosis over the involved tunnel session, by invoking a separate
Diagnostic query for the corresponding Tunnel Session and Tunnel
Sender. Keep in mind, however, that multiple end-to-end sessions may
all map to one pre-configured tunnel session that may have totally
different parameter settings.
The tunnel object is defined in the RSVP Tunnel Specification
[RSVPTUN].
4. Diagnostic Packet Forwarding Rules 4. Diagnostic Packet Forwarding Rules
4.1. DREQ Packet Forwarding 4.1. DREQ Packet Forwarding
DREQ packets are forwarded via hop-by-hop 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 packet address to the Sender address, as specified in the DIAGNOSTIC object.
header. Each hop performs the following processing before forwarding At each hop, the following processing is performed before the DREQ
the packet to the next hop towards the sender: message is forwarded to the next hop towards the sender:
1. Compute the routing hop count from the previous RSVP hop. This 1. Compute the IP hop count from the previous RSVP hop. This is
is done by subtracting the value of the TTL value in the IP done by subtracting the value of the TTL value in the IP header
header from Send_TTL in RSVP common header. The result is then from Send_TTL in the RSVP common header. Save the result in the
saved in the D-TTL field of the response data object. D-TTL field of the DIAG_RESPONSE object.
2. If no PATH state exists for the specified session, set R-error = 2. If no PATH state exists for the specified session, set R-error =
0x01 in the Response Data object. 0x01 in the DIAG_RESPONSE object.
3. If the path MTU value is too large, set "MTU too large" error 3. If the path MTU value is too large, set "MTU too large" error
bit, and change the MTU value to the MTU value of the incoming bit, and change the MTU value to the MTU value of the incoming
interface for PATH messages for the current router. interface for the sender.
4. Attach the response data object to the end of the DREQ packet. 4. Attach the DIAG_RESPONSE object to the end of the DREQ message,
If the DREQ packet contains a SELECT object, attach one copy of and append response objects that describe the reservation in
each of the objects specified in the SELECT. Otherwise attach place at the Outgoing Interface for the specified session.
Tspec, filter spec, and flowspec objects to the response object.
Tspec, filter spec, and flowspec objects describe the
reservation in place at the Outgoing Interface for the specified
session.
If no reservation state exists for the specified RSVP session, If the DREQ message contains a DIAG_SELECT object, the response
the response object will contain no filter-spec or flowspec object classes are those specified in the DIAG_SELECT;
object. otherwise, they are SENDER_TSPEC, FILTER_SPEC, STYLE, and
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.
If neither PATH nor reservation state exists for the specified 5. Increment the RSVP-hop-count field in the diagnostic message
RSVP session, then the response object contains none of the header by one.
Tspec, filter or flow spec object.
5. Increment the RSVP-hop-count field in the diagnostic packet If the resulting value is equal to Max-RSVP-hops, or if the
header by one. If the resulting value is equal to that of Max- current hop is the sender as identified by the Sender
RSVP-hops, or if the current hop is the sender as identified by FILTER_SPEC object field in the DIAGNOSTIC object, go to
the "Source Address" in the RSVP diagnostic header, go to
Send_DREP(), and then return. Send_DREP(), and then return.
6. If any error bit is set, change the type field in RSVP common 6. If any error bit is set, change the type field in RSVP common
header from DREQ to DREP, recompute the checksum and send the header from DREQ to DREP, recompute the checksum, and send the
packet back to either the LAST-HOP address (if H = 1), or to the message back to the requester. It is sent either hop-by-hop to
response address directly via unicast (if H = 0). the LAST-HOP address (if H = 1), or directly to the requester
address (if H = 0).
7. If the resulting DREQ packet size exceeds the MTU limit, minus 7. If the resulting DREQ message size exceeds the MTU limit, minus
some margin to hold the address list object as described below, some margin to hold the address list object as described below,
go to Send_DREP(). go to Send_DREP().
8. If no error bit set ,then if the H-bit is set, append the 8. If no error bit set ,then if the H-bit is set, append the
"Incoming Interface Address" to the end of the ROUTE object, "Incoming Interface Address" to the end of the ROUTE object,
increment R-Pointer by one, update the Next-Hop RSVP_HOP object increment R-Pointer by one, update the Next-Hop RSVP_HOP object
to be the Previous Hop from the Path State and update the packet to be the Previous Hop from the Path State and update the
length field in the RSVP common header accordingly. Finally message length field in the RSVP common header accordingly.
forward the DREQ packet to the next hop towards the source, Finally, forward the DREQ message to the next hop towards the
after recomputing the checksum. source, after recomputing the checksum.
Send_DREP(): Send_DREP():
1. If the H flag in the Diagnostic Header header is off, set 1. If the H flag is off in the DIAGNOSTIC object, set
target=response address given in the DREQ header, else set target=response address given in the DREQ header, else set
target = the last address in ROUTE. target = the last address in ROUTE.
2. Make a copy of the DREQ packet and change the type field in RSVP 2. Make a copy of the DREQ message and change the type field in
common header from DREQ to DREP. If this host is not the source RSVP common header from DREQ to DREP. If this host is not the
set the MF flag on. source, set the MF flag on.
If the ROUTE object is so large such that (size of ROUTE + size If the ROUTE object is so large such that (size of ROUTE + size
of response data object) > path MTU, then set the "route too of DIAG_RESPONSE object) > path MTU, then set the "route too
big" error bit, recompute the checksum, send the response packet big" error bit, recompute the checksum, send the response
and go to 4, else recompute the checksum and send the response message and go to 4, else recompute the checksum and send the
packet. response message.
3. If this host is not the source, then trim off all the response 3. If this host is not the source, then trim off all the
data objects from the original DREQ packet, adjust the "Fragment DIAG_RESPONSE objects from the original DREQ message, adjust the
offset" value in the RSVP common header accordingly and forward "Fragment offset" value in the RSVP common header accordingly,
the modified DREQ packet towards the source, after recomputing recompute the checksum, and forward the modified DREQ message
the checksum. towards the source.
4. Return. 4. Return.
4.2. DREP Forwarding 4.2. DREP Forwarding
When the H flag is off, DREP packets are sent directly to the When the H flag is off, DREP messages are sent directly to the
original requester. When H flag is on, however, they are forwarded original requester. When H flag is on, however, they are forwarded
hop-by-hop towards the requester, by reversing the route as listed in hop-by-hop towards the requester, by reversing the route as listed in
the Route object. the Route object.
When a router receives a DREP packet, it simply decreases R-pointer When a node receives a DREP message, it simply decreases R-pointer by
by one (address length), and forward the packet to the address one (address length), and forwards the message to the address pointed
pointed by R-pointer in the route list. by R-pointer in the route list.
When the LAST-HOP router receives a DREP packet, it sends the packet When the LAST-HOP node receives a DREP message, it sends the message
to the Response address. to the Response address.
4.3. MTU Selection and Adjustment 4.3. MTU Selection and Adjustment
Because the DREQ packet carries the allowed MTU size of previous hops Because the DREQ message carries the allowed MTU size of previous
that the DREP packets will later traverse, this unique feature allows hops that the DREP messages will later traverse, this unique feature
the easy semantic fragmentation as described above. Whenever the allows the easy semantic fragmentation as described above. Whenever
DREQ packet grows to approach the size of MTU, it can be trimmed the DREQ message grows to approach the size of MTU, it can be trimmed
before being forwarded again. before being forwarded again.
When a requester sends a DREQ packet, the path MTU field in the RSVP When a requester sends a DREQ message, the path MTU field in the RSVP
Diagnostic Packet header can be set to a configured default value. Diagnostic Packet header can be set to a configured default value.
Whenever a DREQ packet size approaches the specified MTU value, an Whenever a DREQ message size approaches the specified MTU value, an
intermediate RSVP router makes a copy of the packet, converts it to a intermediate RSVP node makes a copy of the message, converts it to a
DREP packet to send back, and then trims off the partial results from DREP message to send back, and then trims off the partial results
DREQ packet and forwards it. from DREQ message and forwards it.
It is possible that the original MTU value is chosen larger than the It is possible that the original MTU value is chosen larger than the
actual MTU value along some portion of the path being traced. actual MTU value along some portion of the path being traced.
Therefore each intermediate RSVP router must check the MTU value when Therefore each intermediate RSVP node must check the MTU value when
processing a DREQ packet. If the specified MTU value is larger than processing a DREQ message. If the specified MTU value is larger than
the MTU of the incoming interface (that the DREQ packet will be the MTU of the incoming interface (that the DREQ message will be
forwarded to), the router forwarded to), the node
(1) sets the R-error value, (1) sets the R-error value,
(2) changes the MTU value in the header to the smaller value, and (2) changes the MTU value in the header to the smaller value, and
(3) converts the DREQ packet to a DREP and sends it back to the (3) converts the DREQ message to a DREP and sends it back to the
requester. requester.
In the rare case where some intermediate routers do not check, or In the rare case where some intermediate nodes do not check, or
enforce upon, the MTU value carried in the diagnostic packets, it is enforce upon, the MTU value carried in the diagnostic messages, it is
possible that on the way back to the requester, a DREP packet may possible that on the way back to the requester, a DREP message may
encounter a link of smaller MTU. encounter a link of smaller MTU.
When this happens, the router follows steps (1) and (2) as outlined When this happens, the node follows steps (1) and (2) as outlined
above, and trims off the extra part of the DREP packet to fit in the above, and trims off the extra part of the DREP message to fit in the
smaller MTU of the link. The trimming must be done at response smaller MTU of the link. The trimming must be done at response
object boundaries. Such trimming of packets results in information object boundaries. Such trimming of messages results in information
loss. However because the requester learns what is the available MTU loss. However because the requester learns what is the available MTU
size, it can either ignore the loss, or otherwise try again with the size, it can either ignore the loss, or otherwise try again with the
smaller MTU value. smaller MTU value.
4.4. Errors 4.4. Errors
If an error condition prevents a DREP packet from being forwarded If an error condition prevents a DREP message from being forwarded
further, the packet is simply dropped. further, 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
packet from being forwarded further, the router must change the message from being forwarded further, the node must change the
current packet to DREP type and return it to the response address. current message 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 packet forwarding. Let us Firewalls may cause problems in diagnostic message forwarding. Let
look at two different cases. us 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 session to be examined. In this case, firewalls should not the session to be examined. In this case, firewalls should not
prevent the forwarding of the diagnostic packets in a hop-by-hop prevent the forwarding of the diagnostic messages in a hop-by-hop
manner, assuming that proper holes have been punched on the firewall manner, assuming that proper holes have been punched on the firewall
to allow hop-by-hop forwarding of other RSVP packets. The querier to allow hop-by-hop forwarding of other RSVP messages. The querier
may start by setting the H flag off, which can give a faster response may start by setting the H flag off, which can give a faster response
delivery and reduced overhead at intermediate routers. However if no delivery and reduced overhead at intermediate nodes. However if no
response is received, the querier may resend the DREQ packet with H response is received, the querier may resend the DREQ message with H
flag turned on. flag turned on.
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-HOP address by a firewall (either the requester is behind a LAST-HOP address by a firewall (either the requester is behind a
firewall, or the LAST-HOP is a router behind a firewall, or both), at firewall, or the LAST-HOP is a node behind a firewall, or both), at
this time we do not know any other solution but to change the LAST- this time we do not know any other solution but to change the LAST-
HOP to a node that is on the same side of the firewall as the HOP to a node that is 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 RSVP hop along the way. This will be very helpful in situations each RSVP hop along the way. This will be very helpful in situations
when the reservation state goes up and down frequently, to find out when the reservation state goes up and down frequently, to find out
whether the state changes are due to improper setting of timer whether the state changes are due to improper setting of timer
values, or K values (when across lossy links), or frequent routing values, or K values (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 response data block shows the number of The D-TTL field in each DIAG_RESPONSE object shows the number of
routing hops between adjacent RSVP routers. Therefore any value routing hops between adjacent RSVP nodes. Therefore any value
greater than one indicates a non-RSVP clouds in between. Together greater than one indicates a non-RSVP clouds in between. Together
with the arrival timestamps (assuming NTP works), this value can also with the arrival timestamps (assuming NTP works), this value can also
give some vague, though not necessarily accurate, indication of how give some vague, though not necessarily accurate, indication of how
big that cloud might be. One might also find out all the big that cloud might be. One might also find out all the
intermediate non-RSVP routers by running either unicast or multicast intermediate non-RSVP nodes by running either unicast or multicast
trace route. trace route.
5.4. Discovering Reservation Merges 5.4. Discovering Reservation Merges
The flowspec value in a response data block 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 in the same data block. When this value of adjacent response spec in the same data block. When this value of adjacent
data blocks differs, that is, a downstream router Rd has a smaller DIAG_RESPONSE objects differs, that is, a downstream node Rd has a
value than its immediate upstream router Ru, it indicates a merge of smaller value than its immediate upstream node Ru, it indicates a
reservation with RSVP request(s) from other down stream interface(s) merge of reservation with RSVP request(s) from other down stream
at Rd. Further, in case of SE style reservation, one can examine how interface(s) at Rd. Further, in case of SE style reservation, one
the different SE scopes get merged at each hop. can examine how the different SE scopes get merged at each hop.
In particular, if a receiver sends a DREQ packet before sending its In particular, if a receiver sends a DREQ message before sending its
own reservation, it can discover (1) how many RSVP hops there are own reservation, it can discover (1) how many RSVP hops there are
along the path between the specified sender and itself, (2) how many along the path between the specified sender and itself, (2) how many
of the hops already have some reservation by other receivers, and (3) of the hops already have some reservation by other receivers, and (3)
possibly a rough prediction of how its reservation request might get possibly a rough prediction of how its reservation request might get
merged with other existing ones. merged with 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
diagnostic packets are more likely to be invoked when things are not diagnostic messages are more likely to be invoked when things are not
working correctly. For example, a receiver has reserved an adequate working correctly. For example, a receiver has reserved an adequate
pipe for a specified incoming data stream, yet the observed delay or pipe for a specified incoming data stream, yet the observed delay or
loss ratio is much higher than expected. In this case the receiver loss ratio is much higher than expected. In this case the receiver
can use the diagnostic facility to examine the reservation state at can use the diagnostic facility to examine the reservation state at
each RSVP hop along the way to find out whether the RSVP state is set each RSVP hop along the way to find out whether the RSVP state is set
up correctly, whether there is any blackhole along the way that up correctly, whether there is any blackhole along the way that
caused RSVP message losses, or whether there are non-RSVP clouds, and caused RSVP message losses, or whether there are non-RSVP clouds, and
where they are, that may have caused the performance problem. where they are, that may have caused the performance problem.
5.6. Crossing "Legacy" RSVP Routers 5.6. Crossing "Legacy" RSVP Routers
Given that this diagnosis function is developed and added to RSVP Since this diagnosis facility was developed and added to RSVP after a
after a number of RSVP implementations have been in place, it is number of RSVP implementations were in place, it is possible, or even
possible, or even likely, that when performing RSVP diagnosis, one likely, that when performing RSVP diagnosis, one may encounter one or
may encounter one or more RSVP-capable routers that do not understand more RSVP-capable nodes that do not understand diagnostic messages
diagnostic packets, thus drop them. When this happens, the invoking and drop them. When this happens, the invoking client will get no
client will get no response from its requests. response from its requests.
One way to by-pass such "legacy" RSVP routers is running an iteration One way to by-pass such "legacy" RSVP nodes is to perform RSVP
of RSVP diagnosis by using information from traceroute, or mtrace in diagnosis repeatedly, guided by information from traceroute, or
case of multicast. When an RSVP diagnostic query times out (see next mtrace in case of multicast. When an RSVP diagnostic query times out
section), one may first use traceroute to get the list of routers (see next section), one may first use traceroute to get the list of
along the path, and then gradually increases the value of Max-RSVP- nodes along the path, and then gradually increase the value of Max-
hops field in the DREQ packet, starting from a low value until one no RSVP-hops field in the DREQ message, starting from a low value until
longer receives a response. One can then try RSVP diagnosis again by one no longer receives a response. One can then try RSVP diagnosis
starting with the first router (which is further upstream towards the again by starting with the first node (which is further upstream
sender) after the unresponding one. towards the sender) after the unresponding one.
There are two problem with the method mentioned above in the case of
unicast sessions. Both problems are related to the fact that
traceroute information provides the path from the requester to the
sender. The first problem is that the LAST_HOP may not on the path
from the requester to the sender. In this case we can get information
only from the portion of the path from the LAST_HOP to the sender
which intersects with the path from the requester to the sender. If
routers that are not on the intersection of the two paths don't have
PATH state for the session being diagnosed then they will reply with
R-error=0x01. The requester can overcome this problem by sending a
DREQ to every router on the path (from itself to the sender) until it
reaches the first router that belongs to the path from the sender to
the LAST_HOP.
The second problem is that traceroute provides the path from the
requester to the sender which, due to routing asymmetries, may be
different than the path traffic from the sender to the LAST_HOP uses.
There are (at least) one case where this asymmetry will cause the
diagnosis to fail. We present this case below.
Downstream Path Sender
__ __ __ __
Receiver +------| |<------| |<-- ...---| |-----| |
__ __ / |__| |__| |__| |__|
| |--....--|X |_/ ^
|__| |__| Router B |
Black __ |
Hole +----->| |---->---+
|__| Upstream Path
Router A
Figure 2
Here the first hop upstream of the black hole is different on the
upstream path and the downstream path. Traceroute will indicate
router A as the previous hop (instead of router B which is the right
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 the
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 the
problematic scenarios described here.
6. Comments on Diagnostic Client Implementation. 6. Comments on Diagnostic Client Implementation.
Following the design principle that routers in the network should not Following the design principle that nodes in the network should not
hold more than necessary state, RSVP nodes are responsible only for hold more than necessary state, RSVP nodes are responsible only for
forwarding Diagnostic packets and filling Response Data Objects. forwarding Diagnostic messages and filling DIAG_RESPONSE objects.
Additional diagnostic functionalities should be carried out by the Additional diagnostic functionality should be carried out by the
Diagnostic Clients. Furthermore, if the diagnostic function is diagnostic clients. Furthermore, if the diagnostic function is
invoked from a third-party host, we should not not require that host invoked from a third-party host, we should not require that host be
be running RSVP daemon to perform the function. Below we sketch out running RSVP daemon to perform the function. Below we sketch out the
the basic functions that a diagnostic client daemon should carry out. basic functions that a 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 SELECT list, create a DREQ packet and send to the LAST-HOP the DIAG_SELECT list, create a DREQ message and send to the
RSVP node using raw IP packet with protocol number 46 (RSVP). LAST-HOP RSVP node using raw IP message with protocol number 46
The port of the UDP socket that the Diagnostic Client is (RSVP). The port of the UDP socket on which the Diagnostic
listening to for replies, should be included in the Response Client is listening for replies should be included in the
Address Filter-Spec. Requester FILTER_SPEC object.
2. Set a retransmission timer, waiting for the reply (one or more 2. Set a retransmission timer, waiting for the reply (one or more
DREP packets). Listen to the UDP port specified in the Response DREP messages). Listen to the specified UDP port for responses
Address Filter-Spec for responses from the LAST-HOP RSVP node. from the LAST-HOP RSVP node.
The LAST-HOP RSVP node upon receiving DREP packets sends them to The LAST-HOP RSVP node, upon receiving DREP messages, sends them
the the Diagnostic Client as UDP packets, using the port to the the Diagnostic Client as UDP packets, using the port
supplied to in the Response Address Filter-Spec. supplied in the Requester FILTER_SPEC object.
3. Upon receiving a DREP packet to an outstanding diagnostic 3. Upon receiving a DREP message to an outstanding diagnostic
request, the client should clear the retransmission timer, check request, the client should clear the retransmission timer, check
to see if the reply contains the complete result of the to see if the reply contains the complete result of the
requested diagnosis. If so, it should pass the result up to the requested diagnosis. If so, it should pass the result up to the
invoking entity immediately. invoking entity immediately.
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, the client should set up a reassembly timer in a way result, the client should set up a reassembly timer in a way
similar to IP packet reassembly timer. If the timer goes off similar to IP packet reassembly timer. If the timer goes off
before all fragments arrive, the client should pass the partial before all fragments arrive, the client should pass the partial
result to the invoking entity. result to the 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. In the absence of packet losses and reply fragment scenarios.
response to the first diagnostic request, a client should
retransmit the request a few times. If all the retransmissions In the absence of response to the first diagnostic request, a
also fail, the client should invoke traceroute or mtrace to client should retransmit the request a few times. If all the
obtain the list of hops along the path segment to be diagnosed, retransmissions also fail, the client should invoke traceroute
and then perform an iteration of diagnosis with increasing hop or mtrace to obtain the list of hops along the path segment to
count as suggested in Section 5.6 in order to cross RSVP-capable be diagnosed, and then perform an iteration of diagnosis with
but diagnosis-incapable routers. increasing hop count as suggested in Section 5.6 in order to
cross RSVP-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 entity. invoking 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 since it can reveal possibly sensitive RSVP state information threat since it can reveal possibly sensitive RSVP state information
to unwanted third parties. to 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
Introduction Diagnostics messages produce no side-effects and Introduction Diagnostics messages produce no side-effects and
therefore they cannot change RSVP state in the routers. In this therefore they cannot change RSVP state in the nodes. In this respect
respect RSVP Diagnostics is less a security threat than other RSVP Diagnostics is less a security threat than other diagnostic
diagnostic tools and protocols such as SNMP. tools and protocols such as SNMP.
Furthermore, processing of Diagnostic messages can be disabled if it Furthermore, processing of Diagnostic messages can be disabled if it
is felt that is a security threat. 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
suggested by Mark Handley of UCL. Many thanks to Lee Breslau of suggested by Mark Handley of UCL. Many thanks to Lee Breslau of
Xerox PARC and John Krawczyk of Baynetworks for their valuable Xerox PARC and John Krawczyk of Baynetworks for their valuable
comments on the first draft of this memo. Lee Breslau, Bob Braden, comments on the first draft of this memo. Lee Breslau, Bob Braden,
and John Krawczyk contributed further comments after March 1996 IETF. and John Krawczyk contributed further comments after March 1996 IETF.
Steven Berson provided valuable comments on various drafts of the Steven Berson provided valuable comments on various drafts of the
memo. We would also like to acknowledge Intel for providing a memo. We would also like to acknowledge Intel for providing a
research grant as a partial support for this work. research grant as a partial support for this work. Subramaniam
Vincent did most of this work while a graduate research assistant at
the USC Information Sciences Institute (ISI).
9. References 9. References
[RSVPTUN] L. Zhang, A. Terzis, "RSVP Operation Over IP Tunnels ", [RSVPTUN] A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang. "RSVP
Internet Draft draft-ietf-rsvp-tunnel-02.txt, November, 1997. Operation Over IP Tunnels ", Internet Draft draft-ietf-rsvp-tunnel-
03.txt, August, 1998.
10. Authors' Addresses 10. Authors' Addresses
Lixia Zhang Lixia Zhang
UCLA UCLA
4531G Boelter Hall 4531G Boelter Hall
Los Angeles, CA 90095 Los Angeles, CA 90095
Phone: 310-825-2695 Phone: 310-825-2695
EMail: lixia@cs.ucla.edu 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
skipping to change at line 870 skipping to change at page 21, line 24
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
Subramaniam Vincent Subramaniam Vincent
Cisco Systems
275, E Tasman Drive, MS SJC04/2/1
San Jose, CA 95134.
Phone: 408 525 3474
Email: svincent@cisco.com
Bob Braden
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: 310 822-1511
EMail: braden@isi.edu
 End of changes. 

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