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 = and a filter spec = ). 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]