draft-ietf-rsvp-diagnostic-msgs-03.txt   draft-ietf-rsvp-diagnostic-msgs-04.txt 
INTERNET-DRAFT Lixia Zhang INTERNET-DRAFT Lixia Zhang
<draft-ietf-rsvp-diagnostic-msgs-03.txt> Andreas Terzis <draft-ietf-rsvp-diagnostic-msgs-04.txt> Andreas Terzis
Expiration: May 1998 UCLA Expiration: February 1999 UCLA
November 1997 Subramaniam Vincent
August 1998
RSVP Diagnostic Messages RSVP Diagnostic Messages
<draft-ietf-rsvp-diagnostic-msgs-03.txt> <draft-ietf-rsvp-diagnostic-msgs-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
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 view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet Draft expires in May, 1998. This Internet Draft expires in February, 1999.
Abstract Abstract
This document specifies the RSVP diagnosis facility. As the This document specifies the RSVP diagnosis facility. As the
deployment of RSVP is spreading out, it becomes clear that a method deployment of RSVP is spreading out, it becomes clear that a method
for collecting information about the RSVP state along the path is for collecting information about the RSVP state along the path is
needed. This specification describes the functionality, diagnostic needed. This specification describes the functionality, diagnostic
message formats, and processing rules. message formats, and processing rules.
1. Introduction 1. Introduction
skipping to change at page 13, line 26 skipping to change at page 14, line 26
session. session.
If no reservation state exists for the specified RSVP session, If no reservation state exists for the specified RSVP session,
the response object will contain no filter-spec or flowspec the response object will contain no filter-spec or flowspec
object. object.
If neither PATH nor reservation state exists for the specified If neither PATH nor reservation state exists for the specified
RSVP session, then the response object contains none of the RSVP session, then the response object contains none of the
Tspec, filter or flow spec object. Tspec, filter or flow spec object.
5. If any error bit is set, change the type field in RSVP common 5. 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.
6. If any error bit is set, change the type field in RSVP common
header from DREQ to DREP, recompute the checksum and send the header from DREQ to DREP, recompute the checksum and send the
packet back to either the LAST-HOP address (if H = 1), or to the packet back to either the LAST-HOP address (if H = 1), or to the
response address directly via unicast (if H = 0). response address directly via unicast (if H = 0).
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 current hop is the sender as identified by the "Source
Address" in the RSVP diagnostic header, go to Send_DREP(), and
then return.
7. If the resulting DREQ packet size exceeds the MTU limit, minus 7. If the resulting DREQ packet size exceeds the MTU limit, minus
some margin to hold the address list object as described below, some margin to hold the address list object as described below,
go to Send_DREP(). go to Send_DREP().
8. If no error bit set ,then if the H-bit is set, append the 8. If no error bit set ,then if the H-bit is set, append the
"Incoming Interface Address" to the end of the ROUTE object, "Incoming Interface Address" to the end of the ROUTE object,
increment R-Pointer by one, update the Next-Hop RSVP_HOP object increment R-Pointer by one, update the Next-Hop RSVP_HOP object
to be the Previous Hop from the Path State and update the packet to be the Previous Hop from the Path State and update the packet
length field in the RSVP common header accordingly. Finally length field in the RSVP common header accordingly. Finally
forward the DREQ packet to the next hop towards the source, forward the DREQ packet to the next hop towards the source,
skipping to change at page 19, line 15 skipping to change at page 20, line 9
retransmit the request a few times. If all the retransmissions retransmit the request a few times. If all the retransmissions
also fail, the client should invoke traceroute or mtrace to also fail, the client should invoke traceroute or mtrace to
obtain the list of hops along the path segment to be diagnosed, obtain the list of hops along the path segment to be diagnosed,
and then perform an iteration of diagnosis with increasing hop and then perform an iteration of diagnosis with increasing hop
count as suggested in Section 5.6 in order to cross RSVP-capable count as suggested in Section 5.6 in order to cross RSVP-capable
but diagnosis-incapable routers. but diagnosis-incapable routers.
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. Acknowledgments 7. Security Considerations
RSVP Diagnostics, as any other diagnostic tool, can be a security
threat since it can reveal possibly sensitive RSVP state information
to unwanted third parties.
We feel that the threat is minimal, since as explained in the
Introduction Diagnostics messages produce no side-effects and
therefore they cannot change RSVP state in the routers. In this
respect RSVP Diagnostics is less a security threat than other
diagnostic tools and protocols such as SNMP.
Furthermore, processing of Diagnostic messages can be disabled if it
is felt that is a security threat.
8. Acknowledgments
The idea of developing a diagnostic facility for RSVP was first The idea of developing a diagnostic facility for RSVP was first
suggested by Mark Handley of UCL. Many thanks to Lee Breslau of suggested by Mark Handley of UCL. Many thanks to Lee Breslau of
Xerox PARC and John Krawczyk of Baynetworks for their valuable Xerox PARC and John Krawczyk of Baynetworks for their valuable
comments on the first draft of this memo. Lee Breslau, Bob Braden, comments on the first draft of this memo. Lee Breslau, Bob Braden,
and John Krawczyk contributed further comments after March 1996 IETF. and John Krawczyk contributed further comments after March 1996 IETF.
Vincent Subramaniam and Steven Berson provided valuable comments on Steven Berson provided valuable comments on various drafts of the
variable drafts of the memo. We would also like to acknowledge Intel memo. We would also like to acknowledge Intel for providing a
for providing a research grant as a partial support for this work. research grant as a partial support for this work.
8. References 9. References
[RSVPTUN] L. Zhang, A. Terzis, "RSVP Operation Over IP Tunnels ", [RSVPTUN] L. Zhang, A. Terzis, "RSVP Operation Over IP Tunnels ",
Internet Draft draft-ietf-rsvp-tunnel-02.txt, November, 1997. Internet Draft draft-ietf-rsvp-tunnel-02.txt, November, 1997.
9. Authors' Addresses 10. Authors' Addresses
Lixia Zhang Lixia Zhang
UCLA UCLA
4531G Boelter Hall 4531G Boelter Hall
Los Angeles, CA 90095 Los Angeles, CA 90095
Phone: 310-825-2695 Phone: 310-825-2695
EMail: lixia@cs.ucla.edu EMail: lixia@cs.ucla.edu
Andreas Terzis Andreas Terzis
UCLA UCLA
4677 Boelter Hall 4677 Boelter Hall
Los Angeles, CA 90095 Los Angeles, CA 90095
Phone: 310-267-2190 Phone: 310-267-2190
Email: terzis@cs.ucla.edu Email: terzis@cs.ucla.edu
Subramaniam Vincent
 End of changes. 

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