draft-ietf-rsvp-diagnostic-msgs-02.txt   draft-ietf-rsvp-diagnostic-msgs-03.txt 
Internet Draft Lixia Zhang INTERNET-DRAFT Lixia Zhang
Expiration: April 1997 Andreas Terzis <draft-ietf-rsvp-diagnostic-msgs-03.txt> Andreas Terzis
File: draft-ietf-rsvp-diagnostic-msgs-02.txt UCLA Expiration: May 1998 UCLA
November, 1996 November 1997
RSVP Diagnostic Messages RSVP Diagnostic Messages
Status of Memo <draft-ietf-rsvp-diagnostic-msgs-03.txt>
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
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress".
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, 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 ds.internic.net (US East Coast), nic.nordu.net Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim). Rim).
Distribution of this memo is unlimited.
This Internet Draft expires in May, 1998.
Abstract Abstract
This draft describes the RSVP diagnosis facility. As the This document specifies the RSVP diagnosis facility. As the
deployment of RSVP is spreading out, it has become clear that deployment of RSVP is spreading out, it becomes clear that a method
a method for collecting information about the RSVP state along for collecting information about the RSVP state along the path is
the path is needed. This specification describes the required needed. This specification describes the functionality, diagnostic
functionality, packet format, and processing rules. message formats, and processing rules.
1. Introduction 1. Introduction
In the original design of RSVP, error messages are the only means for In the original design of the RSVP protocol, error messages are the
the end hosts to receive feedback information regarding a specific only means for the end hosts to receive feedback information
request that has failed, a failure in setting up either a PATH state regarding a specific request that has failed, a failure in setting up
or reservation state. In the absence of failures, one receives no either a PATH state or reservation state. In the absence of
feedback regarding the details of a reservation that has been put in failures, one receives no feedback regarding the details of a
place, such as whether, or where, or how, one's own reservation reservation that has been put in place, such as whether, or where, or
request is merged with that of others. In case of a failure, the how, one's own reservation request is merged with that of others. In
error message carries back only the information from the failed point, case of a failure, the error message carries back only the
without any information about the state at other hops before or after information from the failed point, without any information about the
the failure. Such missing information, however, can be highly desirable state at other hops before or after the failure. Such missing
for debugging purpose, or may even be interesting to end applications. information, however, can be highly desirable for debugging purpose,
or for network resource management in general.
In this memo we specify an RSVP diagnostic facility to collect information This document specifies RSVP diagnostic messages that allows one to
of RSVP state along the path from a receiver to a specific sender. collect information of RSVP state along the path from a receiver to a
Diagnostic messages are independent from any other RSVP control messages specific sender. Diagnostic messages are independent from any other
and produce no side-effects. That is, they do not change any RSVP state at RSVP control messages and produce no side-effects. That is, they do
either routers or hosts. A diagnostic reply is not an error report, but a not change any RSVP state at either routers or hosts. Similarly,
collection of requested RSVP state information. they do not represent an error report but a collection of RSVP state
information as requested.
We have the following design goals in mind: We have the following design goals in mind:
- To be able to collect RSVP state information at every hop along the - To be able to collect RSVP state information at every hop along
path once the PATH state has been set up, either for an existing the path where the PATH state has been set up, either for an
reservation or before a reservation request is made; here the "hop" existing reservation or before a reservation request is made;
means RSVP-capable routers. here the "hop" means RSVP-capable routers.
More specifically, we want to be able to collect information about More specifically, we want to be able to collect information
flowspec, refresh timer values, and reservation merging at each hop along about flowspec, refresh timer values, and reservation merging at
the path. each hop along the path.
- To be able to collect the routing hop count for each non-RSVP cloud - To be able to collect the routing hop count for each non-RSVP
the path crosses. 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 are specifically identified as non-goals:
- Checking the resource availability along a path. Such functionality - Checking the resource availability along a path. Such
may be useful for future reservation requests, but would require functionality may be useful for future reservation requests, but
modifications to existing admission control module which is beyond would require modifications to existing admission control module
the scope of RSVP. which is beyond the scope of RSVP.
2. Overview 2. Overview
We define two types of diagnostic packets, diagnostic request (DREQ) We define two types of RSVP diagnostic packets, diagnostic request
and reply (DREP). To avoid packet implosion or explosion, (DREQ) and reply (DREP). This diagnostic tool can be invoked by a
we restrict all diagnostic packets to be unicast only (but see Section client from any host that may or may not be a participant of the RSVP
5.2 on crossing firewalls). If the requesting host is at the receiving session to be diagnosed. Thus generally speaking three nodes are
end of the delivery path that is to be queried, it sends a DREQ packet involved in performing the diagnostic function: the requester, the
to the last-hop router of the path. If the requester is not a starting and the ending nodes of the diagnosis, as shown in Figure 1.
receiving host, it simply sends the DREQ packet to some router on the It is possible that the client invoking the diagnosis function may
path. The DREQ packet specifies the RSVP session and a sending host reside directly on the LAST-HOP, in which case that the first two
to that session. The router receiving the request adds to the DREQ nodes are the the same. The starting node of the diagnosis is named
packet a response data object containing its RSVP state for the "LAST-HOP", meaning the last-hop of the path segment to be diagnosed,
which can be either the receiving end or an intermediate router along
a reserved path. The ending node is the sender host in general,
although one can also limit the length of the path segment to be
diagnosed by specifying a hop-count limit for the diagnosis messages.
To avoid packet implosion or explosion, all diagnostic packets are
forwarded via unicast only.
A client invokes RSVP diagnostic functions by generating a DREQ
packet and sending to the LAST-HOP node which should be on the RSVP
path to be diagnosed. This DREQ packet specifies the RSVP session
and a sender host to that session. The DREQ packet starts collecting
information at the LAST-HOP node and proceeds toward the sender (see
Figure 1).
Receiver LAST-HOP Sender
__ __ __ __ __ __ __
| |---------| |------>| |-->| |-->| |-->| |---->| |
|__| |__| DREQ |__| |__| |__| |__| |__|
^
| RSVP routers
|
|request
_|_
| | Requester
|___|
Figure 1
Each RSVP-capable router receiving the DREQ packet adds to the packet
a response data object containing the router's RSVP state for the
specified RSVP session, and then forwards the request via unicast to specified RSVP session, and then forwards the request via unicast to
the router that it believes is the proper previous hop for the given the router that it believes to be the previous hop for the given
source. Each subsequent hop attaches its own response data object to sender. Each subsequent RSVP router attaches its own response data
the end of the DREQ packet, then unicast-forwards to the previous object to the end of the DREQ packet, then forwards via unicast to
hop. When the DREQ packet reaches the sender, the sender changes the previous hop. When the DREQ packet reaches the sender, the
the packet type to Diagnostic Reply (DREP) and sends the completed sender changes the packet type to Diagnostic Reply (DREP) and sends
response to the original requester. The response may also be returned the completed response to the original requester. Partial response
before reaching the sender if any error condition along the path, such may also be returned before the DREQ packet reaches the sender if any
as "no path state", prevents further forwarding of the request packet. error condition along the path, such as "no path state", prevents
further forwarding of the DREQ packet, or if the specified hop-count
for the diagnosis has been reached.
DREP packets can be unicast back to the requester either directly, or DREP packets can be unicast back to the requester either directly, or
in a hop-by-hop manner by reversing the exact path that the DREQ in a hop-by-hop manner by reversing the exact path that the DREQ
packet has taken. The former is faster and more efficient, but the packet has taken. The former is faster and more efficient, but the
latter may be the only choice if the packets have to cross firewalls. To latter may be the only choice if the packets have to cross firewalls,
facilitate the latter case, a DREQ packet may optionally carry a ROUTE due to the way that firewalls operate.
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 To facilitate the latter case, a DREQ packet may optionally carry a
of a DREP packet will exceed the path MTU size before reaching the sender, ROUTE object, which is a list of router addresses that the DREQ
thus the packet has to be fragmented. Relying on IP fragmentation and packet has passed through on the way to the sender; this ROUTE object
reassembly, however, can be troublesome, especially when DREP packets are is built incrementally as the DREQ packet passes through the
returned to the requester hop-by-hop, in which case fragmentation/reassembly intermediate routers. The DREP packet can then be returned to the
would have to be performed at each hop. To avoid such excessive overhead, requester by reversing the path.
we let the requester define a default path MTU size which is carried in
every DREQ packet. If an intermediate router believes that the default MTU
size is too big, it returns the DREQ packet with corresponding error bit
set. If an intermediate router detects that a DREQ packet size reaches the
MTU size, it trims off the partial result and returns it to the requester,
then forwards the trimmed DREQ packet to the next hop towards the sender.
Through out this memo we use the word "DREQ packet", rather the word
"message" to call a diagnostic request since it always consists of a single
packet. On the other hand, one DREQ packet can generate multiple DREP
packets, each containing a fragment of the total reply.
Notice that one can forward DREQ packets only after the RSVP PATH state has When the path consists of many hops, it is possible that the total
been set up. If no PATH state exists, one may resort to the traceroute length of a DREP packet will exceed the path MTU size before reaching
facility to examine whether the unicast/multicast routing is working the sender, thus the packet has to be fragmented. Relying on IP
correctly. 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
word "message" to call a diagnostic request since it always consists
of a single packet. On the other hand, one DREQ packet can generate
multiple DREP packets, each containing a fragment of the total reply.
Furthermore, when discussing diagnostic packet handling, the
terminology used refers to the direction of data packet flow, thus
"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.
Notice that one can forward DREQ packets only after the RSVP PATH
state has been set up. If no PATH state exists, one may resort to
the traceroute or mtrace facility to examine whether the
unicast/multicast routing is working correctly.
3. Diagnostic Packet Format 3. Diagnostic Packet Format
A diagnostic packet consists of the following parts: A diagnostic packet consists of the following parts:
+-----------------------------------+ +-----------------------------------+
| RSVP common header | | RSVP common header |
+-----------------------------------+ +-----------------------------------+
| Diagnostic packet header object | | Diagnostic packet header object |
+-----------------------------------+ +-----------------------------------+
| session object | | session object |
+-----------------------------------+ +-----------------------------------+
| (optional) route object | | (optional) SELECT object |
+-----------------------------------+ +-----------------------------------+
| one or more Response Object | | (optional) ROUTE object |
+-----------------------------------+
| zero or more Response Object |
+-----------------------------------+ +-----------------------------------+
3.1 RSVP Message Common Header 3.1. RSVP Message Common Header
In the RSVP message common header, In the RSVP message common header,
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Vers | Flags| Type | RSVP Checksum | | Vers | Flags| Type | RSVP Checksum |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Send_TTL | reserved | RSVP Length | | Send_TTL | reserved | RSVP Length |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at line 163 skipping to change at page 5, line 37
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Vers | Flags| Type | RSVP Checksum | | Vers | Flags| Type | RSVP Checksum |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Send_TTL | reserved | RSVP Length | | Send_TTL | reserved | RSVP Length |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
The Flags field is unused for now and must be set to zero. The Flags field is unused for now and must be set to zero.
Type = 8: DREQ Type = 8: DREQ
Type = 9: DREP Type = 9: DREP
RSVP Checksum covers the entire packet body including this header. The RSVP Checksum is the 16-bit one's complement of the one's
The Checksum algorithm is the same as the one used in IP checksum, that complement sum of the whole diagnosis message (including this
is it is: header). For computing the checksum, the checksum field is set to
The 16 bit one's complement of the one's complement sum of all the 16 zero. When receiving packets, the checksum MUST be verified before
bit words in the header. For purposes of computing the checksum, the value processing a packet.
of the checksum is zero.
Send_TTL: the IP TTL value that a router puts in the IP header when Send_TTL: the TTL value that a router puts in the IP packet header
forwarding the DREQ packet to the previous hop. when forwarding the DREQ packet to the previous hop.
RSVP length: the total length of this diagnostic packet in bytes, including RSVP length: the total length of this diagnostic packet in bytes,
the common header. If this is a DREP packet and the MF flag in diagnostic including the common header. If this is a DREP packet and the MF
packet header (see below) is set, this length field indicate the length of flag in the diagnostic packet header (see below) is set, this length
this single DREP fragment, rather than the total length of the field indicate the length of this single DREP fragment, rather than
the complete DREP reply (which may not be known in advance). the total length of the the complete DREP reply (which may not be
known in advance).
3.2 RSVP Diagnostic Packet Header Object 3.2. RSVP Diagnostic Packet Header Object
Both DREQ and DREP headers are a concatenation of Diagnostic Packet Both DREQ and DREP headers are a concatenation of Diagnostic Packet
Header Object and an RSVP Session object, as defined below: Header Object and an RSVP Session object, as defined below:
0 1 2 3 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 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 | | length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-RSVP-hops | RSVP-hop-count| multicast TTL | Reserved |H|MF| | Max-RSVP-hops | RSVP-hop-count| Reserved |H|MF|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| path MTU | Fragment offset | | path MTU | Fragment offset |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Sender Filter Spec | | |
| Sender Filter-Spec |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAST-HOP Address | | LAST-HOP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response Address | | |
| Response Address Filter-Spec |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Next-Hop RSVP_HOP Object |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| | | |
+ Followed by RSVP Session Object | + Followed by RSVP Session Object |
| | | |
Length is the length of this diagnostic header object. Length is the length of this diagnostic header object.
Class = 30. Class = 30.
C-type field is used to distinguish between IPv4 (C-type = 1) and IPv6 C-type field is used to distinguish between IPv4 (C-type = 1) and
(Ctype = 2). In the the IPv6 case adddreses will be 16 bytes each. IPv6 (Ctype = 2). In the IPv6 case addresses will be 16 bytes each.
Max-RSVP-hops specifies the maximum number of RSVP hops that the Max-RSVP-hops specifies the maximum number of RSVP hops that the
requester wants to collect information from. In case an error requester wants to collect information from. In case an error
condition in the middle of the path prevents the DREQ packet from condition in the middle of the path prevents the DREQ packet from
reaching the specified sender, one may use this field to perform an reaching the specified sender, one may use this field to perform an
expanding-length search to reach the point just before the problem. expanding-length search to reach the point just before the problem.
The fragment offset field indicates where in the total reply this fragment The fragment offset field indicates where in the total reply this
belongs. The fragment offset is measured in octets. The first fragment has fragment belongs. The fragment offset is measured in octets. The
offset zero. first fragment has offset zero.
RSVP-hop-count field records the number of RSVP hops that have been RSVP-hop-count field records the number of RSVP hops that have been
traversed so far. traversed so far.
Multicast TTL is used to limit the multicast scope when the response The H flag indicates how the reply should be returned. When H = 0,
address is a multicast address; see Section 5.2 for more details. DREP packets should be sent to the response address directly. If H =
Otherwise this field must be set to zero. 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
The H flag indicates how the reply should be returned. When H = 0 and DREP packets to the response address.
the response address is a unicast address, DREP packets should be sent
to the response address directly via unicast If H = 0 and the response
address is a multicast address, DREP packets should be sent to the LAST-HOP
address via unicast. 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 fragment". It must be set to zero in all DREQ The MF flag means "more fragments". It must be set to zero (0) on
packets. All DREP packets that are returned by intermediate routers rather all DREQ packets, and set to one (1) on all DREP packets that carry
than the sender must set the MF flag to 1; when the sender converts a DREQ partial results and are returned by intermediate routers due to the
packet to a DREP, the MF flag remains zero. 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 corresponding Message ID identifies an individual DREQ packet and the corresponding
reply (or all the fragments of the reply). 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 for The path MTU is a 16-bit field that specifies a default MTU size, in
diagnostic packets. number of bytes, that all diagnostic packets must fit within.
Sender Filter-Spec is the IP address plus the port of the sender being Sender Filter-Spec is the IP address plus the port of the sender
traced. The DREQ packet proceeds hop-by-hop towards this address. 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 LAST-HOP address is the IP address of the last hop at the receiving
end for the path being traced. The DREQ packet starts collecting end for the path being traced. The DREQ packet starts collecting
information at this node and proceeds toward the sender. information at this node and proceeds toward the sender.
Response Address is the address to which the DREP packet(s) should be Response Address Filter-Spec contains the IP address and the port to
sent. This Response Address does not necessarily specify the node that which the DREP packet(s) should be sent. This Response Address
initiates the DREQ packet, although most often it would. Filter-Spec specifies the process originating the request.
The Next-Hop RSVP_HOP object carries the IP address of the interface
to which the DREQ must be forwarded to. This object is updated on a
hop by hop basis, and is used for the same reasons that a RESV
message contains an RSVP_HOP object. That is, to distinguish logical
interfaces and avoid problems caused by routing asymmetries.
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. information is being collected.
Optionally, the diagnostic packet header may also contain a ROUTE object, as Optionally, the diagnostic packet may contain a SELECT object which
defined below, immediately after the Session object. The ROUTE object is carries a list of [Class, C-type] pairs, each pair specifies one type
to be used to return DREP packets hop-by-hop. 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:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| class | c-type | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field represents the total length of the object in number
of bytes.
Class = 33
C-type field is not used at the moment and must be set to zero.
The object payload part carries a list of [Class, C-type] pairs. In
case where the requested number of objects is an odd number, the last
two bytes must be set to zero.
Optionally, the diagnostic packet may also contain a ROUTE object, as
defined below. The ROUTE object is to be used to return DREP packets
hop-by-hop.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type | | length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | R-pointer | | reserved | R-pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ List of RSVP routers | + List of RSVP routers |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length field represents the total length of the object in number of The Length field represents the total length of the object in number
bytes, from which the number of addresses in the RSVP router list can be of bytes, from which the number of addresses in the RSVP router list
easily computed. can be easily computed.
Class = 31. Class = 31.
C-type field is used to distinguish between IPv4 (C-type = 1) and IPv6
(Ctype = 2) ROUTE object. C-type field is used to distinguish between IPv4 (C-type = 1) and
IPv6 (Ctype = 2) ROUTE object.
R-pointer is used in DREP packets only (see Section 4.2 for details), R-pointer is used in DREP packets only (see Section 4.2 for details),
but is incremented as each hop adds its incoming interface address in but is incremented as each hop adds its incoming interface address in
the ROUTE object. the ROUTE object.
In a DREQ packet, List of RSVP routers lists all the RSVP hops between the In a DREQ packet, the List of RSVP routers lists all the RSVP hops
LAST-HOP address, as specified in the Diagnostic packet header object, and between the LAST-HOP address, as specified in the Diagnostic packet
the last RSVP router the DREQ packet has visited. 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 In a DREP packet, List of RSVP routers lists all the RSVP hops
LAST-HOP and the router that returns this DREP packet. between the LAST-HOP and the router that returns this DREP packet.
3.3 Response Data Object 3.3. Response Data Object
When receiving a DREQ packet, each RSVP router attaches a "response data" When receiving a DREQ packet, each RSVP router attaches a "response
object to it before forwarding on. The response data object is defined as data" object to it before forwarding on. The response data object is
follows: defined as follows:
0 1 2 3 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 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 | | 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 | | reservation style |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| D-TTL |M|R-err| K | timer value | | D-TTL |M|R-err| K | timer value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| (TUNNEL object) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Tspec object | | Tspec object |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| filter spec object | | filter spec object |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| flowspec object | | flowspec object |
| | | |
skipping to change at line 334 skipping to change at page 10, line 40
| | | |
| filter spec object | | filter spec object |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| flowspec object | | flowspec object |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class = 32. Class = 32.
Ctype 1 and 2 specify whether this is an IPv4 or IPv6 response data, Ctype 1 and 2 specify whether this is an IPv4 or IPv6 response data,
respectively. respectively.
DREQ Arrival Time is a 32-bit NTP timestamp specifying the arrival DREQ Arrival Time is a 32-bit NTP timestamp specifying the arrival
time of the DREQ packet at this router. The 32-bit form of an NTP 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 timestamp consists of the middle 32 bits of the full 64-bit form;
is, the low 16 bits of the integer part and the high 16 bits of the that is, the low 16 bits of the integer part and the high 16 bits of
fractional part. the fractional part.
Incoming Interface Address specifies the IP address of the interface on Incoming Interface Address specifies the IP address of the interface
which packets from the sender, as defined in the Diagnostic Packet Header, on which packets from the sender, as defined in the Diagnostic Packet
are expected to arrive, or 0 if unknown. Header, are expected to arrive, or 0 if unknown.
Outgoing Interface Address specifies the IP address of the interface from Outgoing Interface Address specifies the IP address of the interface
which the DREQ packet comes, and to which packets from the given sender from which the DREQ packet comes, and to which packets from the given
and for the specified session address flow, or 0 if unknown. sender and for the specified session address flow, or 0 if unknown.
Previous-RSVP-Hop Router Address specifies the router from which this Previous-RSVP-Hop Router Address specifies the router from which this
router receives RSVP PATH messages from this source, or 0 if unknown. router receives RSVP PATH messages for this source, or 0 if unknown.
Notice that the response object format as shown above assumes IPv4 Notice that the response object format as shown above assumes IPv4
addresses of 4-byte each; in case of IPv6 (indicated by C-type = 2), these addresses of 4-byte each; in case of IPv6 (indicated by C-type = 2),
three addresses will be 16 bytes each. these three addresses will be 16 bytes each.
Reservation style is the 4-byte value of RSVP Style Object as defined in Reservation style is the 4-byte value of RSVP Style Object as defined
RSVP specification. in the RSVP specification.
D-TTL contains the routing hop count this DREQ packet traveled from the D-TTL contains the routing hop count this DREQ packet traveled from
down-stream RSVP router to the current router. the down-stream RSVP router to the current router.
M is a single-bit flag which indicates whether the reservation, as M is a single-bit flag which indicates whether the reservation, as
described by the objects below, is merged with reservations from other described by the objects below, is merged with reservations from
downstream interfaces when being forwarded upstream. other downstream interfaces when being forwarded upstream.
R-error is a 3-bit field that indicates error conditions at a router. R-error is a 3-bit field that indicates error conditions at a router.
Currently defined values are 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 the K is the refresh timer parameter defined in RSVP, and timer value is
local refresh timer value in seconds. the local refresh timer value in seconds.
The remaining parts, Tspec, filter spec, and flowspec objects follow the The next part, TUNNEL object, is an optional one which should be
definitions given in RSVP specification. The latter two may be absent inserted when a DREQ packet arrives at an RSVP router that acts as a
(see Section 4.1 on DREQ forwarding). Also note that the length of these tunnel exit point. The TUNNEL object provides mapping between the
object is varying so the lengths used on the diagram above are not end-to-end RSVP session that is being diagnosed and the RSVP session
representative. 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
[RSVPTUN], with the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Session object (for the end-to-end session) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Filter-Spec (for the tunnel sender) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SESSION_ASSOC Object
Class=192. Ctype 1 specifies IPv4 sessions, Ctype 2 specifies IPv6
sessions, and Ctypes 3 and 4 specify sessions with IPSEC Generalized
Port Id for IPv4 and IPv6 respectively.
The remaining parts, Tspec, filter spec, and flowspec objects follow
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
used on the diagram above are not representative.
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 packets are forwarded via hop-by-hop unicast from the LAST-HOP
address to the Source address as specified in the diagnostic packet address to the Sender address as specified in the diagnostic packet
header. Each hop performs the following processing before forwarding header. Each hop performs the following processing before forwarding
the packet to the next hop towards the sender: the packet to the next hop towards the sender:
1 Compute the routing hop count from the previous RSVP hop. 1. Compute the routing hop count from the previous RSVP hop. This
This is done by subtracting the value of the TTL value in the IP header is done by subtracting the value of the TTL value in the IP
from Send_TTL in RSVP common header. The result is then saved in the header from Send_TTL in RSVP common header. The result is then
D-TTL field of the response data object. saved in the D-TTL field of the response data object.
2 If no PATH state exists for the specified session, set R-error = 0x01 in 2. If no PATH state exists for the specified session, set R-error =
the Response Data object. 0x01 in the Response Data object.
3 If the path MTU value is too large, set "MTU too large" error bit, and 3. If the path MTU value is too large, set "MTU too large" error
change the MTU value to the MTU value of the incoming interface for PATH bit, and change the MTU value to the MTU value of the incoming
messages for the current router. interface for PATH messages for the current router.
4 Attach the response data object to the end of the DREQ packet. 4. Attach the response data object to the end of the DREQ packet.
Tspec, filter spec, and flowspec objects in the response object describe If the DREQ packet contains a SELECT object, attach one copy of
the reservation in place at the Outgoing Interface for the specified each of the objects specified in the SELECT. Otherwise attach
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. session.
If no reservation state exists for the specified RSVP session, the If no reservation state exists for the specified RSVP session,
response object will contain no filter-spec or flowspec object; it should the response object will contain no filter-spec or flowspec
still include the Tspec object for the specified sender that has been object.
carried to the router in the sender's PATH messages.
If neither PATH nor reservation state exists for the specified RSVP
session, then the response object contains none of the Tspec, filter
or flow spec object.
5 Increase the packet length field in the RSVP common header accordingly. If neither PATH nor reservation state exists for the specified
RSVP session, then the response object contains none of the
Tspec, filter or flow spec object.
6 If any error bit is set, change the type field in RSVP common header 5. If any error bit is set, change the type field in RSVP common
from DREQ to DREP, and send the packet back to either the LAST-HOP header from DREQ to DREP, recompute the checksum and send the
address (if H = 1, or response address is a multicast address), or packet back to either the LAST-HOP address (if H = 1), or to the
to the response address directly via unicast (if H = 0). response address directly via unicast (if H = 0).
7 Increment the RSVP-hop-count field in the diagnostic packet header by one. 6. Increment the RSVP-hop-count field in the diagnostic packet
header by one.
If the resulting value is equal to that of Max-RSVP-hops, or if the If the resulting value is equal to that of Max-RSVP-hops, or if
current hop is the sender as identified by the "Source Address" in the the current hop is the sender as identified by the "Source
RSVP diagnostic header, go to Send_DREP(), and then return. Address" in the RSVP diagnostic header, go to Send_DREP(), and
then return.
8 If the resulting DREQ packet size exceeds the MTU limit, minus some 7. If the resulting DREQ packet size exceeds the MTU limit, minus
margin to hold the address list object as described below, go to some margin to hold the address list object as described below,
Send_DREP(). go to Send_DREP().
9 If no error bit set ,then if the H-bit is set append the "Incoming 8. If no error bit set ,then if the H-bit is set, append the
Interface Address" to the end of the ROUTE object, increment "Incoming Interface Address" to the end of the ROUTE object,
R-Pointer by one and update the packet length field in the RSVP increment R-Pointer by one, update the Next-Hop RSVP_HOP object
common header accordingly. to be the Previous Hop from the Path State and update the packet
Finally forward the DREQ packet to the next hop towards the length field in the RSVP common header accordingly. Finally
source. forward the DREQ packet to the next hop towards the source,
after recomputing the checksum.
Send_DREP(): Send_DREP():
1. If the H flag in the Diagnostic Header header is off,
set target=response address given in the DREQ header, else 1. If the H flag in the Diagnostic Header header is off, set
set target = the last address in ROUTE. target=response address given in the DREQ header, else set
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 packet and change the type field in RSVP
common header from DREQ to DREP. If this host is not the source set common header from DREQ to DREP. If this host is not the source
the MF flag on. set the MF flag on.
If the ROUTE object is so large such that If the ROUTE object is so large such that (size of ROUTE + size
(size of ROUTE + size of response data object) > path MTU, of response data object) > path MTU, then set the "route too
then set the "route too big" error bit, send the response packet, big" error bit, recompute the checksum, send the response packet
and go to 7, else send the response packet. and go to 4, else recompute the checksum and send the response
packet.
3. If this host is not the source, then trim off all the response data 3. If this host is not the source, then trim off all the response
objects from the original DREQ packet, adjust the "Fragment offset" data objects from the original DREQ packet, adjust the "Fragment
value in the RSVP common header accordingly and forward the offset" value in the RSVP common header accordingly and forward
modified DREQ packet towards the source. the modified DREQ packet towards the source, after recomputing
the checksum.
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 original When the H flag is off, DREP packets are sent directly to the
requester. When H flag is on, however, they are forwarded hop-by-hop original requester. When H flag is on, however, they are forwarded
to the requester, by reversing the route as listed in the Route object. hop-by-hop towards the requester, by reversing the route as listed in
the Route object.
When a router receives a DREP packet, it simply decreases R-pointer by When a router receives a DREP packet, it simply decreases R-pointer
one (address length), and forward the packet to the address pointed by by one (address length), and forward the packet to the address
R-pointer in the route list. pointed by R-pointer in the route list.
When the LAST-HOP router receives a DREP packet, it sends the When the LAST-HOP router receives a DREP packet, it sends the packet
packet 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 packet carries the allowed MTU size of previous hops
that the DREP packets will later traverse, this unique feature allows that the DREP packets will later traverse, this unique feature allows
the easy semantic fragmentation as described above. Whenever the DREQ the easy semantic fragmentation as described above. Whenever the
packet grows to approach the size of MTU, it can be trimmed before DREQ packet grows to approach the size of MTU, it can be trimmed
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 packet, 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 packet size approaches the specified MTU value, an
intermediate RSVP router makes a copy of the packet, converts it to a DREP intermediate RSVP router makes a copy of the packet, converts it to a
packet to send back, and then trims off the partial results from DREQ DREP packet to send back, and then trims off the partial results from
packet and forwards it. DREQ packet and forwards it.
It is possible that the original MTU value is chosen larger than the
actual MTU value along some portion of the path being traced.
Therefore each intermediate RSVP router must check the MTU value when
processing a DREQ packet. If the specified MTU value is larger than
the MTU of the incoming interface (that the DREQ packet will be
forwarded to), the router
It is possible that the original MTU value is chosen larger than the actual
MTU value along some portion of the path being traced. Therefore each
intermediate RSVP router must check the MTU value when processing a DREQ
packet. If the specified MTU value is larger than the MTU of the incoming
interface (that the DREQ packet will be forwarded to), the router
(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 requester. (3) converts the DREQ packet to a DREP and sends it back to the
requester.
In rare case that some intermediate routers do not check, or enforce upon, In the rare case where some intermediate routers do not check, or
the MTU value carried in the diagnostic packets, it is possible that on the enforce upon, the MTU value carried in the diagnostic packets, it is
way back to the requester, a DREP packet may encounter a link of smaller MTU. possible that on the way back to the requester, a DREP packet may
When this happens, the router follows steps (1) and (2) as outlined above, encounter a link of smaller MTU.
and trims off the extra part of the DREP packet to fit in the smaller MTU of
the link. The trimming must be done at response object boundaries. Such
trimming of packets 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 When this happens, the router follows steps (1) and (2) as outlined
above, and trims off the extra part of the DREP packet to fit in the
smaller MTU of the link. The trimming must be done at response
object boundaries. Such trimming of packets 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
If an error condition prevents a DREP packet from being forwarded If an error condition prevents a DREP packet from being forwarded
further, the packet is simply dropped. further, the packet 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 packet from being forwarded further, the router must change the
current packet to DREP type and return it to the response address. current packet 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 Broken Intermediate Router 5.1. Across Firewalls
A broken (or legacy) intermediate RSVP router may simply not
understand diagnostic packets, and drop them. The querier would then
get no response at all from its requests. It may then choose to first
do a multicast traceroute (in case of multicast) to get information
about the route length, and then perform an RSVP diagnosis search
by gradually increasing the value of M_TTL field until it no longer
receives a response.
5.2 Across Firewalls
Firewalls can cause problems in diagnostic packet forwarding. Let us Firewalls may cause problems in diagnostic packet forwarding. Let us
look at two different cases. look at two different cases.
First, let us assume that the querier is a receiving host of the First, let us assume that the querier resides on a receiving host of
session to be examined. In this case, firewalls should not prevent the session to be examined. In this case, firewalls should not
the forwarding of the diagnostic packets in a hop-by-hop manner, prevent the forwarding of the diagnostic packets in a hop-by-hop
assuming that proper holes have been punched on the firewall to allow manner, assuming that proper holes have been punched on the firewall
hop-by-hop forwarding of other RSVP packets. The querier may start by to allow hop-by-hop forwarding of other RSVP packets. The querier
setting the H flag off, which can give a faster response delivery and may start by setting the H flag off, which can give a faster response
reduced overhead at intermediate routers. However if no response is delivery and reduced overhead at intermediate routers. However if no
received, the querier may resend the DREQ packet with H flag turned response is received, the querier may resend the DREQ packet with H
on. flag turned on.
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 firewall, or the
LAST-HOP is a router behind a firewall, or both), at this time I do not
know any other solution but attempting to use multicast.
To send a DREQ packet across a firewall (or firewalls), the request
should be multicast to the group being examined (since the last hop
router listens to that group). All routers except the correct last
hop router, as identified by the LAST-HOP address in the DREQ
header, should ignore any DREQ request received via multicast.
To receive a DREP packet across a firewall (or firewalls), the querier If the requester is a third party host and is separated from the
should set the response address to a well-known multicast address LAST-HOP address by a firewall (either the requester is behind a
allocated specifically for DREP packets. In this case, all the reply firewall, or the LAST-HOP is a router behind a firewall, or both), at
packets will be first unicast to the LAST-HOP address specified in the this time we do not know any other solution but to change the LAST-
diagnostic header, which in turn multicasts them out with a scope as HOP to a node that is on the same side of the firewall as the
specified by the multicast TTL value in the Diagnostic Packet Header requester.
Object. This multicast TTL scope should be set to a value sufficient
for the response from the LAST-HOP router to reach the querier.
However we must also carefully limit this value to a small number,
because there is only one well-known multicast address for this
purpose, therefore all the queriers from all other
sessions will receive the multicast DREP packets as well. If the
querier still cannot receive the DREP packet when the TTL reaches the
limit, then one must consider using a node closer to the LAST-HOP
address instead.
5.3 Examination of RSVP Timers 5.2. Examination of RSVP Timers
One can easily collect information about the current timer value at each One can easily collect information about the current timer value at
RSVP hop along the way. This will be very helpful in situations when each RSVP hop along the way. This will be very helpful in situations
the reservation state goes up and down frequently, to find out whether when the reservation state goes up and down frequently, to find out
the state changes are due to improper setting of timer values, or K whether the state changes are due to improper setting of timer
values (when across lossy links), or frequent routing changes. values, or K values (when across lossy links), or frequent routing
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 response data block shows the number of
routing hops between adjacent RSVP routers. Therefore any value routing hops between adjacent RSVP routers. 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 intermediate big that cloud might be. One might also find out all the
non-RSVP routers by running either unicast or multicast trace route. intermediate non-RSVP routers by running either unicast or multicast
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 response data block specifies the amount of
resources (whatever that means by the yet to be defined flowspec) resources being reserved for the data stream defined by the filter
being reserved for the data stream defined by the filter spec in the spec in the same data block. When this value of adjacent response
same data block. When this value of adjacent response data blocks data blocks differs, that is, a downstream router Rd has a smaller
differs, that is, a downstream router Rd has a smaller value than its value than its immediate upstream router Ru, it indicates a merge of
immediate upstream router Ru, it indicates a merge of reservation with reservation with RSVP request(s) from other down stream interface(s)
RSVP request(s) from other down stream interface(s) at Rd. at Rd. Further, in case of SE style reservation, one can examine how
Further, in case of SE style reservation, one can examine how the the different SE scopes get merged at each hop.
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 packet before sending its
own reservation, it can discover (1)how many RSVP hops there are along own reservation, it can discover (1) how many RSVP hops there are
the path between the specified source and itself, (2)how many of along the path between the specified sender and itself, (2) how many
the hops already have some reservation by other receivers, and of the hops already have some reservation by other receivers, and (3)
(3)possibly foresee how its reservation request might get merged with possibly a rough prediction of how its reservation request might get
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 packets are more likely to be invoked when things are not
working correctly. For example, a receiver has reserved an working correctly. For example, a receiver has reserved an adequate
adequate pipe for a specified incoming data stream, yet the observed pipe for a specified incoming data stream, yet the observed delay or
delay or loss ratio is much higher than expected. In this case the loss ratio is much higher than expected. In this case the receiver
receiver can use the diagnostic facility to examine the reservation can use the diagnostic facility to examine the reservation state at
state at each RSVP hop along the way to find out whether the RSVP state is each RSVP hop along the way to find out whether the RSVP state is set
set up correctly, whether there is any blackhole along the way, or up correctly, whether there is any blackhole along the way that
whether there are non-RSVP clouds, and where, that may have caused the caused RSVP message losses, or whether there are non-RSVP clouds, and
performance problem. where they are, that may have caused the performance problem.
6. Further Work 5.6. Crossing "Legacy" RSVP Routers
A missing piece from the current design is the handling of diagnostic Given that this diagnosis function is developed and added to RSVP
packets across routers that are RSVP-capable but do not support after a number of RSVP implementations have been in place, it is
RSVP diagnostic messages. possible, or even likely, that when performing RSVP diagnosis, one
may encounter one or more RSVP-capable routers that do not understand
diagnostic packets, thus drop them. When this happens, the invoking
client will get no response from its requests.
7. Acknowledgment One way to by-pass such "legacy" RSVP routers is running an iteration
of RSVP diagnosis by using information from traceroute, or mtrace in
case of multicast. When an RSVP diagnostic query times out (see next
section), one may first use traceroute to get the list of routers
along the path, and then gradually increases the value of Max-RSVP-
hops field in the DREQ packet, starting from a low value until one no
longer receives a response. One can then try RSVP diagnosis again by
starting with the first router (which is further upstream towards the
sender) after the unresponding one.
6. Comments on Diagnostic Client Implementation.
Following the design principle that routers in the network should not
hold more than necessary state, RSVP nodes are responsible only for
forwarding Diagnostic packets and filling Response Data Objects.
Additional diagnostic functionalities should be carried out by the
Diagnostic Clients. Furthermore, if the diagnostic function is
invoked from a third-party host, we should not not require that host
be running RSVP daemon to perform the function. Below we sketch out
the basic functions that a diagnostic client daemon should carry out.
1. Take input from the user about the session to be diagnosed, the
last-hop and the sender address, the Max-RSVP-hops, and possibly
the SELECT list, create a DREQ packet and send to the LAST-HOP
RSVP node using raw IP packet with protocol number 46 (RSVP).
The port of the UDP socket that the Diagnostic Client is
listening to for replies, should be included in the Response
Address Filter-Spec.
2. Set a retransmission timer, waiting for the reply (one or more
DREP packets). Listen to the UDP port specified in the Response
Address Filter-Spec for responses from the LAST-HOP RSVP node.
The LAST-HOP RSVP node upon receiving DREP packets sends them to
the the Diagnostic Client as UDP packets, using the port
supplied to in the Response Address Filter-Spec.
3. Upon receiving a DREP packet 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 immediately.
4. Reassemble DREP fragments. If the first reply to an outstanding
diagnostic request contains only a fragment of the expected
result, the client should set up a reassembly timer in a way
similar to IP packet reassembly timer. If the timer goes off
before all fragments arrive, the client should pass the partial
result to the invoking entity.
5. Use retransmission and reassembly timers to gracefully handle
packet losses and reply fragment scenarios. In the absence of
response to the first diagnostic request, a client should
retransmit the request a few times. If all the retransmissions
also fail, the client should invoke traceroute or mtrace to
obtain the list of hops along the path segment to be diagnosed,
and then perform an iteration of diagnosis with increasing hop
count as suggested in Section 5.6 in order to cross RSVP-capable
but diagnosis-incapable routers.
6. If all the above efforts fail, the client must notify the
invoking entity.
7. Acknowledgments
The idea of developing a diagnostic facility for RSVP was first The idea of developing a diagnostic facility for RSVP was first
proposed by Mark Handley of UCL. Many thanks to Lee Breslau of Xerox suggested by Mark Handley of UCL. Many thanks to Lee Breslau of
PARC and John Krawczyk of Baynetworks for their valuable comments on Xerox PARC and John Krawczyk of Baynetworks for their valuable
the first draft of this memo. Lee and Bob Braden contributed further comments on the first draft of this memo. Lee Breslau, Bob Braden,
comments after the LA IETF, and John Krawczyk caught a number of and John Krawczyk contributed further comments after March 1996 IETF.
errors just prior to this post. We would also like to thank Vincent Vincent Subramaniam and Steven Berson provided valuable comments on
Subramanian for his comments on this second draft of the memo. variable drafts of the memo. We would also like to acknowledge Intel
for providing a research grant as a partial support for this work.
Authors' Addresses 8. References
[RSVPTUN] L. Zhang, A. Terzis, "RSVP Operation Over IP Tunnels ",
Internet Draft draft-ietf-rsvp-tunnel-02.txt, November, 1997.
9. Authors' Addresses
Lixia Zhang Lixia Zhang
UCLA UCLA
4531G Boelter Hall 4531G Boelter Hall
Los Angeles, CA 90024 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 90024 Los Angeles, CA 90095
Phone: 310-267-2190 Phone: 310-267-2190
Email: terzis@cs.ucla.edu Email: terzis@cs.ucla.edu
 End of changes. 

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