Internet DRAFT - draft-fu-rsvp-multicast-analysis

draft-fu-rsvp-multicast-analysis





Network Working Group                                              X. Fu
Internet-Draft                                  University of Goettingen
Expires: April 16, 2003                                       C. Kappler
                                                           H. Tschofenig
                                                              Siemens AG
                                                        October 16, 2002


                  Analysis on RSVP Regarding Multicast
                draft-fu-rsvp-multicast-analysis-01.txt

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.

   This Internet-Draft will expire on April 16, 2003.

Copyright Notice

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

Abstract

   RSVP version 1 has been designed for optimum support multicast.
   However, in reality multicast is being used much less frequently than
   anticipated.  Still, even for unicast (one sender, one receiver)
   full-fledged multicast-enabled RSVP signaling must be used.  As
   pointed out in the NSIS requirement draft, multicast would not be
   necessarily required for an NSIS signaling protocol.  This draft
   analyses ingredients of RSVP Version 1 which are affected by
   multicast, and derives how these ingredients may look like if
   multicast is not supported in the generic RSVP signaling protocol and



Fu, et al.               Expires April 16, 2003                 [Page 1]

Internet-Draft          RSVP Multicast Analysis             October 2002


   adapt related functionalities accordingly - we call the resulting
   feature set "RSVP Lite", a potentially more light-weight version of
   RSVP.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Multicast-Influenced Ingredients in RSVP . . . . . . . . . . .  4
   2.1 Reservation Styles and Scope Object  . . . . . . . . . . . . .  4
   2.2 Limitation on Receiver-Initiated Reservation . . . . . . . . .  4
   2.3 Coupled QoS Specification with the Generic Signaling
       Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.4 Complex State Merging Operation in the Routers for
       Signaling  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.5 Killer Problems and Error/Failure Handling . . . . . . . . . .  5
   3.  Towards a Light-weight RSVP: RSVP Lite . . . . . . . . . . . .  6
   3.1 No Reservation Styles and Scope Object . . . . . . . . . . . .  6
   3.2 Decoupling Signaled Data from Signaling  . . . . . . . . . . .  6
   3.3 No Restriction on Sender- or Receiver-Initiation . . . . . . .  6
   3.4 Simpler State Management in Routers  . . . . . . . . . . . . .  7
   3.5 Simplified Error Handling  . . . . . . . . . . . . . . . . . .  7
   3.6 Message Types  . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.7 Mobility Consideration . . . . . . . . . . . . . . . . . . . .  8
   3.8 Multicast Consideration  . . . . . . . . . . . . . . . . . . .  8
   3.9 Potential Advantages of RSVP Lite  . . . . . . . . . . . . . .  8
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   5.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 11
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14





















Fu, et al.               Expires April 16, 2003                 [Page 2]

Internet-Draft          RSVP Multicast Analysis             October 2002


1. Introduction

   As a signaling protocol designed specifically for the Internet, RSVP
   Version 1 (RSVPv1)[1][2][3] distinguishes itself by a number of
   fundamental ways, particularly, soft state management, two-pass
   signaling message exchanges, receiver-based resource reservation and
   separation of QoS signaling from routing (in the sense that RSVP
   messages follow normal IP routing).  However, RSVP end-to-end
   signaled QoS for the Internet has not become a reality.  One reason
   for this is regarded the complexity brought by multicast [8].   In
   fact, vast majority of applications do not use multicast in reality.
   Some multicast protocols (e.g., PIM-SM [4]) even consider multicast
   as a function built on top of unicast routing rather than as an
   integral part of it.  We notice that multicast is not listed as a
   (mandatory) requirement in the NSIS requirements draft [7].

   This draft analyses ingredients of RSVP Version 1 which are needed to
   support multicast.  Compared with standard RSVP, the following
   features could be simplified or would even not be needed if multicast
   is removed from RSVP:

   o  Unnecessary reservation styles and scope object in the signaling
      protocol;

   o  Limitation on receiver-initiation;

   o  Coupled QoS specification and signaling support;

   o  Complex state structure and merging operation in the routers for
      the signaling;

   o  Killer problems and error/failure handling.

   This list might not be comprehensive, but we believe it covers main
   features.  We find that removing multicast capability from RSVP
   generic signaling (and adpting related functionalities accordingly)
   will make it considerably more light-weight.














Fu, et al.               Expires April 16, 2003                 [Page 3]

Internet-Draft          RSVP Multicast Analysis             October 2002


2. Multicast-Influenced Ingredients in RSVP

   This section analysis the ingredients in RSVPv1 influenced by
   multicast.

2.1 Reservation Styles and Scope Object

   To accommodate the multipoint-to-multipoint multicast applications,
   RSVP was designed to support a vector of reservation attributes
   called the "style".  There are two attributes in RSVPv1:

      Sharing attribute, with value "Shared" (all senders share a single
      reservation) or "Distinct" (every sender has a seperate
      reservation);

      Sender Selection attribute, with value "Explicit" (select
      explicitly a specific sender), "Wildcard" (applies to all
      senders).


2.2 Limitation on Receiver-Initiated Reservation

   Receiver-initiated is critical for RSVP to setup multicast sessions
   with a large number of receivers.  RSVP is optimized for a large
   number of receivers with heterogeneous request, and therefore deploys
   the receiver-initiated approach: a receiver initiates a reservation
   request at a leaf of the multicast distribution tree, travelling
   towards the sender.  Whenever a reservation is found to already exist
   in a node in the distribution tree, the new request will be merged
   with the existing reservation.  This could result in fewer signalling
   operations for the RSVP nodes close to the sender, and new receivers
   are handled completely by the receivers and the network without
   bothering the sender.  In comparison, for sender-initiated
   reservation, when the reservation request travels up the multicast
   tree towards the intended heterogeneous receivers, it is necessary to
   distribute its reservation request information to all hops on the
   multicast tree between source and receivers.  This implies gathering
   receivers' QoS information from receivers beforehand and results in
   more signaling overhead.

2.3 Coupled QoS Specification with the Generic Signaling Protocol

   To effectively signal QoS to the network, Path messages carry traffic
   characteristic information (Sender_TSpec) as well as network
   capability information gathered (ADSpec), while a Resv message
   carries QoS information (FlowSpec, which includes TSpec and RSpec)
   requested by the receiver.  These specs are particularly designed for
   multicast QoS resource reservation in the Integrated Service model,



Fu, et al.               Expires April 16, 2003                 [Page 4]

Internet-Draft          RSVP Multicast Analysis             October 2002


   where FlowSpecs should be merged when a Resv message is received by
   an RSVP router where multicast delivery replicates data packets.

2.4 Complex State Merging Operation in the Routers for Signaling

   Each RSVP router uses a Path state to maintain a table of TSpec
   information for each multicast session, in addition to outgoing
   interfaces of the previous RSVP hop and previous RSVP hop addresses.
   An RSVP router also uses a Resv state to maintain next RSVP hop
   address (used to distinguish its route from other multicast session)
   and FlowSpec.  When a router finds multicast delivery replicates data
   packets, those specs related to the downstream reservations should be
   merged, and appropriate reservation parameters should be passed
   upstream.

2.5 Killer Problems and Error/Failure Handling

   For reservation errors (e.g., admission control fails), a ResvErr
   message should be reported to all of the responsible receivers.
   Furthermore, it may result in "killer problems", i.e., if the path
   towards the source has sufficient resources for the smaller of the
   reservations but not for the merged request for the multicast, then
   the effect of merging can be to deny reservations to both.
   Therefore, the error processing of in RSVPv1 is rather complex.
   Furthermore, a blockade state is introduced to solve the one of the
   killer problems (KR-II), which is denial of (reservation) service by
   a large and failing reservation.  After a reservation's failure is
   recorded in the blockade state created by ResvError messages, merging
   will take this into account.






















Fu, et al.               Expires April 16, 2003                 [Page 5]

Internet-Draft          RSVP Multicast Analysis             October 2002


3. Towards a Light-weight RSVP: RSVP Lite

   Based on the analysis above, this section describes how RSVP would
   look like if removing its multicast capabilities and adapting other
   related functionalizties of RSVP.  For the convenience of the
   following discussion, the abbreviation "RSVP Lite" is used to stand
   for the possible feature set that follows.

   Like in RSVPv1, soft-state and security mechanisms would still be
   interesting to be used in RSVP Lite; signaling in the RSVP Lite is
   also separated from routing in routers; the data flow definition
   follows the same (i.e., consists of a session = <dstIP, protoId,
   dstPort> and a filter spec = <srcIP, srcPort>).

   However, RSVP Lite will bring a number of simplifications to RSVPv1.
   In the following paragraphs, these features are briefly described.

3.1 No Reservation Styles and Scope Object

   Styles in RSVPv1 are used for specifying the sender set for a
   reservation request and whether these senders share a single
   reservation.  Beside, a scope object is used in Resv messages to
   carry an explicit list of sender hosts towards which the information
   in the message is to be forwarded.  In RSVP Lite a receiver has only
   one sender, therefore styles are not needed any more.  Then all
   related burden like merging are released from RSVP Lite.

3.2 Decoupling Signaled Data from Signaling

   Path/Resv messages will not be responsible for creation and merging
   of multicast reservation sink trees, they are only responsible for
   creation and maintaining the appropriate states.  The signaled data
   are handled by upper level protocol(s) being carried by RSVP Lite
   (e.g., ALSP described in [10]).  Typically, one-way service signaling
   (Path message) would suffice for setting-up the states from any node
   towards another node in the Internet.  However, to give the signaling
   source a chance to see whether and how its service signaling (Path)
   has been succeed, a confirm message (Resv) still is necessary for
   RSVP Lite, with an optional object to record the last failed node
   (when failed).

3.3 No Restriction on Sender- or Receiver-Initiation

   Unlike in RSVPv1, it is not necessary for RSVP Lite to be always
   receiver-initiated, because there is only one receiver, and no
   merging is necessary from the receiver to the sender.  It is up to
   the upper level of signaling protocols to decide which way to
   initiate.  In addition, RSVP Lite does not rely on the multicast



Fu, et al.               Expires April 16, 2003                 [Page 6]

Internet-Draft          RSVP Multicast Analysis             October 2002


   membership, therefore can initiate and respond the signaling at any
   node in the Internet, i.e., the placement of its signaling source and
   destination is flexible.  Thus it is able to support other signaling
   models like host-to-network and edge-to-edge in a simple way in
   addition to end-to-end signaling.

3.4 Simpler State Management in Routers

   In RSVP Lite, there is no need to keep blockade states in routers,
   only Path and Resv states would suffice.  Hop-by-hop refreshes are
   also simpler since Path/Resv refreshment messages neither need to be
   distributed towards the multiple receivers/senders nor need to be
   merged.

3.5 Simplified Error Handling

   Although there still are a few possibilities of error sources in RSVP
   Lite, most of the issues like killer problems become rather easier to
   handle since: (1) there is no need to merge states for multicast
   sessions in the RSVP routers, so the number of possible error source
   decreases; (2) the error reports can be simply returned back to the
   unicast sender.

3.6 Message Types

   The possible types for messages involved in the signaling process of
   RSVP Lite are listed as follows.

      Path (or Request): for signaling request and state refreshment.
         This message in fact takes only part of responsibilities of
         Path messages in RSVP, and the real semantic of the signaled
         data is defined by seperate protocols.  We call these seperate
         protocols ``client protocols'' and an example is the QoS client
         protocol.  These client protocol elements are encoded into the
         Path (Request) messages  - and Resv (Response) message when
         necessary - which are simular to the concept of ALSP [10].

      PathErr: for reporting errors in processing Path messages.

      PathTear: for tear down of Path state.  PathTear message is sent
         by the sender towards the receiver or the IP address where the
         Path (Request) was rejected to explicitly delete or adapt
         associated states;

      Resv (or Response): indicating whether a signaling request is
         accepted and whether to adpt in the reverse direction
         (``Commit'') or rejected (``Reject'').  The actual reverse
         directional functionalities (mainly reserve for resources) of



Fu, et al.               Expires April 16, 2003                 [Page 7]

Internet-Draft          RSVP Multicast Analysis             October 2002


         Resv message in RSVP is no longer necessary.  However, in RSVP
         Lite, two-pass message exchange would be still necessary for
         setting up proper states in the nodes along the data path from
         the signaling requester to the signaling receiver.  A Resv
         (Response) message with ``reject'' flag set shares the same
         type as the ``Commit'' one, but the IP address where the Path
         reservation is rejected can be included.  This provides the
         signaling sender a flexibility in deciding whether to still use
         the signaled segment for its session, or to clean up the
         established states along the path.

   For QoS signaling purposes, it is further possible to simplify and
   optimize traffic description and QoS specification in the QoS client
   protocol by introducing a ``QoS profile (with acceptable and desired
   QoS level)'' into the QoS-client protocol for RSVP Lite.  To support
   different QoS provisioning techniques and optimize the signaling
   procedure, the FlowSpec in Resv messages and the SenderTSpec/ADSpec
   in Path messages of RSVP could be unified to a ``QoS profile'', e.g.,
   as defined in [14].  In the QoS profile of a Path (Request) message,
   the sender can state its desired QoS and (minimally) acceptable QoS,
   as well as its traffic characteristics (this allows the routers a
   flexibility to dynamically adapt its reservation in dynamic
   environments).  A QoS profile with actually reserved QoS information
   can be attached in the Resv (Response) message.

3.7 Mobility Consideration

   TBD - Ideas of existing RSVP mobility schemes e.g., "Localized RSVP"
   [12], "Mobile Extension for RSVP" [13] can be ported.  It is also
   possible for RSVP Lite to release the unused states and establish new
   states without much pain following the ideas of mobility/route change
   handling in CASP design [11]; special attention should be paid to
   session identifiers.

3.8 Multicast Consideration

   TBD - It would be useful for RSVPm/oMC to provide limited support for
   some of multicast models.  One possibility is to provide a special
   interface to access the multicast routing tables.  A limited support
   for SSM multicast [9] is provided in CASP [11] and its idea may also
   applies for RSVP Lite.

3.9 Potential Advantages of RSVP Lite

   According to the discussion above, RSVP Lite potentially has a number
   of advantages over RSVPv1:

      Reduction in signaling set-up time.  Because RSVP Lite can be



Fu, et al.               Expires April 16, 2003                 [Page 8]

Internet-Draft          RSVP Multicast Analysis             October 2002


      sender- and receiver-initiated without additional message
      exchange, the signaling set-up time will be one-pass less than in
      RSVPv1 in a sender-initiated signaling scenario.

      Different modularity and more flexibility.  RSVP Lite does not
      intend to optimize for multicast, instead keeping the RSVP Lite
      signaling integrants as minimal as possible, while freely putting
      initiator and responder.  Decoupling signaled data and signaling
      message makes it more flexible and applicable to many other
      signaling purposes besides QoS signaling.

      Reduction in processing overhead due to (1) no need to carry
      unncessary component and interpret signaled data in the basic
      signaling protocol (RSVP Lite), (2) no need to merge for multicast
      sessions and (3) simpler handling of errors and failures.




































Fu, et al.               Expires April 16, 2003                 [Page 9]

Internet-Draft          RSVP Multicast Analysis             October 2002


4. Security Considerations

   By removing multicast support from RSVP, message processing is
   simplified as explained throughout this document.  However, there is
   little room for optimization in security aspect.  Integrity and
   replay protection of RSVP signaling messages as offered by RFC2747
   [5] is still required to provide security on a hop-by-hop basis.
   Additionally, the integrity handshake mechanism used for recovering
   from host or router crash to offer sequence number resynchronization
   is required.  In order to support policy based admission control and
   authentication of the user via Kerberos, digital signature or plain-
   text credentials the objects described in [6] have to be present.
   Multicast processing of the policy locator inside the POLICY_DATA
   object can be simplified in such a way that the policy locator is
   copied from the received to the new message.  The same procedure has
   to be applied for the AUTH_DATA object which is also left unchanged
   and forwarded (i.e.  copied to the new RSVP message).

   Section 7 of [5] states that in the multicast case all receivers must
   share a single key with the Kerberos Authentication Server (i.e.  a
   single Kerberos principal is used).  Removing multicast allows
   avoiding the case where all receivers must share a single key.

   Whether it is possible to simplify processing of POLICY_DATA objects
   altogether needs further investigation.


























Fu, et al.               Expires April 16, 2003                [Page 10]

Internet-Draft          RSVP Multicast Analysis             October 2002


5. Acknowledgement

   Mehmet Ersue and Robert Hancock provided useful comments.
















































Fu, et al.               Expires April 16, 2003                [Page 11]

Internet-Draft          RSVP Multicast Analysis             October 2002


References

   [1]   Braden, R., Estrin, D., Berson, S., Herzog, S. and D. Zappala,
         "The Design of the RSVP Protocol", ISI Final Technical Report ,
         Jul 1996.

   [2]   Zhang, L., Deering, S., Estrin, D. and D. Zappala, "RSVP: A New
         Resource Reservation Protocol", IEEE Network, Volume 7, Pages
         8-18, Sep 1993.

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

   [4]   Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
         Handley, M. and V. Jacobson, "Protocol Independent Multicast-
         Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, Jun
         1998.

   [5]   Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic
         Authentication", RFC 2747, Jan 2000.

   [6]   Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
         Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC
         3182, Oct 2001.

   [7]   Brunner, M., "Requirements for Signaling Protocols", draft-
         ietf-nsis-req-04 (work in progress), Aug 2002.

   [8]   Freytsis, I. and et al, "Next Steps in Signaling: Framework",
         draft-ietf-nsis-fw-00 (work in progress), Oct 2002.

   [9]   Bhattacharyya, S. and et al, "An Overview of Source-Specific
         Multicast(SSM) Deployment", draft-ietf-ssm-overview-03 (work in
         progress), Mar 2002.

   [10]  Braden, B. and B. Lindell, "A Two-Level Architecture for
         Internet Signaling", draft-braden-2level-signal-arch-00 (work
         in progress), Nov 2001.

   [11]  Schulzrinne, H. and et al, "CASP -  Cross-application Signaling
         Protocol", draft-schulzrinne-nsis-casp-00 (work in progress),
         Sep 2002.

   [12]  Manner, J. and et al, "Localized RSVP", draft-manner-lrsvp-00
         (work in progress), May 2002.

   [13]  Shen, C. and et al, "Mobility Extensions to RSVP in an RSVP-



Fu, et al.               Expires April 16, 2003                [Page 12]

Internet-Draft          RSVP Multicast Analysis             October 2002


         Mobile IPv6 Framework", draft-shen-nsis-rsvp-mobileipv6-00
         (work in progress), Jul 2002.

   [14]  Westphal, C. and et al, "Context Relocation of QoS Parameters
         in IP Networks", draft-westphal-seamoby-qos-relocate-00 (work
         in progress), Jul 2001.


Authors' Addresses

   Xiaoming Fu
   University of Goettingen
   Telematics Group
   Lotzestr. 16-18
   Goettingen  37083
   Germany

   EMail: fu@cs.uni-goettingen.de


   Cornelia Kappler
   Siemens AG
   Siemensdamm 62
   Berlin  13623
   Germany

   EMail: Cornelia.Kappler@icn.siemens.de


   Hannes Tschofenig
   Siemens AG
   Otto-Hahn-Ring 6
   Munich  81739
   Germany

   EMail: Hannes.Tschofenig@mchp.siemens.de















Fu, et al.               Expires April 16, 2003                [Page 13]

Internet-Draft          RSVP Multicast Analysis             October 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.

 

    
    



















Fu, et al.               Expires April 16, 2003                [Page 14]