draft-ietf-rsvp-diagnostic-msgs-07.txt   rfc2745.txt 
INTERNET-DRAFT Andreas Terzis Network Working Group A. Terzis
Expires: October 1999 UCLA Request for Comments: 2745 UCLA
<draft-ietf-rsvp-diagnostic-msgs-07.txt> Bob Braden Category: Standards Track B. Braden
ISI ISI
Subramaniam Vincent S. Vincent
Cisco Systems Cisco Systems
Lixia Zhang L. Zhang
UCLA UCLA
April 1999 January 2000
RSVP Diagnostic Messages
<draft-ietf-rsvp-diagnostic-msgs-07.txt> RSVP Diagnostic Messages
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
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."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2000). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This document specifies the RSVP diagnostic facility, which allows a This document specifies the RSVP diagnostic facility, which allows a
user to collect information about the RSVP state along a path. This user to collect information about the RSVP state along a path. This
specification describes the functionality, diagnostic message specification describes the functionality, diagnostic message
formats, and processing rules. formats, and processing rules.
Changes
A summary of the changes from the previous version (06) of this
document follows:
-Some editorial changes were made, using input from Tim Gleeson.
The technical content of the document has not changed from the
previous version.
1. Introduction 1. Introduction
In the basic RSVP protocol [RSVP], error messages are the only means In the basic RSVP protocol [RSVP], error messages are the only means
for an end host to receive feedback regarding a failure in setting up for an end host to receive feedback regarding a failure in setting up
either path state or reservation state. An error message carries either path state or reservation state. An error message carries
back only the information from the failed point, without any back only the information from the failed point, without any
information about the state at other hops before or after the information about the state at other hops before or after the
failure. In the absence of failures, a host receives no feedback failure. In the absence of failures, a host receives no feedback
regarding the details of a reservation that has been put in place, regarding the details of a reservation that has been put in place,
such as whether, or where, or how, its own reservation request is such as whether, or where, or how, its own reservation request is
skipping to change at page 2, line 39 skipping to change at page 2, line 16
designed to fill this information gap. The diagnostic facility can designed to fill this information gap. The diagnostic facility can
be used to collect and report RSVP state information along the path be used to collect and report RSVP state information along the path
from a receiver to a specific sender. It uses Diagnostic messages from a receiver to a specific sender. It uses Diagnostic messages
that are independent of other RSVP control messages and produce no that are independent of other RSVP control messages and produce no
side-effects; that is, they do not change any RSVP state at either side-effects; that is, they do not change any RSVP state at either
nodes or hosts. Similarly, they provide not an error report but nodes or hosts. Similarly, they provide not an error report but
rather a collection of requested RSVP state information. rather a collection of requested RSVP state information.
The RSVP diagnostic facility was designed with the following goals: The RSVP diagnostic facility was designed with the following goals:
- To collect RSVP state information from every RSVP-capable hop - To collect RSVP state information from every RSVP-capable hop
along a path defined by path state, either for an existing along a path defined by path state, either for an existing
reservation or before a reservation request is made. More reservation or before a reservation request is made. More
specifically, we want to be able to collect information about specifically, we want to be able to collect information about
flowspecs, refresh timer values, and reservation merging at each flowspecs, refresh timer values, and reservation merging at each
hop along the path. hop along the path.
- To collect the IP hop count across each non-RSVP cloud. - To collect the IP hop count across each non-RSVP cloud.
- To avoid diagnostic packet implosion or explosion. - To avoid diagnostic packet implosion or explosion.
The following is specifically identified as a non-goal: The following is specifically identified as a non-goal:
- Checking the resource availability along a path. Such - Checking the resource availability along a path. Such
functionality may be useful for future reservation requests, but functionality may be useful for future reservation requests, but
it would require modifications to existing admission control it would require modifications to existing admission control
modules that is beyond the scope of RSVP. modules that is beyond the scope of RSVP.
2. Overview 2. Overview
The diagnostic facility introduces two new RSVP message types: The diagnostic facility introduces two new RSVP message types:
Diagnostic Request (DREQ) and Diagnostic Reply (DREP). A DREQ Diagnostic Request (DREQ) and Diagnostic Reply (DREP). A DREQ
message can be originated by a client in a "requester" host, which message can be originated by a client in a "requester" host, which
may or may not be a participant of the RSVP session to be diagnosed. may or may not be a participant of the RSVP session to be diagnosed.
A client in the requester host invokes the RSVP diagnostic facility A client in the requester host invokes the RSVP diagnostic facility
by generating a DREQ packet and sending it towards the LAST-HOP node, by generating a DREQ packet and sending it towards the LAST-HOP node,
which should be on the RSVP path to be diagnosed. This DREQ packet which should be on the RSVP path to be diagnosed. This DREQ packet
skipping to change at page 4, line 5 skipping to change at page 3, line 25
starting node, and the ending node, as shown in Figure 1. It is starting node, and the ending node, as shown in Figure 1. It is
possible that the client invoking the diagnosis function may reside possible that the client invoking the diagnosis function may reside
directly on the starting node, in which case that the first two nodes directly on the starting node, in which case that the first two nodes
are the same. The starting node is named "LAST-HOP", meaning the are the same. The starting node is named "LAST-HOP", meaning the
last-hop of the path segment to be diagnosed. The LAST-HOP node can last-hop of the path segment to be diagnosed. The LAST-HOP node can
be either a receiver node or an intermediate node along the path. be either a receiver node or an intermediate node along the path.
The ending node is usually the specified sender host. However, the The ending node is usually the specified sender host. However, the
client can limit the length of the path segment to be diagnosed by client can limit the length of the path segment to be diagnosed by
specifying a hop-count limit in the DREQ message. specifying a hop-count limit in the DREQ message.
LAST-HOP Ending LAST-HOP Ending
Receiver node node Sender Receiver node node Sender
__ __ __ __ __ __ __ __ __ __
| |---------| |------>| |--> ...-->| |--> ...---->| | | |---------| |------>| |--> ...-->| |--> ...---->| |
|__| |__| DREQ |__| DREQ |__| DREQ |__| |__| |__| DREQ |__| DREQ |__| DREQ |__|
^ . | ^ . |
| . | | . |
| DREQ . DREP | DREP | DREQ . DREP | DREP
| . | | . |
_|_ DREP V V _|_ DREP V V
Requester | | <------------------------------------ Requester | | <------------------------------------
(client) |___| (client) |___|
Figure 1 Figure 1
DREP packets can be unicast from the ending node back to the DREP packets can be unicast from the ending node back to the
requester either directly or hop-by-hop along the reverse of the path requester either directly or hop-by-hop along the reverse of the path
taken by the DREQ message to the LAST-HOP, and thence to the taken by the DREQ message to the LAST-HOP, and thence to the
requester. The direct return is faster and more efficient, but the requester. The direct return is faster and more efficient, but the
hop-by-hop reverse-path route may be the only choice if the packets hop-by-hop reverse-path route may be the only choice if the packets
have to cross firewalls. Hop-by-hop return is accomplished using an have to cross firewalls. Hop-by-hop return is accomplished using an
optional ROUTE object, which is built incrementally to contain a list optional ROUTE object, which is built incrementally to contain a list
of node addresses that the DREQ packet has passed through. The ROUTE of node addresses that the DREQ packet has passed through. The ROUTE
object is then used in reverse as a source route to forward the DREP object is then used in reverse as a source route to forward the DREP
skipping to change at page 5, line 26 skipping to change at page 5, line 5
state has been set up. If no path state exists, one may resort to state has been set up. If no path state exists, one may resort to
the traceroute or mtrace facility to examine whether the the traceroute or mtrace facility to examine whether the
unicast/multicast routing is working correctly. unicast/multicast routing is working correctly.
3. Diagnostic Packet Format 3. Diagnostic Packet Format
Like other RSVP messages, DREQ and DREP messages consist of an RSVP Like other RSVP messages, DREQ and DREP messages consist of an RSVP
Common Header followed by a variable set of typed RSVP data objects. Common Header followed by a variable set of typed RSVP data objects.
The following sequence must be used: The following sequence must be used:
+-----------------------------------+ +-----------------------------------+
| RSVP Common Header | | RSVP Common Header |
+-----------------------------------+ +-----------------------------------+
| Session object | | Session object |
+-----------------------------------+ +-----------------------------------+
| Next-Hop RSVP_HOP object | | Next-Hop RSVP_HOP object |
+-----------------------------------+ +-----------------------------------+
| DIAGNOSTIC object | | DIAGNOSTIC object |
+-----------------------------------+ +-----------------------------------+
| (optional) DIAG_SELECT object | | (optional) DIAG_SELECT object |
+-----------------------------------+ +-----------------------------------+
| (optional) ROUTE object | | (optional) ROUTE object |
+-----------------------------------+ +-----------------------------------+
| zero or more DIAG_RESPONSE objects| | zero or more DIAG_RESPONSE objects|
+-----------------------------------+ +-----------------------------------+
The session object identifies the RSVP session for which the state The session object identifies the RSVP session for which the state
information is being collected. We describe each of the other parts. information is being collected. We describe each of the other parts.
3.1. RSVP Message Common Header 3.1. RSVP Message Common Header
The RSVP message common header is defined in [RSVP]. The following The RSVP message common header is defined in [RSVP]. The following
specific exceptions and extensions are needed for DREP and DREQ. specific exceptions and extensions are needed for DREP and DREQ.
Type field: define: Type field: define:
Type = 8: DREQ Diagnostic Request Type = 8: DREQ Diagnostic Request
Type = 9: DREP Diagnostic Reply Type = 9: DREP Diagnostic Reply
RSVP length: RSVP length:
If this is a DREP message and the MF flag in the DIAGNOSTIC object If this is a DREP message and the MF flag in the DIAGNOSTIC object
(see below) is set, this field indicates the length of this single (see below) is set, this field indicates the length of this single
DREP fragment rather than the total length of the complete DREP DREP fragment rather than the total length of the complete DREP
reply message (which cannot generally be known in advance). reply message (which cannot generally be known in advance).
3.2. Next-Hop RSVP_HOP Object 3.2. Next-Hop RSVP_HOP Object
This RSVP_HOP object carries the LIH of the interface through which This RSVP_HOP object carries the LIH of the interface through which
the DREQ should be received at the upstream node. This object is the DREQ should be received at the upstream node. This object is
updated hop-by hop. It is used for the same reasons that a RESV updated hop-by hop. It is used for the same reasons that a RESV
message contains an RSVP_HOP object: to distinguish logical message contains an RSVP_HOP object: to distinguish logical
interfaces and avoid problems caused by routing asymmetries and non- interfaces and avoid problems caused by routing asymmetries and non-
RSVP clouds. RSVP clouds.
While the IP address is not really used during DREQ processing , for While the IP address is not really used during DREQ processing, for
consistency with the use of the RSVP_HOP object in other RSVP consistency with the use of the RSVP_HOP object in other RSVP
messages, the IP address in the RSVP_HOP object to contain the messages, the IP address in the RSVP_HOP object to contain the
address of the interface through which the DREQ was sent. address of the interface through which the DREQ was sent.
3.3. DIAGNOSTIC Object 3.3. DIAGNOSTIC Object
A DIAGNOSTIC object contains the common diagnostic control A DIAGNOSTIC object contains the common diagnostic control
information in both DREQ and DREP messages. information in both DREQ and DREP messages.
o IPv4 DIAGNOSTIC object: Class = 30, C-Type = 1 o IPv4 DIAGNOSTIC object: Class = 30, C-Type = 1
skipping to change at page 8, line 9 skipping to change at page 7, line 18
RSVP-hop-count RSVP-hop-count
Records the number of RSVP hops that have been traversed so far. Records the number of RSVP hops that have been traversed so far.
If the starting and ending nodes are the same, this value will be If the starting and ending nodes are the same, this value will be
1 in the resulting DREP message. 1 in the resulting DREP message.
Fragment Offset Fragment Offset
Indicates where this DREP fragment belongs in the complete DREP Indicates where this DREP fragment belongs in the complete DREP
message, measured in octets. The first fragment has offset zero. message, measured in octets. The first fragment has offset zero.
Fragment Offset is used to determine if a DREQ message containing Fragment Offset is used also to determine if a DREQ message
zero DIAG_RESPONSE objects should be processed at an RSVP capable containing zero DIAG_RESPONSE objects should be processed at an
node. RSVP capable node.
MF flag MF flag
Flag means "more fragments". It must be set to zero (0) in all Flag means "more fragments". It must be set to zero (0) in all
DREQ messages. It must be set to one (1) in all DREP packets that DREQ messages. It must be set to one (1) in all DREP packets that
carry partial results and are returned by intermediate nodes due carry partial results and are returned by intermediate nodes due
to the MTU limit. When the DREQ message is converted to a DREP to the MTU limit. When the DREQ message is converted to a DREP
message in the ending node, the MF flag must remain zero. message in the ending node, the MF flag must remain zero.
Request ID Request ID
skipping to change at page 8, line 35 skipping to change at page 7, line 44
One possible way to define the Request ID would use 16 bits to One possible way to define the Request ID would use 16 bits to
specify the ID of the process making the query and 16 bits to specify the ID of the process making the query and 16 bits to
distinguish different queries from this process. distinguish different queries from this process.
Path MTU Path MTU
Specifies a default MTU size in octets for DREP and DREQ messages. Specifies a default MTU size in octets for DREP and DREQ messages.
This value should not be smaller than the size of the "base" DREQ This value should not be smaller than the size of the "base" DREQ
packet. A "base" DREQ packet is one that contains a Common Header, packet. A "base" DREQ packet is one that contains a Common Header,
a Session object , a Next-Hop RSVP_HOP object, a DIAGNOSTIC a Session object, a Next-Hop RSVP_HOP object, a DIAGNOSTIC object,
object, an empty ROUTE object and a single default DIAG_RESPONSE an empty ROUTE object and a single default DIAG_RESPONSE (see
(see below). The assumption made here is that a diagnostic packet below). The assumption made here is that a diagnostic packet of
of this size can always be forwarded without being fragmented. this size can always be forwarded without IP fragmentation.
LAST-HOP Address LAST-HOP Address
The IP address of the LAST-HOP node. The DREQ message starts The IP address of the LAST-HOP node. The DREQ message starts
collecting information at this node and proceeds toward the collecting information at this node and proceeds toward the
sender. sender.
SENDER_TEMPLATE object SENDER_TEMPLATE object
This IPv4/IPv6 SENDER_TEMPLATE object contains the IP address and This IPv4/IPv6 SENDER_TEMPLATE object contains the IP address and
skipping to change at page 9, line 13 skipping to change at page 8, line 25
packet is forwarded hop-by-hop towards this address. packet is forwarded hop-by-hop towards this address.
Requester FILTER_SPEC Object Requester FILTER_SPEC Object
This IPv4/IPv6 FILTER_SPEC object contains the IP address and the This IPv4/IPv6 FILTER_SPEC object contains the IP address and the
port from which the request originated and to which the DREP port from which the request originated and to which the DREP
message(s) should be sent. message(s) should be sent.
3.4. DIAG_SELECT Object 3.4. DIAG_SELECT Object
o DIAG_SELECT Class = 33, C-Type = 0. o DIAG_SELECT Class = 33, C-Type = 1.
A Diagnostic message may optionally contain a DIAG_SELECT object to A Diagnostic message may optionally contain a DIAG_SELECT object to
specify which specific RSVP objects should be reported in a specify which specific RSVP objects should be reported in a
DIAG_RESPONSE object. In the absence of a DIAG_SELECT object, the DIAG_RESPONSE object. In the absence of a DIAG_SELECT object, the
DIAG_RESPONSE object added by the node will contain a default set of DIAG_RESPONSE object added by the node will contain a default set of
object types (see DIAG_RESPONSE object below). object types (see DIAG_RESPONSE object below).
The DIAG_SELECT object contains a list of [Class, C-type] pairs, in The DIAG_SELECT object contains a list of [Class, C-type] pairs, in
the following format: the following format:
skipping to change at page 9, line 43 skipping to change at page 9, line 9
node along the path will add a DIAG_RESPONSE object containing node along the path will add a DIAG_RESPONSE object containing
response objects (see below) whose classes and C-Types match entries response objects (see below) whose classes and C-Types match entries
in the DIAG_SELECT list (and are from matching path and reservation in the DIAG_SELECT list (and are from matching path and reservation
state). A C-type octet of zero is a 'wildcard', matching any C-Type state). A C-type octet of zero is a 'wildcard', matching any C-Type
associated with the associated class. associated with the associated class.
Depending on the type of objects requested, a node can find the Depending on the type of objects requested, a node can find the
associated information in the path or reservation state stored for associated information in the path or reservation state stored for
the session described in the SESSION object. Specifically, the session described in the SESSION object. Specifically,
information for the RSVP_HOP,SENDER_TEMPLATE, SENDER_TSPEC, ADSPEC information for the RSVP_HOP,SENDER_TEMPLATE, SENDER_TSPEC, ADSPEC
and FILTER_SPEC objects can be extracted from the node's path state, objects can be extracted from the node's path state, while
while information for the FLOWSPEC, CONFIRM, STYLE and SCOPE objects information for the FLOWSPEC, FILTER_SPEC, CONFIRM, STYLE and SCOPE
can be found in the node's reservation state (if existent). objects can be found in the node's reservation state (if existent).
If the number of [Class, C-Type] pairs is odd, the last two octets of If the number of [Class, C-Type] pairs is odd, the last two octets of
the DIAG_SELECT object must be zero. A maximum DIAG_SELECT object is the DIAG_SELECT object must be zero. A maximum DIAG_SELECT object is
one that contains the [Class, C-type] pairs for all the RSVP objects one that contains the [Class, C-type] pairs for all the RSVP objects
that can be requested in a Diagnostic query. that can be requested in a Diagnostic query.
3.5. ROUTE Object 3.5. ROUTE Object
A diagnostic message may contain a ROUTE object, which is used to A diagnostic message may contain a ROUTE object, which is used to
record the route of the DREQ message and as a source route for record the route of the DREQ message and as a source route for
skipping to change at page 12, line 36 skipping to change at page 11, line 39
D-TTL D-TTL
The number of IP hops this DREQ message traveled from the down- The number of IP hops this DREQ message traveled from the down-
stream RSVP node to the current node. stream RSVP node to the current node.
M flag M flag
A single-bit flag which indicates whether the reservation A single-bit flag which indicates whether the reservation
described by the response objects is merged with reservations from described by the response objects is merged with reservations from
other downstream interfaces when being forwarded upstream. other down-stream interfaces when being forwarded upstream.
R-error R-error
A 3-bit field that indicates error conditions at a node. Currently A 3-bit field that indicates error conditions at a node. Currently
defined values are: defined values are:
0x00: no error 0x00: no error
0x01: No PATH state 0x01: No PATH state
0x02: packet too big 0x02: packet too big
0x04: ROUTE object too big 0x04: ROUTE object too big
skipping to change at page 13, line 14 skipping to change at page 12, line 18
Timer value Timer value
The local refresh timer value in seconds. The local refresh timer value in seconds.
The set of response objects to be included at the end of the The set of response objects to be included at the end of the
DIAG_RESPONSE object is determined by a DIAG_SELECT object, if one is DIAG_RESPONSE object is determined by a DIAG_SELECT object, if one is
present. If no DIAG_SELECT object is present, the response objects present. If no DIAG_SELECT object is present, the response objects
belong to the default list of classes: belong to the default list of classes:
SENDER_TSPEC object FILTER_SPEC object SENDER_TSPEC object FILTER_SPEC object FLOWSPEC object
FLOWSPEC object STYLE object STYLE object
Any C-Type present in the local RSVP state will be used. These Any C-Type present in the local RSVP state will be used. These
response objects may be in any order but they must all be at the end response objects may be in any order but they must all be at the end
of the DIAG_RESPONSE object. of the DIAG_RESPONSE object.
A default DIAG_RESPONSE object is one containing the default list of A default DIAG_RESPONSE object is one containing the default list of
classes described above. classes described above.
3.7. TUNNEL Object 3.7. TUNNEL Object
skipping to change at page 14, line 9 skipping to change at page 13, line 10
DREQ messages are forwarded hop-by-hop via unicast from the LAST-HOP DREQ messages are forwarded hop-by-hop via unicast from the LAST-HOP
address to the Sender address, as specified in the DIAGNOSTIC object. address to the Sender address, as specified in the DIAGNOSTIC object.
If an RSVP capable node, other than the LAST-HOP node, receives a If an RSVP capable node, other than the LAST-HOP node, receives a
DREQ message that contains no DIAG_RESPONSE objects and has a zero DREQ message that contains no DIAG_RESPONSE objects and has a zero
Fragment Offset, the node should forward the DREQ packet towards the Fragment Offset, the node should forward the DREQ packet towards the
LAST-HOP without doing any of the processing mentioned below. The LAST-HOP without doing any of the processing mentioned below. The
reason is that such conditions apply only for nodes downstream of the reason is that such conditions apply only for nodes downstream of the
LAST-HOP where no information should be collected. LAST-HOP where no information should be collected.
Processing begins when a DREQ message, DREQ_in, arrives at a node. Processing begins when a DREQ message, DREQ_in, arrives at a node.
The following processing is performed before DREQ_in is forwarded:
1. Create a new DIAG_RESPONSE object. Compute the IP hop count from 1. Create a new DIAG_RESPONSE object. Compute the IP hop count
the previous RSVP hop. This is done by subtracting the value of from the previous RSVP hop. This is done by subtracting the
the TTL value in the IP header from Send_TTL in the RSVP common value of the TTL value in the IP header from Send_TTL in the
header. Save the result in the D-TTL field of the DIAG_RESPONSE RSVP common header. Save the result in the D-TTL field of the
object. DIAG_RESPONSE object.
2. Set the DREQ Arrival Time and the Outgoing Interface Address in 2. Set the DREQ Arrival Time and the Outgoing Interface Address
the DIAG_RESPONSE object. If this node is the LAST-HOP, then in the DIAG_RESPONSE object. If this node is the LAST-HOP,
the Outgoing Interface Address field in the DIAG_RESPONSE object then the Out- going Interface Address field in the
contains the following value depending on the session being DIAG_RESPONSE object contains the following value depending on
diagnosed. the session being diagnosed.
* If the session in question is a unicast session, then the * If the session in question is a unicast session, then the
Outgoing Interface Address field contains the address of Out-going Interface Address field contains the address of
the interface LAST-HOP uses to send PATH messages and data the interface LAST-HOP uses to send PATH messages and data
to the receiver specified by the session address. to the receiver specified by the session address.
* Otherwise, if it is a multicast session and there is at * Otherwise, if it is a multicast session and there is at
least one receiver for this session, LAST_HOP should use least one receiver for this session, LAST_HOP should use the
the address of one of local interfaces used to reach one of address of one of local interfaces used to reach one of the
the receivers. receivers.
* Otherwise Outgoing Interface Address should be zero. * Otherwise Outgoing Interface Address should be zero.
If no PATH state exists for the specified session, set R-error = 3. Increment the RSVP-hop-count field in the DIAGNOSTIC message
0x01 (No PATH state). object by one.
3. Increment the RSVP-hop-count field in the DIAGNOSTIC message 4. If no PATH state exists for the specified session, set R-error
object by one. = 0x01 (No PATH state) and goto step 7.
4. If the "No PATH state" bit is set, goto Send_DREP. 5. Set the rest of the fields in the DIAG_RESPONSE object. If
DREQ_in contains a DIAG_SELECT object, the response object
classes are those specified in the DIAG_SELECT; otherwise,
they are SENDER_TSPEC, STYLE, and FLOWSPEC objects. If no
reservation state exists for the specified RSVP session, the
DIAG_RESPONSE object will contain no FLOWSPEC, FILTER_SPEC or
STYLE object. If neither PATH nor reservation state exists for
the specified RSVP session, then no response objects will be
appended to the DIAG_RESPONSE object.
5. Set the rest of the fields in the DIAG_RESPONSE object. If 6. If RSVP-hop-count is less than Max-RSVP-hops and this node is
DREQ_in contains a DIAG_SELECT object, the response object not the sender, then the DREQ is eligible for forwarding; set
classes are those specified in the DIAG_SELECT; otherwise, they the Path MTU to the min of the Path MTU and the MTU size of
are SENDER_TSPEC, FILTER_SPEC, STYLE, and FLOWSPEC objects. If the incoming interface for the sender being diagnosed.
no reservation state exists for the specified RSVP session, the
DIAG_RESPONSE object will contain no FILTER_SPEC or FLOWSPEC or
STYLE object. If neither PATH nor reservation state exists for
the specified RSVP session, then no response objects will be
appended to the DIAG_RESPONSE object.
6. If RSVP-hop-count is equal to Max-RSVP-hops or this node is the 7. If the size of DREQ_in plus the size of the new DIAG_RESPONSE
sender, go to Send_DREP. object plus the size of an IP address (if a ROUTE object
exists and R-error= 0) is larger than Path MTU, then the new
diagnostic message will be too large to be forwarded or
returned without fragmentation; set the "packet too big"
(0x02) error bit in DIAG_RESPONSE and goto Step SD1 in
Send_DREP (below).
7. If the Path MTU value is larger than the MTU size of the 8. If the "No PATH state" (0x01) error bit is set or if RSVP-
incoming interface for the sender being diagnosed, change the hop-count is equal to Max-RSVP-hops or if this node is the
Path MTU value to the MTU value of the incoming interface. sender, then the DREQ cannot be forwarded further; goto Step
10.
8. If the size of DREQ_in plus the size of the new DIAG_RESPONSE 9. Forward the DREQ towards the sender, as follows. If a ROUTE
object plus the size of an IP address ,if a ROUTE object exists, object exists, append the "Incoming Interface Address" to the
is larger than Path MTU set the "packet too big" (0x02) error end of the ROUTE object and increment R-Pointer by one.
bit in DIAG_RESPONSE, goto Send_DREP. Update the Next-Hop RSVP_HOP object, append the new
DIAG_RESPONSE object to the list of DIAG_RESPONSE object, and
update the message length field in the RSVP common header
accordingly. Finally, recompute the checksum, forward DREQ_in
to the next hop towards the sender, and return.
9. If a ROUTE object exists, append the "Incoming Interface 10. Turn the DREQ into a DREP and return to the requester, as
Address" to the end of the ROUTE object, increment R-Pointer by follows. Append the DIAG_RESPONSE object to the end of
one, update the Next-Hop RSVP_HOP object, append the new DREQ_in and update the packet length. If a ROUTE object is
DIAG_RESPONSE object to the list of DIAG_RESPONSE object and present in the message, decrement the R-pointer and set target
update the message length field in the RSVP common header address to the last address in the ROUTE object, otherwise set
accordingly. Finally, forward DREQ_in to the next hop towards target address to the requester address. Change the Type Field
the sender, after recomputing the checksum. Return. in the Common header from DREQ to DREP. Finally, recompute
the checksum, send the DREP to the target address, and return.
Note that the MF bit must be off in this case.
Send_DREP: Send_DREP:
1. If the size of DREQ_in plus the size of the new DIAG_RESPONSE This sequence is entered if the DREQ message augmented with the new
object plus the size of an IP address ,if a ROUTE object exists, DIAG_RESPONSE object is too large to be forwarded towards the sender
is larger than Path MTU set the "packet too big" (0x02) error or, if it is not eligible for forwarding, too large to be returned as
bit in DIAG_RESPONSE, otherwise goto step 11. a DREP.
2. Make a copy of DREQ_in and change the type field in RSVP common
header from DREQ to DREP. Trim all DIAG_RESPONSE objects from
DREQ_in and adjust the Fragment Offset.
3. If a ROUTE object is present in the DREP message, decrement the
R-pointer and set target address to the last address in the
ROUTE object, otherwise set target address to the requester
address. Set the MF bit, recompute the checksum and send the
DREP message back to the target address.
4. If the size of DREQ_in plus the size of DIAG_RESPONSE plus the
size of an IP address ,if a ROUTE object exists, is smaller than
Path MTU goto Step 9.
5. Make a copy of DREQ_in and change the type field in RSVP common
header from DREQ to DREP. If a ROUTE object exists, replace the
ROUTE object in DREQ_in with an empty ROUTE object. Turn on the
"ROUTE object too big" (0x04) error bit in the DIAG_RESPONSE.
6. If the "No PATH state" (0x01) error bit is set or if RSVP-hop-
count is equal to Max-RSVP-hops or if this node is the sender,
goto Step 8.
7. If a ROUTE object exists, append the "Incoming Interface
Address" to the end of the ROUTE object, increment R-Pointer by
one, update the Next-Hop RSVP_HOP object, append the new
DIAG_RESPONSE object to the list of DIAG_RESPONSE object, update
the message length field in the RSVP common header accordingly
and adjust the Fragment Offset. Finally, forward DREQ_in to the
next hop towards the sender, after recomputing the checksum.
8. Append the DIAG_RESPONSE object to the end of DREP. Set target SD1. Make a copy of DREQ_in and change the message type field from
address to the requester address. Turn on the MF bit. Update the DREQ to DREP. Trim all DIAG_RESPONSE objects from DREQ_in and
packet length, recompute the checksum in the DREP message and adjust the Fragment Offset. The DREP message contains the
send it towards the target address. Return DIAG_RESPONSE objects accumulated by prior nodes.
9. If the "No PATH state" (0x01) error bit is set or if RSVP-hop- SD2. Send the DREP message towards the requester, as follows. If a
count is equal to Max-RSVP-hops or if this node is the sender, ROUTE object is present in the DREP message, decrement the R-
goto Step 11. pointer and set target address to the last address in the ROUTE
object, otherwise set target address to the requester address.
Set the MF bit, recompute the checksum and send the DREP message
back to the target address.
10. If a ROUTE object exists, append the "Incoming Interface SD3. If the reduced size of DREQ_in plus the size of DIAG_RESPONSE
Address" to the end of the ROUTE object, increment R-Pointer by plus the size of an IP address (if a ROUTE object exists) is
one, update the Next-Hop RSVP_HOP object, append the new smaller than or equal to Path MTU, then return to Step 8 of the
DIAG_RESPONSE object to the list of DIAG_RESPONSE object and main DREQ processing sequence above.
update the message length field in the RSVP common header
accordingly. Finally, forward DREQ_in to the next hop towards
the sender, after recomputing the checksum. Return.
11. Append the DIAG_RESPONSE object to the end of DREQ_in. If a SD4. If a ROUTE object exists, replace the ROUTE object in DREQ_in
ROUTE object is present in the message, decrement the R-pointer with an empty ROUTE object and turn on the "ROUTE object too
and set target address to the last address in the ROUTE object, big" (0x04) error bit in the DIAG_RESPONSE. In either case,
otherwise set target address to the requester address. Change return to Step 8 of the main DREQ processing sequence above.
the Type Field in the Common header from DREQ to DREP.Update the
packet length, recompute the checksum in the DREP message and
send it towards the target address. The MF bit in this case must
be off.
4.2. DREP Forwarding 4.2. DREP Forwarding
When a ROUTE object is present, DREP messages are forwarded hop-by- When a ROUTE object is present, DREP messages are forwarded hop-by-
hop towards the requester, by reversing the route as listed in the hop towards the requester, by reversing the route as listed in the
ROUTE object. Otherwise, DREP messages are sent directly to the ROUTE object. Otherwise, DREP messages are sent directly to the
original requester. original requester.
When a node receives a DREP message, it simply decreases R-pointer by When a node receives a DREP message, it simply decreases R-pointer by
one (address length), recomputes the checksum and forwards the one (address length), recomputes the checksum and forwards the
skipping to change at page 17, line 46 skipping to change at page 16, line 24
object trimming, DREP(s) will come hop-by-hop up to this node and object trimming, DREP(s) will come hop-by-hop up to this node and
will then immediately be forwarded to the requester address. will then immediately be forwarded to the requester address.
Even if the steps shown above are followed there are a few cases Even if the steps shown above are followed there are a few cases
where fragmentation at the IP layer will happen. For example, non- where fragmentation at the IP layer will happen. For example, non-
RSVP hops with smaller MTUs may exist before LAST-HOP is reached, or RSVP hops with smaller MTUs may exist before LAST-HOP is reached, or
if the response is sent directly back to requester (as opposed to hop if the response is sent directly back to requester (as opposed to hop
by hop) the DREP may take a different route to the requester than the by hop) the DREP may take a different route to the requester than the
DREQ took from the requester. Another case is when there exists a DREQ took from the requester. Another case is when there exists a
link with MTU smaller than the minimum Path MTU value defined in link with MTU smaller than the minimum Path MTU value defined in
Section 3.2. Section 3.3.
4.4. Errors 4.4. Errors
If an error condition prevents a DREP message from being forwarded If an error condition prevents a DREP message from being forwarded
further, the message is simply dropped. further, the message is simply dropped.
If an error condition, such as lack of PATH state, prevents a DREQ If an error condition, such as lack of PATH state, prevents a DREQ
message from being forwarded further, the node must change the message from being forwarded further, the node must change the
current message to DREP type and return it to the response address. current message to DREP type and return it to the response address.
skipping to change at page 19, line 43 skipping to change at page 18, line 14
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 messages are more likely to be invoked when things are not diagnostic messages are more likely to be invoked when things are not
working correctly. For example, a receiver has reserved an adequate working correctly. For example, a receiver has reserved an adequate
pipe for a specified incoming data stream, yet the observed delay or pipe for a specified incoming data stream, yet the observed delay or
loss ratio is much higher than expected. In this case the receiver loss ratio is much higher than expected. In this case the receiver
can use the diagnostic facility to examine the reservation state at can use the diagnostic facility to examine the reservation state at
each RSVP hop along the way to find out whether the RSVP state is set each RSVP hop along the way to find out whether the RSVP state is set
up correctly, whether there is any blackhole along the way that up correctly, whether there is any black-hole along the way that
caused RSVP message losses, or whether there are non-RSVP clouds, and caused RSVP message losses, or whether there are non-RSVP clouds, and
where they are, that may have caused the performance problem. where they are, that may have caused the performance problem.
5.6. Crossing "Legacy" RSVP Routers 5.6. Crossing "Legacy" RSVP Routers
Since this diagnosis facility was developed and added to RSVP after a Since this diagnosis facility was developed and added to RSVP after a
number of RSVP implementations were in place, it is possible, or even number of RSVP implementations were in place, it is possible, or even
likely, that when performing RSVP diagnosis, one may encounter one or likely, that when performing RSVP diagnosis, one may encounter one or
more RSVP-capable nodes that do not understand diagnostic messages more RSVP-capable nodes that do not understand diagnostic messages
and drop them. When this happens, the invoking client will get no and drop them. When this happens, the invoking client will get no
skipping to change at page 21, line 5 skipping to change at page 19, line 11
DREQ to every router on the path (from itself to the sender) until it DREQ to every router on the path (from itself to the sender) until it
reaches the first router that belongs to the path from the sender to reaches the first router that belongs to the path from the sender to
the LAST-HOP. the LAST-HOP.
The second problem is that traceroute provides the path from the The second problem is that traceroute provides the path from the
requester to the sender which, due to routing asymmetries, may be requester to the sender which, due to routing asymmetries, may be
different than the path traffic from the sender to the LAST-HOP uses. different than the path traffic from the sender to the LAST-HOP uses.
There is (at least) one case where this asymmetry will cause the There is (at least) one case where this asymmetry will cause the
diagnosis to fail. We present this case below. diagnosis to fail. We present this case below.
Downstream Path Sender Downstream Path Sender
__ __ __ __ __ __ __ __
Receiver +------| |<------| |<-- ...---| |-----| | Receiver +------| |<------| |<-- ...---| |-----| |
__ __ / |__| |__| |__| |__| __ __ / |__| |__| |__| |__|
| |--....--|X |_/ ^ | |--....--|X |_/ ^
|__| |__| Router B | |__| |__| \ Router B |
Black __ | Black \ __ |
Hole +----->| |---->---+ Hole +----->| |---->---+
|__| Upstream Path |__| Upstream Path
Router A Router A
Figure 2 Figure 2
Here the first hop upstream of the black hole is different on the Here the first hop upstream of the black hole is different on the
upstream path and the downstream path. Traceroute will indicate upstream path and the downstream path. Traceroute will indicate
router A as the previous hop (instead of router B which is the right router A as the previous hop (instead of router B which is the right
one). Sending a DREQ to router A will result in A responding with R- one). Sending a DREQ to router A will result in A responding with R-
error 0x01 (No PATH State). If the two paths converge again then the error 0x01 (No PATH State). If the two paths converge again then the
requester can use the solution proposed above to get any (partial) requester can use the solution proposed above to get any (partial)
information from the rest of the path. information from the rest of the path.
We don't have, for the moment, any complete solutions for the We don't have, for the moment, any complete solutions for the
skipping to change at page 21, line 41 skipping to change at page 19, line 47
Following the design principle that nodes in the network should not Following the design principle that nodes in the network should not
hold more than necessary state, RSVP nodes are responsible only for hold more than necessary state, RSVP nodes are responsible only for
forwarding Diagnostic messages and filling DIAG_RESPONSE objects. forwarding Diagnostic messages and filling DIAG_RESPONSE objects.
Additional diagnostic functionality should be carried out by the Additional diagnostic functionality should be carried out by the
diagnostic clients. Furthermore, if the diagnostic function is diagnostic clients. Furthermore, if the diagnostic function is
invoked from a third-party host, we should not require that host be invoked from a third-party host, we should not require that host be
running an RSVP daemon to perform the function. Below we sketch out running an RSVP daemon to perform the function. Below we sketch out
the basic functions that a diagnostic client daemon should carry 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 1. Take input from the user about the session to be diagnosed, the
last-hop and the sender address, the Max-RSVP-hops, and possibly last-hop and the sender address, the Max-RSVP-hops, and
the DIAG_SELECT list, create a DREQ message and send to the possibly the DIAG_SELECT list, create a DREQ message and send
LAST-HOP RSVP node using raw IP message with protocol number 46 to the LAST-HOP RSVP node using raw IP message with protocol
(RSVP). If the user specified that the response should be sent number 46 (RSVP). If the user specified that the response
hop-by-hop include an empty ROUTE object to the DREQ message should be sent hop-by-hop include an empty ROUTE object to the
sent. Set the Path_MTU to the smaller of the user request and DREQ message sent. Set the Path_MTU to the smaller of the user
the MTU of the link through which the DREQ will be sent. request and the MTU of the link through which the DREQ will be
sent.
The port of the UDP socket on which the Diagnostic Client is The port of the UDP socket on which the Diagnostic Client is
listening for replies should be included in the Requester listening for replies should be included in the Requester
FILTER_SPEC object. FILTER_SPEC object.
2. Set a retransmission timer, waiting for the reply (one or more 2. Set a retransmission timer, waiting for the reply (one or more
DREP messages). Listen to the specified UDP port for responses DREP messages). Listen to the specified UDP port for responses
from the LAST-HOP RSVP node. from the LAST-HOP RSVP node.
The LAST-HOP RSVP node, upon receiving DREP messages, sends them The LAST-HOP RSVP node, upon receiving DREP messages, sends
to the Diagnostic Client as UDP packets, using the port supplied them to the Diagnostic Client as UDP packets, using the port
in the Requester FILTER_SPEC object. supplied in the Requester FILTER_SPEC object.
3. Upon receiving a DREP message to an outstanding diagnostic 3. Upon receiving a DREP message to an outstanding diagnostic
request, the client should clear the retransmission timer, check request, the client should clear the retransmission timer,
to see if the reply contains the complete result of the check to see if the reply contains the complete result of the
requested diagnosis. If so, it should pass the result up to the requested diagnosis. If so, it should pass the result up to
invoking entity immediately. the invoking entity immediately.
4. Reassemble DREP fragments. If the first reply to an outstanding 4. Reassemble DREP fragments. If the first reply to an
diagnostic request contains only a fragment of the expected outstanding diagnostic request contains only a fragment of the
result, the client should set up a reassembly timer in a way expected result, the client should set up a reassembly timer in
similar to IP packet reassembly timer. If the timer goes off a way similar to IP packet reassembly timer. If the timer goes
before all fragments arrive, the client should pass the partial off before all fragments arrive, the client should pass the
result to the invoking entity. partial result to the invoking entity.
5. Use retransmission and reassembly timers to gracefully handle 5. Use retransmission and reassembly timers to gracefully handle
packet losses and reply fragment scenarios. packet losses and reply fragment scenarios.
In the absence of response to the first diagnostic request, a In the absence of response to the first diagnostic request, a
client should retransmit the request a few times. If all the client should retransmit the request a few times. If all the
retransmissions also fail, the client should invoke traceroute retransmissions also fail, the client should invoke traceroute
or mtrace to obtain the list of hops along the path segment to or mtrace to obtain the list of hops along the path segment to
be diagnosed, and then perform an iteration of diagnosis with be diagnosed, and then perform an iteration of diagnosis with
increasing hop count as suggested in Section 5.6 in order to increasing hop count as suggested in Section 5.6 in order to
cross RSVP-capable but diagnosis-incapable nodes. cross RSVP-capable but diagnosis-incapable nodes.
6. If all the above efforts fail, the client must notify the 6. If all the above efforts fail, the client must notify the
invoking entity. invoking entity.
7. Security Considerations 7. Security Considerations
RSVP Diagnostics, as any other diagnostic tool, can be a security RSVP Diagnostics, as any other diagnostic tool, can be a security
threat since it can reveal possibly sensitive RSVP state information threat since it can reveal possibly sensitive RSVP state information
to unwanted third parties. to unwanted third parties.
We feel that the threat is minimal, since as explained in the We feel that the threat is minimal, since as explained in the
Introduction Diagnostics messages produce no side-effects and Introduction Diagnostics messages produce no side-effects and
therefore they cannot change RSVP state in the nodes. In this respect therefore they cannot change RSVP state in the nodes. In this respect
RSVP Diagnostics is less a security threat than other diagnostic RSVP Diagnostics is less a security threat than other diagnostic
tools and protocols such as SNMP. tools and protocols such as SNMP.
Furthermore, processing of Diagnostic messages can be disabled if it Furthermore, processing of Diagnostic messages can be disabled if it
is felt that is a security threat. is felt that is a security threat.
8. Acknowledgments 8. Acknowledgments
The idea of developing a diagnostic facility for RSVP was first The idea of developing a diagnostic facility for RSVP was first
suggested by Mark Handley of UCL. Many thanks to Lee Breslau of suggested by Mark Handley of ACIRI. Many thanks to Lee Breslau of
Xerox PARC and John Krawczyk of Baynetworks for their valuable AT&T Labs and John Krawczyk of Nortel Networks for their valuable
comments on the first draft of this memo. Lee Breslau, Bob Braden, comments on the first draft of this memo. Lee Breslau, Bob Braden,
and John Krawczyk contributed further comments after March 1996 IETF. and John Krawczyk contributed further comments after March 1996 IETF.
Steven Berson provided valuable comments on various drafts of the Steven Berson provided valuable comments on various drafts of the
memo. Tim Gleeson contributed an extensive list of editorial memo. Tim Gleeson contributed an extensive list of editorial
comments. We would also like to acknowledge Intel for providing a comments. We would also like to acknowledge Intel for providing a
research grant as a partial support for this work. Subramaniam research grant as a partial support for this work. Subramaniam
Vincent did most of this work while a graduate research assistant at Vincent did most of this work while a graduate research assistant at
the USC Information Sciences Institute (ISI). the USC Information Sciences Institute (ISI).
9. References 9. References
[RSVP] Braden, R. Ed. et al, "Resource ReserVation Protocol -- [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
Version 1 Functional Specification", RFC 2205, September 1997. "Resource ReserVation Protocol -- Version 1 Functional
Specification", RFC 2205, September 1997.
[RSVPTUN] A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang. "RSVP [RSVPTUN] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang,
Operation Over IP Tunnels ", Internet Draft. draft-ietf-rsvp-tunnel- "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
02.txt, February, 1999.
10. Authors' Addresses 10. Authors' Addresses
Andreas Terzis Andreas Terzis
UCLA UCLA
4677 Boelter Hall 4677 Boelter Hall
Los Angeles, CA 90095 Los Angeles, CA 90095
Phone: 310-267-2190 Phone: 310-267-2190
Email: terzis@cs.ucla.edu EMail: terzis@cs.ucla.edu
Bob Braden Bob Braden
USC Information Sciences Institute USC Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292 Marina del Rey, CA 90292
Phone: 310 822-1511 Phone: 310 822-1511
EMail: braden@isi.edu EMail: braden@isi.edu
Subramaniam Vincent Subramaniam Vincent
Cisco Systems Cisco Systems
275, E Tasman Drive, MS SJC04/2/1 275, E Tasman Drive, MS SJC04/2/1
San Jose, CA 95134. San Jose, CA 95134
Phone: 408 525 3474
Email: svincent@cisco.com
Lixia Zhang Phone: 408 525 3474
UCLA EMail: svincent@cisco.com
4531G Boelter Hall
Los Angeles, CA 90095
Phone: 310-825-2695 Lixia Zhang
EMail: lixia@cs.ucla.edu UCLA
4531G Boelter Hall
Los Angeles, CA 90095
Phone: 310-825-2695
EMail: lixia@cs.ucla.edu
10. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 68 change blocks. 
278 lines changed or deleted 235 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/