rfc2745.txt

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

   The optional TUNNEL object should be inserted when a DREQ message
   arrives at an RSVP node that acts as a tunnel exit point.

   The TUNNEL object provides the mapping between the end-to-end RSVP
   session that is being diagnosed and the RSVP session over the tunnel.
   This mapping information allows the diagnosis client to conduct
   diagnosis over the involved tunnel session, by invoking a separate
   Diagnostic query for the corresponding Tunnel Session and Tunnel
   Sender.  Keep in mind, however, that multiple end-to-end sessions may
   all map to one pre-configured tunnel session that may have totally
   different parameter settings.

   The tunnel object is defined in the RSVP Tunnel Specification
   [RSVPTUN].

4.  Diagnostic Packet Forwarding Rules

4.1.  DREQ Packet Forwarding

   DREQ messages are forwarded  hop-by-hop via unicast from the LAST-HOP
   address to the Sender address, as specified in the DIAGNOSTIC object.
   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



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


   Fragment Offset, the node should forward the DREQ packet towards the
   LAST-HOP without doing any of the processing mentioned below. The
   reason is that such conditions apply only for nodes downstream of the
   LAST-HOP where no information should be collected.

   Processing begins when a DREQ message, DREQ_in, arrives at a node.

       1. Create a new DIAG_RESPONSE object. Compute the IP 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 the
          RSVP common header.  Save the result in the D-TTL field of the
          DIAG_RESPONSE object.

       2. Set the DREQ Arrival Time and the Outgoing Interface Address
          in the DIAG_RESPONSE object.  If this node is the LAST-HOP,
          then the Out- going Interface Address field in the
          DIAG_RESPONSE object contains the following value depending on
          the session being diagnosed.

         *  If the session in question is a unicast session, then the
            Out-going Interface Address field contains the address of
            the interface LAST-HOP uses to send PATH messages and data
            to the receiver specified by the session address.

         *  Otherwise, if it is a multicast session and there is at
            least one receiver for this session, LAST_HOP should use the
            address of one of local interfaces used to reach one of the
            receivers.

         *  Otherwise Outgoing Interface Address should be zero.

       3. Increment the RSVP-hop-count field in the DIAGNOSTIC message
          object by one.

       4. If no PATH state exists for the specified session, set R-error
          = 0x01 (No PATH state) and goto step 7.

       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.





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


       6. If RSVP-hop-count is less than Max-RSVP-hops and this node is
          not the sender, then the DREQ is eligible for forwarding; set
          the Path MTU to the min of the Path MTU and the MTU size of
          the incoming interface for the sender being diagnosed.

       7. If the size of DREQ_in plus the size of the new DIAG_RESPONSE
          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).

       8. 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, then the DREQ cannot be forwarded further; goto Step
          10.

       9. Forward the DREQ towards the sender, as follows.  If a ROUTE
          object exists, append the "Incoming Interface Address" to the
          end of the ROUTE object and 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, 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.

      10. Turn the DREQ into a DREP and return to the requester, as
          follows.  Append the DIAG_RESPONSE object to the end of
          DREQ_in and update the packet length.  If a ROUTE object is
          present in the 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. Change the Type Field
          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:

   This sequence is entered if the DREQ message augmented with the new
   DIAG_RESPONSE object is too large to be forwarded towards the sender
   or, if it is not eligible for forwarding, too large to be returned as
   a DREP.

   SD1. Make a copy of DREQ_in and change the message type field from
        DREQ to DREP.  Trim all DIAG_RESPONSE objects from DREQ_in and
        adjust the Fragment Offset.  The DREP message contains the
        DIAG_RESPONSE objects accumulated by prior nodes.



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


   SD2. Send the DREP message towards the requester, as follows.  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.

   SD3. If the reduced 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 or equal to Path MTU, then return to Step 8 of the
        main DREQ processing sequence above.

   SD4. If a ROUTE object exists, replace the ROUTE object in DREQ_in
        with an empty ROUTE object and turn on the "ROUTE object too
        big" (0x04) error bit in the DIAG_RESPONSE.  In either case,
        return to Step 8 of the main DREQ processing sequence above.

4.2.  DREP Forwarding

   When a ROUTE object is present, DREP messages are forwarded hop-by-
   hop towards the requester, by reversing the route as listed in the
   ROUTE object. Otherwise, DREP messages are sent directly to the
   original requester.

   When a node receives a DREP message, it simply decreases R-pointer by
   one (address length), recomputes the checksum and forwards the
   message to the address pointed to by R-pointer in the route list. If
   a node, other than the LAST-HOP, receives a DREP packet where R-
   pointer is equal to zero, it must send it directly to the requester.

   When the LAST-HOP node receives a DREP message, it sends the message
   to the requester.

4.3.  MTU Selection and Adjustment

   Because the DREQ message carries the allowed MTU size of previous
   hops that the DREP messages will later traverse, this unique feature
   allows easy semantic fragmentation as described above.  Whenever the
   DREQ message approaches the size of Path MTU, it can be trimmed
   before being forwarded again.

   When a requester sends a DREQ message, the Path MTU field in the
   DIAGNOSTIC object can be set to a configured default value. It is
   possible that the original Path MTU value is chosen larger than the
   actual MTU value along some portion of the path being traced.
   Therefore each intermediate RSVP node must check the MTU value when
   processing a DREQ message.  If the specified MTU value is larger than




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


   the MTU of the incoming interface (that the DREQ message will be
   forwarded to), the node changes the MTU value in the header to the
   smaller value.

   Whenever a DREQ message size becomes larger than the Path MTU value,
   an intermediate RSVP node makes a copy of the message, converts it to
   a DREP message to send back, and then trims off the partial results
   from the DREQ message. If in this case also the DREQ cannot be
   forwarded upstream due to a large ROUTE object, the "ROUTE object too
   big" is set and the ROUTE object is trimmed. As a result of the ROUTE
   object trimming, DREP(s) will come hop-by-hop up to this node and
   will then immediately be forwarded to the requester address.

   Even if the steps shown above are followed there are a few cases
   where fragmentation at the IP layer will happen. For example, non-
   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
   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
   link with MTU smaller than the minimum Path MTU value defined in
   Section 3.3.

4.4.  Errors

   If an error condition prevents a DREP message from being forwarded
   further, the message is simply dropped.

   If an error condition, such as lack of PATH state, prevents a DREQ
   message from being forwarded further, the node must change the
   current message to DREP type and return it to the response address.

5.  Problem Diagnosis by Using RSVP Diagnostic Facility

5.1.  Across Firewalls

   Firewalls may cause problems in diagnostic message forwarding.  Let
   us look at two different cases.

   First, let us assume that the querier resides on a receiving host of
   the session to be examined.  In this case, firewalls should not
   prevent the forwarding of the diagnostic messages 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 messages.  The querier
   may start by not including a ROUTE object, which can give a faster
   response delivery and reduced overhead at intermediate nodes.
   However if no response is received, the querier may resend the DREQ
   message with a ROUTE object, specifying that a hop-by-hop reply
   should be sent.



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


   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 node behind a firewall, or both), at
   this time we do not know any other solution but to change the LAST-
   HOP to a node that is on the same side of the firewall as the
   requester.

5.2.  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 DIAG_RESPONSE object shows the number of
   routing hops between adjacent RSVP nodes.  Therefore any value
   greater than one indicates a non-RSVP cloud 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 nodes by running either unicast or multicast
   trace route.

5.4.  Discovering Reservation Merges

   The flowspec value in a DIAG_RESPONSE object specifies the amount of
   resources being reserved for the data stream defined by the filter
   spec in the same data block.  When this value of adjacent
   DIAG_RESPONSE objects differs, that is, a downstream node Rd has a
   smaller value than its immediate upstream node 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 message before sending its
   own reservation, it can discover (1) how many RSVP hops there are
   along the path between the specified sender and itself, (2) how many
   of the hops already have some reservation by other receivers, and (3)
   possibly a rough prediction of how its reservation request might get
   merged with other existing ones.







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


5.5.  Error Diagnosis

   In addition to examining the state of a working reservation, RSVP
   diagnostic messages 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 black-hole along the way that
   caused RSVP message losses, or whether there are non-RSVP clouds, and