[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Draft                                              M. Yuhara
Expiration: October 1999                                    M. Tomikawa
File: draft-yuhara-rsvp-refresh-00.txt
                                              Fujitsu Laboratories Ltd.

                                                             April 1999

                 RSVP Extensions for ID-based Refreshes

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   The purpose of this document is to provide a discussion on the
   refresh overhead reduction of RSVP. Specifically, this document
   proposes some extensions to deal with route change while maintaining
   the advantage of ID-based refreshes. For environments where PATH
   refreshes must be used to detect route change, ID-only refreshes are
   used to decrease the message size. For environments where route
   change is informed to RSVP process by some other means, a new message
   is introduced to invalidate ID.

1. Introduction

   The combination of RSVP [RFC2205, RFC2209] and intserv [RFC2210,
   RFC2215] was proposed to provide better quality of service than
   traditional best effort service. When deploying this combination over
   the internet, however, there are several concerns [RFC 2208], and the
   scalability problem is regarded as the biggest problem. The



Yuhara & Tomikawa       Expiration: October 1999                [Page 1]


Internet Draft           RSVP ID-based Refresh                April 1999


   differentiated services (diffserv) [RFC2475] has challenged this
   problem. Diffserv is expected to replace the role of intserv in the
   internet backbones. However, to provide the end-to-end QoS, we still
   need an end-to-end signaling protocol, and the only usable signaling
   protocol now is RSVP. In fact, [Baker] and other drafts propose to
   use RSVP as a signaling protocol for diffserv.

   If we assume the aggregation region of [Baker] is a DS domain, RSVP
   will be used (a) between a DS boundary node of a DS domain and an
   external node which may be in a different DS domain or in an intserv
   domain, (b) between DS boundary nodes of the same DS domain (for
   individual reservation, bypassing interior nodes), (c) between two
   RSVP neighbor nodes within the same DS domain (for behavior
   aggregates).

   Because the number of diffserv codepoints and the number of boundary
   nodes are limited, (c) should not cause a scalability problem.

   Scalability problems in the case of (a) and (b), however, still
   exist.  The refresh reduction draft [Berger] alleviates some of the
   problems using several techniques. The techniques include refresh
   suppression and packaging multiple RSVP messages into one message
   (called aggregate messages; should not be confused with the
   reservation aggregation in [Baker]).

   The purpose of this document is to provide some discussion on that
   draft and show some enhancements. Although multicast case will be
   mentioned, it is not discussed extensively.

   The extensions introduced in this draft surely complicate the
   programming of RSVP process, but alleviate the RSVP processing cost
   and the bandwidth required for refresh messages in the environments
   where route change must be detected via PATH messages. Whether such
   environments will exist in the core of the future internet, remains
   to be seen.

2. Definition of route change

   Let us defined what "route change at a node" means in the following
   discussion.  Route is said to have changed at an RSVP node when:
      after sending the first PATH message for a session from this node,
         the stream of packets for which this PATH message is intended
         still goes through this node and
         the next RSVP-capable node (or set of nodes of a multicast
         group) for this stream has changed, or the outgoing interface
         (or interfaces) for this stream has changed.

   Note that this definition only concerns outgoing route from this



Yuhara & Tomikawa       Expiration: October 1999                [Page 2]


Internet Draft           RSVP ID-based Refresh                April 1999


   node.  When the packets under consideration are no longer received by
   this node due to a route change, the route is considered to have
   changed at some upstream node, not at this node.

   There are three cases for route change:

   (case 1) There is no route change for this outgoing interface.  An
         example is an outgoing interface of a diffserv boundary node
         that connects to another diffserv boundary. Since this kind of
         link tend to be stable for a long period, we can consider that
         there is no route change at this node. Maintenance shutdown may
         be required, but that can be considered as a rare exception and
         may be manually handled (for example, shutting down rsvp
         processes on both sides).

   (case 2) The route change may happen, but the necessary route change
         information is provided to the rsvp process as soon as
         possible.  The information may be provided by means of routing
         protocols or management protocols, or by measurements.  In this
         case, if the no-refresh option (Last_Refresh) [Berger] is
         enabled and the (old) next hop has already registered an ID-
         based state for PATH of this stream, that state must be
         explicitly revoked.  Otherwise, the state would remain there
         forever. We will discuss this case in section 4.

   (case 3) The route change may happen, and the necessary route change
         information is NOT provided to the rsvp process.  In this case,
         we have to rely on the PATH refreshes.  However, by exchanging
         the ID between RSVP neighbor nodes, we can drastically reduce
         the amount of PATH message size.  We will discuss this case
         first.

3. ID-only PATH refreshes

   In (case 3), route change is detected using PATH refreshes, thus we
   cannot eliminate PATH refreshes.  In [Baker], detection of route
   change within a domain depends on the refreshes of individual PATH
   messages. An example of route change is shown below. Individual PATH
   messages are not interpreted by interior nodes (Rx) but by boundary
   nodes (ingress, egress1, egress2).











Yuhara & Tomikawa       Expiration: October 1999                [Page 3]


Internet Draft           RSVP ID-based Refresh                April 1999


      Before route change

        [ingress] -----> [R1] -----> [R2] ------> [R3] -----> [egress1]

      After route change

        [ingress] -----> [R1] -----> [R2] ---+
                                             |
                                             +--> [R4] -----> [egress2]

   In general, the interior routing protocol does not inform the ingress
   node of the route change at R2 (although some protocols could do so,
   such protocols cannot be assumed in general).

   Since the number of reservations on a DS boundary node may get large,
   we still want the processing overhead and bandwidth overhead be small
   to alleviate the scalability problem.

   The ID-based refresh in [Berger] helps to quickly find a
   corresponding state in the receiving node and to instantly check the
   equality of the previous message and the incoming message
   (Last_Refresh flag off).

   In this draft, we further reduce the overhead by removing unnecessary
   information from the PATH refresh. A PATH message with an ID consists
   of the following elements (size is shown by the number of 4-byte
   words).

                       Words
      ------------------------------
      Common Header     2
      INTEGRITY         0-         (9 for HMAC-MD5)
      MESSAGE_ID        2          [Berger]
      SESSION           3          (IPv4)
      RSVP_HOP          3          (IPv4)

      TIME_VALUES       2
      POLICY_DATA       0-
      SENDER_TEMPLATE   3          (IPv4)
      SENDER_TSPEC      9          (INTSERV)
      ADSPEC          about 21     (21 for General Param, Guaranteed Service,
                                    Controlled-Load Service, no override)

   Some objets are optional and vary in size.  In particular, some
   people has been worried that a POLICY_DATA object gets large
   (possibly gets larger than MTU). So a PATH message could be very
   large.




Yuhara & Tomikawa       Expiration: October 1999                [Page 4]


Internet Draft           RSVP ID-based Refresh                April 1999


   Now, we propose ID-only PATH refreshes. ID-only PATH refresh reduces
   the PATH message size, once the PATH is confirmed. The ACK mechanism
   in [Berger] is used for confirmation. ID-only PATH message looks like
   this:

           <Path Refresh Message> ::= <Common Header> [ <INTEGRITY> ]

                                      <MESSAGE_REFRESH>

                                      <SESSION> <RSVP_HOP>

   MESSAGE_ID ACK object is defined in [Berger]. The MESSAGE_REFRESH
   object is similar to the MESSAGE_ID object in [Berger] but has a
   different class number:

   MESSAGE_REFRESH class
     Class-Num is of 0bbbbbbb form (must report error if this object is
     unknown) and should be assigned by IANA.

   REFRESH_ID object

     Class = MESSAGE_REFRESH class, C-Type = 1

          +-------------+-------------+-------------+-------------+
          |  Reserved   |               Message ID                |
          +-------------+-------------+-------------+-------------+

           Reserved: reserved and must be zero.
           Message ID: Latest ID for this PATH state. The ID must have
                       been acknowledged by the next hop(s).


   The IP header is the same as normal PATH messages. The IP destination
   address is the session address. Unfortunately, since PATH REFRESH
   messages must detect route change, PATH REFRESH messages cannot be
   aggregated in a single message [Berger], whose destination address is
   the address of the common next hop.

   The recipient hop of this PATH REFRESH message must behave as if the
   full PATH message previously received with this Message ID was
   received, if such message was received from the same RSVP_HOP and
   this node has sent its acknowledgement. However, this node does not
   have to send another acknowledgment even if the original message
   requested it.

   In this way, the total message size is reduced significantly.  If we
   assume the numbers above, the message is reduced from 45 words to 10
   words. If the POLICY_DATA object is very large, the reduction is more



Yuhara & Tomikawa       Expiration: October 1999                [Page 5]


Internet Draft           RSVP ID-based Refresh                April 1999


   effective. The smaller gets the message size, the smaller gets the
   message handling cost. In addition, the bandwidth required for PATH
   refreshes is reduced.

   The rest of this section describes how route change is handled when
   ID-only PATH refresh is used.

   If a PATH receiving node has never heard of the Message ID from the
   RSVP_HOP, or if this node has not send an acknowledgment for the
   Message ID, then this node considers it detects a route change at
   RSVP_HOP, and explicitly requests the RSVP_HOP node to send a full
   PATH message. The request message is sent to the sending node
   (RSVP_HOP) as follows:

        <Refresh Request Message> ::= <Common Header> [ <INTEGRITY> ]

                                      [ <MESSAGE_ID ACK> ... ]

                                      <MESSAGE_REQUEST>

                                      <SESSION> <RSVP_HOP>

   REFRESH_REQUEST object

     Class = MESSAGE_REFRESH class, C-Type = 2

          +-------------+-------------+-------------+-------------+
          |  Reserved   |               Message ID                |
          +-------------+-------------+-------------+-------------+

           Reserved: reserved and must be zero.
           Message ID: The received Message ID that should be sent
                       again in full format.

   If a PATH sending node receives Refresh Request message with an ID
   registered in this node, the node must send a full PATH message with
   a newly allocated ID.

   The PATH state in the receiving node will timeout if PATH or PATH
   Refresh messages are not received for a long time as defined in
   [RFC2205].  Or, it may be explicitly revoked by Invalidate ID
   Messages described in the next section.

   An RSVP node that does not support this extension will report a Path
   Error when it receives a Path Refresh message, since it does not know
   the REFRESH_ID object and its class is requesting an error report if
   the object is unknown to the node. The SESSION and RSVP_HOP objects
   are included in the Path Refresh Message so that such node can



Yuhara & Tomikawa       Expiration: October 1999                [Page 6]


Internet Draft           RSVP ID-based Refresh                April 1999


   construct a Path Error message.  The PATH sending host which receives
   a Path Error must first check if the previous PATH message was an
   ID-only PATH, and if so, it should not forward the Path Error message
   upstream, but should reset the ID-based state and send a full PATH
   message. If the error reporting node only supports conventional RSVP,
   it will not send back an acknowledgment, so the sending node
   continues to send full PATH messages.

   We could use Path Error in place of Refresh Request.  However, we
   provide a separate message type for easier handling.

   The above route change handling for ID-only refreshes can also be
   used for multicast sessions when ID-only refreshes are used. If a new
   node joins a multicast group down-stream of a PATH sending node, and
   the rsvp process of the PATH sending node is not informed of the
   change, then the new node will request a full PATH message or will
   report an error, since it receives unknown ID-only PATH refreshes.
   The PATH sending node can try to re-establish ID-based relations with
   all neighbor members.

4. Route change handling when refresh is suppressed

   This section discusses the extension to [Berger] for previously
   described (case 2). In this case, The route change may happen, but
   the information on route change at this node is provided to the rsvp
   process. With this information, the node can re-establish the PATH
   state with a new next hop.

   However, there is no means to revoke the old state in the old next
   hop. We cannot use a Path Tear message for this purpose, because Path
   Tear has the ultimate destination as its IP address and it would now
   be routed to the new next hop. We need a message that can directly
   reach the old next hop. To this end, we define INVALIDATE_ID RSVP
   messages.

          <Invalidate ID Message> ::= <Common Header> [ <INTEGRITY> ]

                                      [ <MESSAGE_ID ACK> ... ]

                                      <MESSAGE_ID>

                                      <INVALIDATE_ID>


   INVALIDATE_ID object

     Class = MESSAGE_REFRESH class, C-Type = 3




Yuhara & Tomikawa       Expiration: October 1999                [Page 7]


Internet Draft           RSVP ID-based Refresh                April 1999


          +-------------+-------------+-------------+-------------+
          |  Reserved   |               Message ID                |
          +-------------+-------------+-------------+-------------+

           Reserved: reserved and must be zero.
           Message ID: The Message ID that should be invalidated.

   The host must retransmit the Invalidate ID Message until it is
   acknowledged, or a maximum retry limit is reached (or Hello Message
   has timed-out and all relating states are cleared).  Since this
   message must be acknowledged, the message ID for this message is
   included in the message.

   If a host receives an Invalidate ID Message that has a matching
   state, the host must invalidate the state and send an acknowledgment.
   The host must be prepared to repeatedly receive the same
   INVALIDATE_ID messages, since the acknowledgment may be lost in the
   network.

6. Possible modification to the RSVP aggregate reservation

   The RSVP aggregate reservation proposed in [Baker] installs states in
   DS-ingress and DS-egress boundary nodes to aggregate reservations.
   Since this state handling is very similar to the one for ID-based
   refreshes, reservation aggregation mechanism can relay on the ID-
   based states.

   In [Baker], Path Error messages with error code of NEW-AGGREGATE-
   NEEDED are used for two purposes.  One is for the ingress node to
   identify an egress node for the session. This Path Error can be
   replaced by an acknowledgment for the PATH message. The other is for
   an egress node to request re-establishment of the states when it
   receives an unknown PATH (due to route change).  This Path Error can
   be replaced by a Refresh Request message.  By combining [Baker] and
   [Berger] in this way, we can eliminate the duplicate state
   management.

Security Considerations

   No new security issues are raised in this document. See [RFC2205] for
   a general discussion on RSVP security issues.

References

   [Baker] Baker, F., Iturralde, C., Le Faucheur, F., Davie, B.,
   "Aggregation of RSVP for IP4 and IP6 Reservations", Work In Progress,
   draft-baker-rsvp-aggregation-00.txt, February 1999.




Yuhara & Tomikawa       Expiration: October 1999                [Page 8]


Internet Draft           RSVP ID-based Refresh                April 1999


   [Berger] Berger, L., Gan, D., Swallow, G., "RSVP Refresh Reduction
   Extensions", draft-berger-rsvp-refresh-reduct-00.txt, Work In
   Progress, March 1999.

   [Bernet] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
   Nichols, K., Speer, M., Braden, R., "Interoperation of RSVP/Int-Serv
   and Diff-Serv Networks", Work In Progress, draft-ietf-diffserv-rsvp-
   02.txt, February 1999.

   [Pan] Pan, P., Schulzrinne, H., Guerin, R., "Staged Refresh Timers
   for RSVP", draft-pan-rsvp-timer-00.txt, Work In Progress (already
   expired), November 1997.

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

   [RFC2209] Braden, R., Zhang, L., "Resource ReSerVation Protocol
   (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September
   1997.

   [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
   Services", RFC 2210, September 1997.

   [RFC2208] Baker, F., Braden, B., Bradner, S., O`Dell, M., Romanow,
   A., Weinrib, A., Zhang, L., "Resource ReSerVation Protocol (RSVP)
   Version 1 Applicability Statement Some Guidelines on Deployment", RFC
   2208, September 1997.

   [RFC2215] Shenker, S., Wroclawski, J., "General Characterization
   Parameters for Integrated Service Network Elements", RFC 2215,
   September 1997.

   [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
   Weiss, W., "An Architecture for Differentiated Services", RFC 2475,
   December 1998.

Author's Address

   Masanobu Yuhara
   Fujitsu Laboratories Ltd.
   4-1-1 Kamikodanaka, Nakahara-ku
   Kawasaki, 211-8588, Japan
   Phone: +81-44-777-1111
   Email: yuhara@flab.fujitsu.co.jp

   Mayumi Tomikawa
   Fujitsu Laboratories Ltd.



Yuhara & Tomikawa       Expiration: October 1999                [Page 9]


Internet Draft           RSVP ID-based Refresh                April 1999


   4-1-1 Kamikodanaka, Nakahara-ku
   Kawasaki, 211-8588, Japan
   Phone: +81-44-777-1111
   Email: ohya@flab.fujitsu.co.jp















































Yuhara & Tomikawa       Expiration: October 1999               [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/