Internet DRAFT - draft-ietf-rsvp-diagnostics-msgs
draft-ietf-rsvp-diagnostics-msgs
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 07:29:09 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 27 Nov 1996 00:20:00 GMT
ETag: "361bc4-78c7-329b8930"
Accept-Ranges: bytes
Content-Length: 30919
Connection: close
Content-Type: text/plain
Internet Draft Lixia Zhang
Expiration: April 1997 Andreas Terzis
File: draft-ietf-rsvp-diagnostic-msgs-02.txt UCLA
November, 1996
RSVP Diagnostic Messages
Status of Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
This draft describes the RSVP diagnosis facility. As the
deployment of RSVP is spreading out, it has become clear that
a method for collecting information about the RSVP state along
the path is needed. This specification describes the required
functionality, packet format, and processing rules.
1. Introduction
In the original design of RSVP, error messages are the only means for
the end hosts to receive feedback information regarding a specific
request that has failed, a failure in setting up either a PATH state
or reservation state. In the absence of failures, one receives no
feedback regarding the details of a reservation that has been put in
place, such as whether, or where, or how, one's own reservation
request is merged with that of others. In case of a failure, the
error message carries back only the information from the failed point,
without any information about the state at other hops before or after
the failure. Such missing information, however, can be highly desirable
for debugging purpose, or may even be interesting to end applications.
In this memo we specify an RSVP diagnostic facility 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. A diagnostic reply is not an error report, but a
collection of requested RSVP state information.
We have the following design goals in mind:
- To be able to collect RSVP state information at every hop along the
path once the PATH state has been set up, either for an existing
reservation or before a reservation request is made; here the "hop"
means RSVP-capable routers.
More specifically, we want to be able to collect information about
flowspec, 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 cloud
the path crosses.
- To avoid diagnostic packet implosion or explosion.
The following are specifically identified as non-goals:
- Checking the resource availability along a path. Such functionality
may be useful for future reservation requests, but would require
modifications to existing admission control module which is beyond
the scope of RSVP.
2. Overview
We define two types of diagnostic packets, diagnostic request (DREQ)
and reply (DREP). To avoid packet implosion or explosion,
we restrict all diagnostic packets to be unicast only (but see Section
5.2 on crossing firewalls). If the requesting host is at the receiving
end of the delivery path that is to be queried, it sends a DREQ packet
to the last-hop router of the path. If the requester is not a
receiving host, it simply sends the DREQ packet to some router on the
path. The DREQ packet specifies the RSVP session and a sending host
to that session. The router receiving the request adds to the DREQ
packet a response data object containing its RSVP state for the
specified RSVP session, and then forwards the request via unicast to
the router that it believes is the proper previous hop for the given
source. Each subsequent hop attaches its own response data object to
the end of the DREQ packet, then unicast-forwards to the previous
hop. When the DREQ packet reaches the sender, the sender changes
the packet type to Diagnostic Reply (DREP) and sends the completed
response to the original requester. The response may also be returned
before reaching the sender if any error condition along the path, such
as "no path state", prevents further forwarding of the request packet.
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
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
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 troublesome, especially when DREP packets are
returned to the requester hop-by-hop, in which case fragmentation/reassembly
would have to be performed at each 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 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
been set up. If no PATH state exists, one may resort to the traceroute
facility to examine whether the unicast/multicast routing is working
correctly.
3. Diagnostic Packet Format
A diagnostic packet consists of the following parts:
+-----------------------------------+
| RSVP common header |
+-----------------------------------+
| Diagnostic packet header object |
+-----------------------------------+
| session object |
+-----------------------------------+
| (optional) route object |
+-----------------------------------+
| one or more Response Object |
+-----------------------------------+
3.1 RSVP Message Common Header
In the RSVP message common header,
0 1 2 3
+-------------+-------------+-------------+-------------+
| 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
Type = 9: DREP
RSVP Checksum covers the entire packet body including this header.
The Checksum algorithm is the same as the one used in IP checksum, that
is it is:
The 16 bit one's complement of the one's complement sum of all the 16
bit words in the header. For purposes of computing the checksum, the value
of the checksum is zero.
Send_TTL: the IP TTL value that a router puts in the IP header when
forwarding the DREQ packet to the previous hop.
RSVP length: the total length of this diagnostic packet in bytes, including
the common header. If this is a DREP packet and the MF flag in 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
Both DREQ and DREP headers are a concatenation of Diagnostic Packet
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| multicast TTL | Reserved |H|MF|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+---------------+---------------+---------------+---------------+
| path MTU | Fragment offset |
+---------------+---------------+---------------+---------------+
| Sender Filter Spec |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAST-HOP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response Address |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ Followed by RSVP Session Object |
| |
Length is the length of this diagnostic header object.
Class = 30.
C-type field is used to distinguish between IPv4 (C-type = 1) and IPv6
(Ctype = 2). In the the IPv6 case adddreses will be 16 bytes each.
Max-RSVP-hops specifies the maximum number of RSVP hops that the
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 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
traversed so far.
Multicast TTL is used to limit the multicast scope when the response
address is a multicast address; see Section 5.2 for more details.
Otherwise this field must be set to zero.
The H flag indicates how the reply should be returned. When H = 0 and
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
packets. All DREP packets that are returned by intermediate routers rather
than the sender must set the MF flag to 1; when the sender converts a DREQ
packet to a DREP, the MF flag remains zero.
Message ID identifies an individual DREQ packet and corresponding
reply (or all the fragments of the reply).
The path MTU is a 16-bit field that specifies a default MTU size for
diagnostic packets.
Sender Filter-Spec is the IP address plus the port of the sender 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
end for the path being traced. The DREQ packet starts collecting
information at this node and proceeds toward the sender.
Response Address is the address to which the DREP packet(s) should be
sent. This Response Address does not necessarily specify the node that
initiates the DREQ packet, although most often it would.
The session object identifies the RSVP session for which the state
information is being collected.
Optionally, the diagnostic packet header may also contain a ROUTE object, as
defined below, immediately after the Session object. The ROUTE object is
to be used to return DREP packets hop-by-hop.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | class | c-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | R-pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ List of RSVP routers |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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),
but is incremented as each hop adds its incoming interface address in
the ROUTE object.
In a DREQ packet, List of RSVP routers lists all the RSVP hops 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
When receiving a DREQ packet, each RSVP router attaches a "response data"
object to it before forwarding on. The response data object is defined as
follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outgoing Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous-RSVP-Hop Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reservation style |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| D-TTL |M|R-err| K | timer value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Tspec object |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| filter spec object |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| flowspec object |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class = 32.
Ctype 1 and 2 specify whether this is an IPv4 or IPv6 response data,
respectively.
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
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 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 from
which the DREQ packet comes, and to which packets from the given sender
and for the specified session address flow, or 0 if unknown.
Previous-RSVP-Hop Router Address specifies the router from which this
router receives RSVP PATH messages from this source, or 0 if unknown.
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
three addresses will be 16 bytes each.
Reservation style is the 4-byte value of RSVP Style Object as defined in
RSVP specification.
D-TTL contains the routing hop count this DREQ packet traveled from the
down-stream RSVP router to the current router.
M is a single-bit flag which indicates whether the reservation, as
described by the objects below, is merged with reservations from other
downstream interfaces when being forwarded upstream.
R-error is a 3-bit field that indicates error conditions at a router.
Currently defined values are
0x00: no error
0x01: no PATH state
0x02: MTU too big
0x04: ROUTE object too big
K is the refresh timer parameter defined in RSVP, and timer value is the
local refresh timer value in seconds.
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). 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.1 DREQ Packet Forwarding
DREQ packets are forwarded via hop-by-hop unicast from the LAST-HOP
address to the Source address as specified in the diagnostic packet
header. Each hop performs the following processing before forwarding
the packet to the next hop towards the sender:
1 Compute the routing hop count from the previous RSVP hop.
This is done by subtracting the value of the TTL value in the IP header
from Send_TTL in RSVP common header. The result is then 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
the Response Data object.
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 interface for PATH
messages for the current router.
4 Attach the response data object to the end of the DREQ packet.
Tspec, filter spec, and flowspec objects in the response object describe
the reservation in place at the Outgoing Interface for the specified
session.
If no reservation state exists for the specified RSVP session, the
response object will contain no filter-spec or flowspec object; it should
still include the Tspec object for the specified sender that has been
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.
6 If any error bit is set, change the type field in RSVP common header
from DREQ to DREP, and send the packet back to either the LAST-HOP
address (if H = 1, or response address is a multicast address), or
to the response address directly via unicast (if H = 0).
7 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
current hop is the sender as identified by the "Source 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
margin to hold the address list object as described below, go to
Send_DREP().
9 If no error bit set ,then if the H-bit is set append the "Incoming
Interface Address" to the end of the ROUTE object, increment
R-Pointer by one and update the packet length field in the RSVP
common header accordingly.
Finally forward the DREQ packet to the next hop towards the
source.
Send_DREP():
1. If the H flag in the Diagnostic Header header is off,
set 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
common header from DREQ to DREP. If this host is not the source set
the MF flag on.
If the ROUTE object is so large such that
(size of ROUTE + size of response data object) > path MTU,
then set the "route too big" error bit, send the response packet,
and go to 7, else send the response packet.
3. If this host is not the source, then trim off all the response data
objects from the original DREQ packet, adjust the "Fragment offset"
value in the RSVP common header accordingly and forward the
modified DREQ packet towards the source.
4. Return.
4.2 DREP Forwarding
When the H flag is off, DREP packets are sent directly to the original
requester. When H flag is on, however, they are forwarded hop-by-hop
to 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
one (address length), and forward the packet to the address pointed by
R-pointer in the route list.
When the LAST-HOP router receives a DREP packet, it sends the
packet to the Response address.
4.3 MTU Selection and Adjustment
Because the DREQ packet carries the allowed MTU size of previous hops
that the DREP packets will later traverse, this unique feature allows
the easy semantic fragmentation as described above. Whenever the DREQ
packet grows to approach the size of MTU, it can be trimmed before
being forwarded again.
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.
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
packet to send back, and then trims off the partial results from 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
(1) sets the R-error value,
(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.
In rare case that some intermediate routers do not check, or enforce upon,
the MTU value carried in the diagnostic packets, it is possible that on the
way back to the requester, a DREP packet may encounter a link of smaller MTU.
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
further, the packet is simply dropped.
If an error condition, such as lack of PATH state, prevents a DREQ
packet from being forwarded further, the router must change the
current packet to DREP type and return it to the response address.
5. Problem Diagnosis by Using RSVP Diagnostic Facility
5.1 Broken Intermediate Router
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
look at two different cases.
First, let us assume that the querier is a receiving host of the
session to be examined. In this case, firewalls should not prevent
the forwarding of the diagnostic packets in a hop-by-hop manner,
assuming that proper holes have been punched on the firewall to allow
hop-by-hop forwarding of other RSVP packets. The querier may start by
setting the H flag off, which can give a faster response delivery and
reduced overhead at intermediate routers. However if no response is
received, the querier may resend the DREQ packet with H 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
should set the response address to a well-known multicast address
allocated specifically for DREP packets. In this case, all the reply
packets will be first unicast to the LAST-HOP address specified in the
diagnostic header, which in turn multicasts them out with a scope as
specified by the multicast TTL value in the Diagnostic Packet Header
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
One can easily collect information about the current timer value at 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 whether
the state changes are due to improper setting of timer values, or K
values (when across lossy links), or frequent routing changes.
5.3 Discovering Non-RSVP Clouds
The D-TTL field in each response data block shows the number of
routing hops between adjacent RSVP routers. Therefore any value
greater than one indicates a non-RSVP clouds in between. Together
with the arrival timestamps (assuming NTP works), this value can also
give some vague, though not necessarily accurate, indication of how
big that cloud might be. One might also find out all the intermediate
non-RSVP routers by running either unicast or multicast trace route.
5.4 Discovering Reservation Merges
The flowspec value in a response data block specifies the amount of
resources (whatever that means by the yet to be defined flowspec)
being reserved for the data stream defined by the filter spec in the
same data block. When this value of adjacent response data blocks
differs, that is, a downstream router Rd has a smaller value than its
immediate upstream router Ru, it indicates a merge of reservation with
RSVP request(s) from other down stream interface(s) at Rd.
Further, in case of SE style reservation, one can examine how the
different SE scopes get merged at each hop.
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
the path between the specified source and itself, (2)how many of
the hops already have some reservation by other receivers, and
(3)possibly foresee how its reservation request might get merged with
other existing ones.
5.5 Error Diagnosis
In addition to examining the state of a working reservation, RSVP
diagnostic packets are more likely to be invoked when things are not
working correctly. For example, a receiver has reserved an
adequate pipe for a specified incoming data stream, yet the observed
delay or loss ratio is much higher than expected. In this case the
receiver 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 up correctly, whether there is any blackhole along the way, or
whether there are non-RSVP clouds, and where, that may have caused the
performance problem.
6. Further Work
A missing piece from the current design is the handling of diagnostic
packets across routers that are RSVP-capable but do not support
RSVP diagnostic messages.
7. Acknowledgment
The idea of developing a diagnostic facility for RSVP was first
proposed by Mark Handley of UCL. Many thanks to Lee Breslau of Xerox
PARC and John Krawczyk of Baynetworks for their valuable comments on
the first draft of this memo. Lee and Bob Braden contributed further
comments after the LA IETF, and John Krawczyk caught a number of
errors just prior to this post. We would also like to thank Vincent
Subramanian for his comments on this second draft of the memo.
Authors' Addresses
Lixia Zhang
UCLA
4531G Boelter Hall
Los Angeles, CA 90024
Phone: 310-825-2695
EMail: lixia@cs.ucla.edu
Andreas Terzis
UCLA
4677 Boelter Hall
Los Angeles, CA 90024
Phone: 310-267-2190
Email: terzis@cs.ucla.edu
