rfc2745.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,292 行 · 第 1/4 页

Network Working Group                                          A. Terzis
Request for Comments: 2745                                          UCLA
Category: Standards Track                                      B. Braden
                                                                     ISI
                                                              S. Vincent
                                                           Cisco Systems
                                                                L. Zhang
                                                                    UCLA
                                                            January 2000


                        RSVP Diagnostic Messages

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document specifies the RSVP diagnostic facility, which allows a
   user to collect information about the RSVP state along a path.  This
   specification describes the functionality, diagnostic message
   formats, and processing rules.

1.  Introduction

   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
   either path state or reservation state.  An 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.  In the absence of failures, a host receives no feedback
   regarding the details of a reservation that has been put in place,
   such as whether, or where, or how, its own reservation request is
   being merged with that of others.  Such missing information can be
   highly desirable for debugging purposes, or for network resource
   management in general.






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


   This document specifies the RSVP diagnostic facility, which is
   designed to fill this information gap.  The diagnostic facility can
   be used to collect and report RSVP state information along the path
   from a receiver to a specific sender.  It uses Diagnostic messages
   that are independent of other RSVP control messages and produce no
   side-effects; that is, they do not change any RSVP state at either
   nodes or hosts.  Similarly, they provide not an error report but
   rather a collection of requested RSVP state information.

   The RSVP diagnostic facility was designed with the following goals:

   -  To collect RSVP state information from every RSVP-capable hop
      along a path defined by path state, either for an existing
      reservation or before a reservation request is made.  More
      specifically, we want to be able to collect information about
      flowspecs, refresh timer values, and reservation merging at each
      hop along the path.

   -  To collect the IP hop count across each non-RSVP cloud.

   -  To avoid diagnostic packet implosion or explosion.

   The following is specifically identified as a non-goal:

   -  Checking the resource availability along a path.  Such
      functionality may be useful for future reservation requests, but
      it would require modifications to existing admission control
      modules that is beyond the scope of RSVP.

2.  Overview

   The diagnostic facility introduces two new RSVP message types:
   Diagnostic Request (DREQ) and Diagnostic Reply (DREP).  A DREQ
   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.
   A client in the requester host invokes the RSVP diagnostic facility
   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
   specifies the RSVP session and a sender host for that session.
   Starting from the LAST-HOP, the DREQ packet collects information
   hop-by-hop as it is forwarded towards the sender (see Figure 1),
   until it reaches the ending node.  Specifically, each RSVP-capable
   hop adds to the DREQ message a response (DIAG_RESPONSE) object
   containing local RSVP state for the specified RSVP session.







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


   When the DREQ packet reaches the ending node, the message type is
   changed to Diagnostic Reply (DREP) and the completed response is sent
   to the original requester node.  Partial responses may also be
   returned before the DREQ packet reaches the ending node if an error
   condition along the path, such as "no path state", prevents further
   forwarding of the DREQ packet.  To avoid packet implosion or
   explosion, all diagnostic packets are forwarded via unicast only.

   Thus, there are generally three nodes (hosts and/or routers) involved
   in performing the diagnostic function: the requester node, the
   starting node, and the ending node, as shown in Figure 1.  It is
   possible that the client invoking the diagnosis function may reside
   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
   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.
   The ending node is usually the specified sender host.  However, the
   client can limit the length of the path segment to be diagnosed by
   specifying a hop-count limit in the DREQ message.


                  LAST-HOP                  Ending
     Receiver        node                     node           Sender
         __           __         __            __              __
        |  |---------|  |------>|  |--> ...-->|  |--> ...---->|  |
        |__|         |__| DREQ  |__|   DREQ   |__|   DREQ     |__|
                      ^                         .              |
                      |                         .              |
                      | DREQ                    . DREP         | DREP
                      |                         .              |
                     _|_               DREP     V              V
        Requester   |   | <------------------------------------
        (client)    |___|

                         Figure 1


   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
   taken by the DREQ message to the LAST-HOP, and thence to 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
   have to cross firewalls.  Hop-by-hop return is accomplished using an
   optional ROUTE object, which is built incrementally to contain a list
   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
   hop-by-hop back to the LAST-HOP node.




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


   A DREQ message always consists of a single unfragmented IP datagram.
   On the other hand, one DREQ message can generate multiple DREP
   packets, each containing a fragment of the total DREQ message.  When
   the path consists of many hops, the total length of a DREP message
   will exceed the MTU size before reaching the ending node; thus, the
   message has to be fragmented.  Relying on IP fragmentation and
   reassembly, however, can be problematic, especially when DREP
   messages are returned to the requester hop-by-hop, in which case
   fragmentation/reassembly would have to be performed at every hop.  To
   avoid such excessive overhead, we let the requester define a default
   path MTU size that is carried in every DREQ packet.  If an
   intermediate node finds that the default MTU size is bigger than the
   MTU of the incoming interface, it reduces the default MTU size to the
   MTU size of the incoming interface. If an intermediate node detects
   that a DREQ packet size is larger than the default MTU size, it
   returns to the requester (in either manner described above) a DREP
   fragment containing accumulated responses.  It then removes these
   responses from the DREQ and continues to forward it.  The requester
   node can reassemble the resulting DREP fragments into a complete DREP
   message.

   When discussing diagnostic packet handling, this document uses
   direction terminology that is consistent with the RSVP functional
   specification [RSVP], relative to the direction of data packet flow.
   Thus, a DREQ packet enters a node through an "outgoing interface" and
   is forwarded towards the sender through an "incoming interface",
   because DREQ packets travel in the reverse direction to the data
   flow.

   Notice that DREQ packets can be forwarded only after the RSVP path
   state has been set up.  If no path state exists, one may resort to
   the traceroute or mtrace facility to examine whether the
   unicast/multicast routing is working correctly.

3.  Diagnostic Packet Format

   Like other RSVP messages, DREQ and DREP messages consist of an RSVP
   Common Header followed by a variable set of typed RSVP data objects.
   The following sequence must be used:












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


           +-----------------------------------+
           |        RSVP Common Header         |
           +-----------------------------------+
           |         Session object            |
           +-----------------------------------+
           |      Next-Hop RSVP_HOP object     |
           +-----------------------------------+
           |       DIAGNOSTIC object           |
           +-----------------------------------+
           |    (optional) DIAG_SELECT object  |
           +-----------------------------------+
           |    (optional) ROUTE object        |
           +-----------------------------------+
           | zero or more DIAG_RESPONSE objects|
           +-----------------------------------+

   The session object identifies the RSVP session for which the state
   information is being collected.  We describe each of the other parts.

3.1.  RSVP Message Common Header

   The RSVP message common header is defined in [RSVP].  The following
   specific exceptions and extensions are needed for DREP and DREQ.

   Type field: define:

          Type = 8: DREQ     Diagnostic Request

          Type = 9: DREP     Diagnostic Reply

   RSVP length:

      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
      DREP fragment rather than the total length of the complete DREP
      reply message (which cannot generally be known in advance).

3.2.  Next-Hop RSVP_HOP Object

   This RSVP_HOP object carries the LIH of the interface through which
   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
   message contains an RSVP_HOP object: to distinguish logical
   interfaces and avoid problems caused by routing asymmetries and non-
   RSVP clouds.






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


   While the IP address is not really used during DREQ processing, for
   consistency with the use of the RSVP_HOP object in other RSVP
   messages, the IP address in the RSVP_HOP object to contain the
   address of the interface through which the DREQ was sent.

3.3.  DIAGNOSTIC Object

   A DIAGNOSTIC object contains the common diagnostic control
   information in both DREQ and DREP messages.

   o IPv4 DIAGNOSTIC object: Class = 30, C-Type = 1

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Max-RSVP-hops | RSVP-hop-count|         Reserved            |MF|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Request ID                           |
    +---------------+---------------+---------------+---------------+
    |           Path MTU            |     Fragment Offset           |
    +---------------+---------------+---------------+---------------+
    |                         LAST-HOP Address                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                     SENDER_TEMPLATE object                    |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                 Requester FILTER_SPEC object                  |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Here all IP addresses use the 4 byte IPv4 format, both explicitly in
   the LAST-HOP Address and by using the IPv4 forms of the embedded
   FILTER_SPEC and RSVP_HOP objects.

   o IPv6 DIAGNOSTIC object: Class = 30, C-Type = 2

   The format is the same, except all explicit and embedded IP addresses