rfc2961.txt

RFC 的详细文档！

Network Working Group                                         L. Berger
Request for Comments: 2961                         LabN Consulting, LLC
Category: Standards Track                                        D. Gan
                                                 Juniper Networks, Inc.
                                                             G. Swallow
                                                    Cisco Systems, Inc.
                                                                 P. Pan
                                                 Juniper Networks, Inc.
                                                             F. Tommasi
                                                           S. Molendini
                                                    University of Lecce
                                                             April 2001


               RSVP Refresh Overhead Reduction Extensions

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 (2001).  All Rights Reserved.

Abstract

   This document describes a number of mechanisms that can be used to
   reduce processing overhead requirements of refresh messages,
   eliminate the state synchronization latency incurred when an RSVP
   (Resource ReserVation Protocol) message is lost and, when desired,
   refreshing state without the transmission of whole refresh messages.
   The same extensions also support reliable RSVP message delivery on a
   per hop basis.  These extension present no backwards compatibility
   issues.













Berger, et al.              Standards Track                     [Page 1]

RFC 2961       RSVP Refresh Overhead Reduction Extensions     April 2001


Table of Contents

   1      Introduction and Background ................................2
   1.1    Trigger and Refresh Messages ...............................4
   2      Refresh-Reduction-Capable Bit ..............................4
   3      RSVP Bundle Message ........................................5
   3.1    Bundle Header ..............................................5
   3.2    Message Formats ............................................6
   3.3    Sending RSVP Bundle Messages ...............................7
   3.4    Receiving RSVP Bundle Messages .............................8
   4      MESSAGE_ID Extension .......................................8
   4.1    Modification of Standard Message Formats ...................9
   4.2    MESSAGE_ID Objects ........................................10
   4.3    MESSAGE_ID_ACK and MESSAGE_ID_NACK Objects ................11
   4.4    Ack Message Format ........................................11
   4.5    MESSAGE_ID Object Usage ...................................12
   4.6    MESSAGE_ID_ACK Object and MESSAGE_ID_NACK Object Usage ....14
   4.7    Multicast Considerations ..................................15
   4.7.1  Reference RSVP/Routing Interface ..........................16
   4.8    Compatibility .............................................16
   5      Summary Refresh Extension .................................17
   5.1    MESSAGE_ID LIST, SRC_LIST and MCAST_LIST Objects ..........18
   5.2    Srefresh Message Format ...................................24
   5.3    Srefresh Message Usage ....................................25
   5.4    Srefresh NACK .............................................28
   5.5    Preserving RSVP Soft State ................................28
   5.6    Compatibility .............................................29
   6      Exponential Back-Off Procedures ...........................29
   6.1    Outline of Operation ......................................30
   6.2    Time Parameters ...........................................30
   6.3    Retransmission Algorithm ..................................31
   6.4    Performance Considerations ................................31
   7      Acknowledgments ...........................................31
   8      Security Considerations ...................................32
   9      References ................................................32
   10     Authors' Addresses ........................................33
   11     Full Copyright Statement...................................34

1. Introduction and Background

   Standard RSVP [RFC2205] maintains state via the generation of RSVP
   refresh messages.  Refresh messages are used to both synchronize
   state between RSVP neighbors and to recover from lost RSVP messages.
   The use of Refresh messages to cover many possible failures has
   resulted in a number of operational problems.  One problem relates to
   scaling, another relates to the reliability and latency of RSVP
   Signaling.




Berger, et al.              Standards Track                     [Page 2]

RFC 2961       RSVP Refresh Overhead Reduction Extensions     April 2001


   The scaling problems are linked to the resource requirements (in
   terms of processing and memory) of running RSVP.  The resource
   requirements increase proportionally with the number of sessions.
   Each session requires the generation, transmission, reception and
   processing of RSVP Path and Resv messages per refresh period.
   Supporting a large number of sessions, and the corresponding volume
   of refresh messages, presents a scaling problem.

   The reliability and latency problem occurs when a non-refresh RSVP
   message is lost in transmission.  Standard RSVP [RFC2205] recovers
   from a lost message via RSVP refresh messages.  In the face of
   transmission loss of RSVP messages, the end-to-end latency of RSVP
   signaling is tied to the refresh interval of the node(s) experiencing
   the loss.  When end-to-end signaling is limited by the refresh
   interval, the delay incurred in the establishment or the change of a
   reservation may be beyond the range of what is acceptable for some
   applications.

   One way to address the refresh volume problem is to increase the
   refresh period, "R" as defined in Section 3.7 of [RFC2205].
   Increasing the value of R provides linear improvement on transmission
   overhead, but at the cost of increasing the time it takes to
   synchronize state.

   One way to address the reliability and latency of RSVP Signaling is
   to decrease the refresh period R.  Decreasing the value of R
   increases the probability that state will be installed in the face of
   message loss, but at the cost of increasing refresh message rate and
   associated processing requirements.

   An additional issue is the time to deallocate resources after a tear
   message is lost.  RSVP does not retransmit ResvTear or PathTear
   messages.  If the sole tear message transmitted is lost, then
   resources will only be deallocated once the "cleanup timer" interval
   has passed.  This may result in resources being allocated for an
   unnecessary period of time.  Note that even when the refresh period
   is adjusted, the "cleanup timer" must still expire since tear
   messages are not retransmitted.

   The extensions defined in this document address both the refresh
   volume and the reliability issues with mechanisms other than
   adjusting refresh rate.  The extensions are collectively referred to
   as the "Refresh Overhead Reduction" or the "Refresh Reduction"
   extensions.  A Bundle message is defined to reduce overall message
   handling load.  A MESSAGE_ID object is defined to reduce refresh
   message processing by allowing the receiver to more readily identify
   an unchanged message.  A MESSAGE_ACK object is defined which can be
   used to detect message loss and support reliable RSVP message



Berger, et al.              Standards Track                     [Page 3]

RFC 2961       RSVP Refresh Overhead Reduction Extensions     April 2001


   delivery on a per hop basis.  A summary refresh message is defined to
   enable refreshing state without the transmission of whole refresh
   messages, while maintaining RSVP's ability to indicate when state is
   lost and to adjust to changes in routing.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.1. Trigger and Refresh Messages

   This document categorizes RSVP messages into two types: trigger and
   refresh messages.  Trigger messages are those RSVP messages that
   advertise state or any other information not previously transmitted.
   Trigger messages include messages advertising new state, a route
   change that alters a reservation path, or a modification to an
   existing RSVP session or reservation.  Trigger messages also include
   those messages that include changes in non-RSVP processed objects,
   such as changes in the Policy or ADSPEC objects.

   Refresh messages represent previously advertised state and contain
   exactly the same objects and same information as a previously
   transmitted message, and are sent over the same path.  Only Path and
   Resv messages can be refresh messages.  Refresh messages are
   identical to the corresponding previously transmitted message, with
   some possible exceptions.  Specifically, the checksum field, the
   flags field and the INTEGRITY object may differ in refresh messages.

2. Refresh-Reduction-Capable Bit

   To indicate support for the refresh overhead reduction extensions, an
   additional capability bit is added to the common RSVP header, which
   is defined in [RFC2205].

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Vers | Flags |   Msg Type    |         RSVP Checksum         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Send_TTL    |  (Reserved)   |         RSVP Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Flags: 4 bits

         0x01: Refresh (overhead) reduction capable






Berger, et al.              Standards Track                     [Page 4]

RFC 2961       RSVP Refresh Overhead Reduction Extensions     April 2001


           When set, indicates that this node is willing and capable of
           receiving all the messages and objects described in this
           document.  This includes the Bundle message described in
           Section 3, the MESSAGE_ID objects and Ack messages described
           in Section 4, and the MESSAGE_ID LIST objects and Srefresh
           message described in Section 5.  This bit is meaningful only
           between RSVP neighbors.

   Nodes supporting the refresh overhead reduction extensions must also
   take care to recognize when a next hop stops sending RSVP messages
   with the Refresh-Reduction-Capable bit set.  To cover this case,
   nodes supporting the refresh overhead reduction extensions MUST
   examine the flags field of each received RSVP message.  If the flag
   changes from indicating support to indicating non-support then,
   unless configured otherwise, Srefresh messages (described in Section
   5) MUST NOT be used for subsequent state refreshes to that neighbor
   and Bundle messages (Section 3) MUST NOT be sent to that neighbor.
   Note, a node that supports reliable RSVP message delivery (Section 4)
   but not Bundle and Srefresh messages, will not set the Refresh-
   Reduction-Capable bit.

3. RSVP Bundle Message

   An RSVP Bundle message consists of a bundle header followed by a body
   consisting of a variable number of standard RSVP messages.  A Bundle
   message is used to aggregate multiple RSVP messages within a single
   PDU.  The term "bundling" is used to avoid confusion with RSVP
   reservation aggregation.  The following subsections define the
   formats of the bundle header and the rules for including standard
   RSVP messages as part of the message.

3.1. Bundle Header

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vers  | Flags |   Msg type    |         RSVP checksum         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Send_TTL    |  (Reserved)   |         RSVP length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The format of the bundle header is identical to the format of the
      RSVP common header [RFC2205].  The fields in the header are as
      follows:

      Vers: 4 bits

         Protocol version number.  This is version 1.



Berger, et al.              Standards Track                     [Page 5]

RFC 2961       RSVP Refresh Overhead Reduction Extensions     April 2001


      Flags: 4 bits

         0x01: Refresh (overhead) reduction capable