rfc2745.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   where they are, that may have caused the performance problem.

5.6.  Crossing "Legacy" RSVP Routers

   Since this diagnosis facility was developed and added to RSVP after a
   number of RSVP implementations were in place, it is possible, or even
   likely, that when performing RSVP diagnosis, one may encounter one or
   more RSVP-capable nodes that do not understand diagnostic messages
   and drop them.  When this happens, the invoking client will get no
   response from its requests.

   One way to by-pass such "legacy" RSVP nodes is to perform RSVP
   diagnosis repeatedly, guided by information from traceroute, or
   mtrace in case of multicast.  When an RSVP diagnostic query times out
   (see next section), one may first use traceroute to get the list of
   nodes along the path, and then gradually increase the value of Max-
   RSVP-hops field in the DREQ message, starting from a low value until
   one no longer receives a response.  One can then try RSVP diagnosis
   again by starting with the first node (which is further upstream
   towards the sender) after the unresponding one.

   There are two problem with the method mentioned above in the case of
   unicast sessions. Both problems are related to the fact that
   traceroute information provides the path from the requester to the
   sender. The first problem is that the LAST-HOP may not be on the path
   from the requester to the sender. In this case we can get information
   only from the portion of the path from the LAST-HOP to the sender
   which intersects with the path from the requester to the sender. If
   routers that are not on the intersection of the two paths don't have
   PATH state for the session being diagnosed then they will reply with
   R-error=0x01. The requester can overcome this problem by sending a
   DREQ to every router on the path (from itself to the sender) until it
   reaches the first router that belongs to the path from the sender to
   the LAST-HOP.






Terzis, et al.              Standards Track                    [Page 18]

RFC 2745                RSVP Diagnostic Messages            January 2000


   The second problem is that traceroute provides the path from the
   requester to the sender which, due to routing asymmetries, may be
   different than the path traffic from the sender to the LAST-HOP uses.
   There is (at least) one case where this asymmetry will cause the
   diagnosis to fail. We present this case below.

                                Downstream Path                Sender
                                __         __            __       __
   Receiver             +------|  |<------|  |<-- ...---|  |-----|  |
      __          __   /       |__|       |__|          |__|     |__|
     |  |--....--|X |_/                    ^
     |__|        |__| \     Router B       |
                Black  \        __         |
                Hole    +----->|  |---->---+
                               |__| Upstream Path

                             Router A

                             Figure 2

   Here the first hop upstream of the black hole is different on the
   upstream path and the downstream path. Traceroute will indicate
   router A as the previous hop (instead of router B which is the right
   one). Sending a DREQ to router A will result in A responding with R-
   error 0x01 (No PATH State). If the two paths converge again then the
   requester can use the solution proposed above to get any (partial)
   information from the rest of the path.

   We don't have, for the moment, any complete solutions for the
   problematic scenarios described here.

6.  Comments on Diagnostic Client Implementation.

   Following the design principle that nodes in the network should not
   hold more than necessary state,  RSVP nodes are responsible only for
   forwarding Diagnostic messages and filling DIAG_RESPONSE objects.
   Additional diagnostic functionality should be carried out by the
   diagnostic clients.  Furthermore, if the diagnostic function is
   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
   the basic functions that a diagnostic client daemon should carry out.

      1. Take input from the user about the session to be diagnosed, the
         last-hop and the sender address, the Max-RSVP-hops, and
         possibly the DIAG_SELECT list, create a DREQ message and send
         to the LAST-HOP RSVP node using raw IP message with protocol
         number 46 (RSVP).  If the user specified that the response
         should be sent hop-by-hop include an empty ROUTE object to the



Terzis, et al.              Standards Track                    [Page 19]

RFC 2745                RSVP Diagnostic Messages            January 2000


         DREQ message sent. Set the Path_MTU to the smaller of the user
         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
         listening for replies should be included in the Requester
         FILTER_SPEC object.

      2. Set a retransmission timer, waiting for the reply (one or more
         DREP messages).  Listen to the specified UDP port for responses
         from the LAST-HOP RSVP node.

         The LAST-HOP RSVP node, upon receiving DREP messages, sends
         them to the Diagnostic Client as UDP packets, using the port
         supplied in the Requester FILTER_SPEC object.

      3. Upon receiving a DREP message to an outstanding diagnostic
         request, the client should clear the retransmission timer,
         check to see if the reply contains the complete result of the
         requested diagnosis.  If so, it should pass the result up to
         the invoking entity immediately.

      4. Reassemble DREP fragments.  If the first reply to an
         outstanding diagnostic request contains only a fragment of the
         expected result, the client should set up a reassembly timer in
         a way similar to IP packet reassembly timer.  If the timer goes
         off before all fragments arrive, the client should pass the
         partial result to the invoking entity.

      5. Use retransmission and reassembly timers to gracefully handle
         packet losses and reply fragment scenarios.

         In the absence of response to the first diagnostic request, a
         client should retransmit the request a few times.  If all the
         retransmissions also fail, the client should invoke traceroute
         or mtrace to obtain the list of hops along the path segment to
         be diagnosed, and then perform an iteration of diagnosis with
         increasing hop count as suggested in Section 5.6 in order to
         cross RSVP-capable but diagnosis-incapable nodes.

      6. If all the above efforts fail, the client must notify the
         invoking entity.









Terzis, et al.              Standards Track                    [Page 20]

RFC 2745                RSVP Diagnostic Messages            January 2000


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 nodes. 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
   suggested by Mark Handley of ACIRI.  Many thanks to Lee Breslau of
   AT&T Labs and John Krawczyk of Nortel Networks for their valuable
   comments on the first draft of this memo.  Lee Breslau, Bob Braden,
   and John Krawczyk contributed further comments after March 1996 IETF.
   Steven Berson provided valuable comments on various drafts of the
   memo. Tim Gleeson contributed an extensive list of editorial
   comments. We would also like to acknowledge Intel for providing a
   research grant as a partial support for this work. Subramaniam
   Vincent did most of this work while a graduate research assistant at
   the USC Information Sciences Institute (ISI).

9.  References

   [RSVP]    Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
             "Resource ReserVation Protocol -- Version 1 Functional
             Specification", RFC 2205, September 1997.

   [RSVPTUN] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang,
             "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.














Terzis, et al.              Standards Track                    [Page 21]

RFC 2745                RSVP Diagnostic Messages            January 2000


10.  Authors' Addresses

   Andreas Terzis
   UCLA
   4677 Boelter Hall
   Los Angeles, CA 90095

   Phone:    [phone]
   EMail:    [e-mail]


   Bob Braden
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone:    [phone]
   EMail:    [e-mail]


   Subramaniam Vincent
   Cisco Systems
   275, E Tasman Drive, MS SJC04/2/1
   San Jose, CA 95134

   Phone:    [phone]
   EMail:    [e-mail]


   Lixia Zhang
   UCLA
   4531G Boelter Hall
   Los Angeles, CA  90095

   Phone:    [phone]
   EMail:    [e-mail]















Terzis, et al.              Standards Track                    [Page 22]

RFC 2745                RSVP Diagnostic Messages            January 2000


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.



















Terzis, et al.              Standards Track                    [Page 23]