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

Versions: 00 01 02 03 04 05 RFC 4094

Internet Engineering Task Force                          J. Manner (ed.)
Internet-Draft                                               X. Fu (ed.)
Expires: April, 2003
                                                        October 28, 2002

        Analysis of Existing Quality of Service Signaling Protocols

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

   The list of Internet-Draft Shadow Directories can be accessed at

   Distribution of this memo is unlimited.

   This Internet-Draft will expire in April, 2003.

   Copyright Notice

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

   All comments to this work should be directec to the NSIS mailing at


   This document presents a review of existing protocols for signalling
   the Quality of Service requirements of flows to nodes in an IP
   network. Protocols are reviewed independently and not compared
   against the NSIS requirements document nor to RSVP itself. The
   purpose is to learn from existing work and to avoid common
   misconceptions about the protocols. A further goal is to avoid to
   redesign ideas already implemented in another protocol.

Manner et al               Expires April 2003                   [Page 1]

Internet-Draft          Analysis of QoS Signaling           October 2002

TODO items

   - Evaluate the rest of the protocols
   - Add more protocols? Remove protocols?

Table of Contents

   1 Introduction .................................................    3
   2 The Resource Reservation Protocol ............................    4
   2.1 Extensions to RSVP .........................................    5
   2.2 Reservation functionality ..................................    6
   2.3 Processing Overhead ........................................    7
   2.4 Bandwidth Consumption ......................................    8
   2.5 Mobility Support ...........................................    8
   2.6 Security ...................................................    9
   2.7 Deployment Issues ..........................................    9
   2.8 Conclusions ................................................   10
   3 YESSIR .......................................................   11
   3.1 Reservation Functionality ..................................   11
   3.2 Processing Overhead ........................................   12
   3.3 Bandwidth Consumption ......................................   12
   3.4 Mobility Support ...........................................   12
   3.5 Security ...................................................   12
   3.6 Deployment Issues ..........................................   12
   3.7 Conclusions ................................................   12
   4 Boomerang ....................................................   12
   4.1 Reservation Functionality ..................................   13
   4.2 Processing Overhead ........................................   13
   4.3 Bandwidth Consumption ......................................   13
   4.4 Mobility Support ...........................................   13
   4.5 Security ...................................................   13
   4.6 Deployment Issues ..........................................   13
   4.7 Conclusions ................................................   14
   5 Other Protocols ..............................................   14
   5.1 INSIGNIA ...................................................   14
   5.2 Mobile RSVP ................................................   15
   5.3 BGRP .......................................................   15
   5.4 ST-II ......................................................   15
   5.5 The ITSUMO Framework .......................................   16
   6 Summary ......................................................   17
   7 Security Considerations ......................................   17
   8 Contributors .................................................   17
   9 Acknowledgement ..............................................   17
   10 References ..................................................   17
   11 Author's Addresses ..........................................   20

Manner et al               Expires April 2003                   [Page 2]

Internet-Draft          Analysis of QoS Signaling           October 2002

1.  Introduction

   The aim of this document is to present existing mature protocols and
   architectures for signalling the Quality of Service (QoS)
   requirements of flows to nodes in an IP network. The various
   protocols are reviewed independently and without comparing against
   the NSIS requirements document, because the protocols have already
   been designed before the work on present requirements was
   initialized. Neither do we want to make any comparison of protocols
   against RSVP because this would of little value - all protocols have
   their own research backgrounds and targets and therefore do things
   differently. We also hope that the NSIS Working Group can learn from
   existing work and we can avoid common misconceptions about the
   protocols. A further goal is to avoid to redesign ideas already
   implemented in an existing protocol.

   There have been a number of historic attempts in delivering QoS or
   generic signaling into the Internet.  In the early years, multicast
   was believed to be going to be popular to majority of communications,
   hence RSVP and earlier ST-II were designed in a way which is
   multicast-oriented. ST-II was developed as a reservation protocol for
   point-to-multipoint communication. However, since it is sender-
   initiated, it does not scale with the number of receivers in a
   multicast group. It is complex and since every sender needs to set up
   its own reservation, the total amount of reservation state is large.
   RSVP was then designed to provide support for multipoint-to-
   multipoint reservation setup in a more efficient way, however its
   complexity, scalability and ability to meet new requirements have
   been criticized.

   YESSIR [PaSc98] and Boomerang [FNM+99] are examples of protocols
   designed after RSVP. Both protocols were meant to be simpler than
   RSVP. YESSIR is an extension to RTCP, while Boomerang is used with

   Previously, there has been a lot of work targeted at creating a new
   signalling protocol for resource control.  Istvan Cselenyi suggested
   to request for QoSSIG BOF in IETF#47 (http://www-nrg.ee.lbl.gov/diff-
   serv-arch/msg05055.html), for identifying problems in QoS signaling,
   but failed. Some people argued, "in many ways, RSVP improved upon
   ST-2, and it did start out simpler, but resulting a design with
   complexity and scalability", while some others thought it is "new
   knowledge and requirements" that made RSVP insufficient (http://www-
   nrg.ee.lbl.gov/diff-serv-arch/msg05066.html), and there is no simpler
   way to handle the same problem as RSVP.

   Michael Welzl organized a special session "ABR to the Internet" in
   SCI 2001, and gathered some inputs for requesting an "ABR to the
   Internet" BOF in IETF#51, which was intended to introduce explicit
   rate feedback related mechanisms for the Internet (e2e, edge2edge)
   but failed because of "missing community interest"

   OPENSIG (http://comet.columbia.edu/opensig/) has been involved in the

Manner et al               Expires April 2003                   [Page 3]

Internet-Draft          Analysis of QoS Signaling           October 2002

   Internet signaling for years. Ping Pan initiated a SIGLITE
   (http://www.cs.columbia.edu/~pingpan/projects/siglite.html) BOF
   mailing list to investigate light-weight Internet signaling. Finally,
   NSIS BOF was successful and the NSIS WG was formed.

   The most mature and original protocols are presented in their own
   sections and other QoS signalling protocols are presented in later

2.  The Resource Reservation Protocol

   RSVP (the Resource ReServation Protocol) [RSVP] [RFC2205] [BEBH96]
   has evolved from ST-II to provide end-to-end QoS signaling services
   for application data streams. Hosts use RSVP to request a specific
   quality of service (QoS) from the network for particular application
   flows. Routers use RSVP to deliver QoS requests to all routers along
   the data path. RSVP also can maintain and refresh states for a
   requested QoS application flow. This section shortly reviews the RSVP
   basic model and its extensions.

   RSVP tries to be well-fit in the Integrated Services (IntServ)
   [RFC2210], [BEBH96] architecture with certain modularity and
   scalability. The design of the RSVP protocol distinguished 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.

   RSVP Signaling Model: The RSVP signaling model is based on a special
   handling of multicast. The sender of a multicast flow advertises the
   traffic characteristics periodically to the receivers via "Path"
   messages. On receipt of an advertisement, a receiver may generate a
   "Resv" message to reserve resources along the flow path from the
   sender. Receiver reservations may be heterogeneous. To accommodate
   the multipoint-to-multipoint multicast applications, RSVP was
   designed to support a vector of reservation attributes called the
   "style". A style describes whether all senders of a multicast group
   share a single reservation and which receiver is applied. The "Scope"
   object additionally provides the explicit list of senders.

   Soft State: Because the number of receivers in a multicast flow is
   likely to change, and the flow of delivery paths might change during
   the life of an application flow, RSVP takes a soft-state approach in
   its design, creating and removing the protocol states in routers and
   hosts incrementally over time. RSVP sends periodic refresh messages
   to maintain its state and to recover from occasional lost messages.
   In the absence of refresh messages, the RSVP states automatically
   time out and are deleted.

   Two-pass Signaling Message Exchanges: The receiver in an application
   flow is responsible for requesting the desired QoS from the sender.
   To do this, the receiver issues an RSVP QoS request on behalf of the
   local application. The request propagates to all routers in reverse
   direction of the data paths toward the sender. In this process, RSVP

Manner et al               Expires April 2003                   [Page 4]

Internet-Draft          Analysis of QoS Signaling           October 2002

   requests might be merged, resulting in a protocol that scales well
   when there are a large number of receivers.

   Receiver-based Resource Reservation: Receiver-initiation is critical
   for RSVP to setup multicast sessions with a large number of
   heterogeneous receivers. A receiver initiates a reservation request
   at a leaf of the multicast distribution tree, traveling 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 in the multicast tree close to the
   sender, but introduce a restriction to receiver-initiation.

   Separation of QoS Signaling from Routing: RSVP messages follow normal
   IP routing. RSVP is not a routing protocol, but rather is designed to
   operate with current and future unicast and multicast routing
   protocols. The routing protocols are responsible for choosing the
   routes to use to forward packets, and RSVP consults local routing
   tables to obtain routes. RSVP is responsible only for reservation
   setup along a data path.

2.1.  Extensions to RSVP

   There have been various extensions to enhance the basic RSVP
   protocol: policy, cryptographic authentication, operation over 802.x
   and ATM, aggregation, tunneling, refresh overhead reduction,
   diagnostics, RSVP-TE, DCLASS, null service, proxy, mobility schemes,
   etc., there have been a large amount of efforts towards a globe-wide
   Internet QoS deployment based on RSVP since its development.

   Note: only Standards Track RFCs are discussed below; informational
   and BCP RFCs (e.g., RFC2998) and I-Ds (e.g., proxy) are not covered

   [RFC2749] specifies the usage of COPS policy services in RSVP

   [RSVP2750] specifies the standard format of POLICY_DATA objects and
   RSVP handling of policy events.

   [RSVP2751] specifies a preemption priority policy element

   L-N. Hamer, et al, draft-ietf-rap-rsvp-authsession-04 (being approved
   by IESG) describes how an RSVP session is authorized by a host and
   provides the host with encoded session authorization information as a
   POLICY_DATA object.

   [RFC2380] presents the implementation requirements for running RSVP
   over ATM switched virtual circuits (SVCs).

   [RFC2814] introduces an RSVP LAN_NHOP address object that keeps track

Manner et al               Expires April 2003                   [Page 5]

Internet-Draft          Analysis of QoS Signaling           October 2002

   of the next L3 hop as the PATH message traverses an L2 domain between
   two L3 entities (RSVP PHOP and NHOP nodes). Both layer-2 and layer-3
   addresses are included in the LAN_NHOP; the RSVP_HOP_L2 object is
   used to include the Layer 2 address (L2ADDR) of the previous hop,
   complementing the L3 address information included in the RSVP_HOP
   object (RSVP_HOP_L3 address).

   To provide sufficient information for debugging or resource
   management, RSVP diagnostic messages (DREQ and DREP) are defined in
   [RFC2745] to collect and report RSVP state information along the path
   from a receiver to a specific sender.

   [RFC2746] describes an IP tunneling enhancement mechanism that allows
   RSVP to make reservations across all IP-in-IP tunnels, basically, by
   way of recursively applying RSVP over the tunnel portion of the path.

   To reduce the refresh volume and maintain reliability, [RFC2961]
   defines a Bundle message to reduce overall message handling load, a
   MESSAGE_ID object to reduce refresh message processing by allowing
   the receiver to more readily identify an unchanged message, and a
   MESSAGE_ACK object to detect message loss and support reliable RSVP
   message delivery on a per hop basis.

   [RFC3175] allows to install one or more aggregated reservations in an
   aggregation region, thus the number of individual RSVP sessions can
   be reduced.

   [RFC3209] specifies the extension to RSVP for establishing explicitly
   routed LSPs in MPLS networks using RSVP as a signaling protocol. An
   EXPLICIT_ROUTE object is incorporated into RSVP Path messages,
   encapsulating a concatenation of hops which constitutes the
   explicitly routed path. Using this object, the paths taken by label-
   switched RSVP-MPLS flows can be pre-determined, independent of
   conventional IP routing.

   Section 5 of RFC3270 further specifies the extensions to RSVP to
   establish LSPs supporting DiffServ in MPLS networks, introducing a
   new DIFFSERV Object (applicable in the Path messages) and using pre-
   configured or (e.g. RFC3270) signaled "EXP<-->PHB mapping".

2.2.  Reservation functionality

   RSVP carries the QoS data of the request through the network,
   visiting each node along the data path. To make a resource
   reservation at a node, the RSVP module communicates with two local
   decision modules, admission control and policy control. Admission
   control determines whether the node has sufficient available
   resources to supply the requested QoS. Policy control determines
   whether the user has administrative permission to make the
   reservation. If either check fails, the RSVP module returns an error
   notification to the application process that originated the request.
   If both checks succeed, the RSVP module sets parameters in a packet

Manner et al               Expires April 2003                   [Page 6]

Internet-Draft          Analysis of QoS Signaling           October 2002

   classifier and packet scheduler to obtain the desired QoS.

   The definition of the required resources is not part of the RSVP
   standard, but commonly the IntServ specifications for Controlled Load
   and Guaranteed Services are used. RSVP allows for unicast and
   multicast reservations. Various filtering rules may be used to
   identify flows belonging to a reservation - commonly the 5-tuple is
   used. RFC 2207 [RFC2207] specifies an RSVP extension to use the IPSEC
   SPI (Security Parameter Index), in place of the UDP/TCP-like ports,
   so that data flows containing IPSEC protocols can be controlled at a
   granularity similar to what is already specified for UDP and TCP.
   The IPv6 Flow Label can also be used as a key in the filters.
   Furthermore, reservations may be distinct or shared by several

   RFC2996 [RFC2996] introduces a DCLASS Object to carry Differentiated
   Services Code Points (DSCPs) in RSVP message objects. If the network
   element determines that the RSVP request is admissible to the diff-
   serv network, one or more DSCPs corresponding to the behavior
   aggregate are determined, and will be carried by the DCLASS Object
   added to the RESV message upstream towards the RSVP sender.

   For some applications, service parameters are specified by the
   network, not by the application (e.g. ERP applications). The Null
   Service [RFC2997] allows applications to identify themselves to
   network QoS policy agents using RSVP signaling, but does not require
   them to specify resource requirements. QoS policy agents in the
   network respond by applying QoS policies appropriate for the
   application (as determined by the network administrator). The RSVP
   sender offers the new service type, 'Null Service Type' in the ADSPEC
   that is included with the PATH message. A new TSpec corresponding to
   the new service type is added to the SENDER_TSPEC. In addition, the
   RSVP sender will typically include with the PATH message policy
   objects identifying the user, application and sub-flow, which will be
   used for network nodes to manage the correspondent traffic flow.

2.3.  Processing Overhead

   RSVP scales in that it supports large multicast groups, at the cost
   of high complexity in dealing with multicast in its basic protocol.
   While the RSVP protocol is also able to make unicast reservations, it
   was designed specifically and optimally for multicast. This important
   RSVP design consideration leads to the fact that, even for unicast
   applications, a full-fledged set of features for supporting multicast
   is still needed, mainly: reservation styles and scope object,
   receiver-initiated reservation, state management in routers, killer
   problems and blockade state handling. A detailed analysis of RSVP
   regarding multicast can be found in [Fu02]. [RaNa98] also identified
   the issue of inefficient resource reservation resulting from
   decentralized multicast routing.

   By way of aggregated RSVP [RFC3175] the complexity (in terms of
   number of states and needed processing overhead) decreases, but still

Manner et al               Expires April 2003                   [Page 7]

Internet-Draft          Analysis of QoS Signaling           October 2002

   depends on the number of (de-)aggregators and topology, which may be
   more than marginal, e.g., in case of many edge nodes or meshed way of
   communications through the aggregate region, and remains complexity
   in dealing with multicast. In fact, many signaling scenarios do not
   need multicast in reality, e.g., typical DiffServ edge router
   resource reservation setup. Some multicast protocols (e.g., PIM-SM
   [RFC2362]) even consider multicast as a function built on top of
   unicast routing rather than as an integral part of it. Since a
   signaling protocol would typically traverse along a number of nodes
   in the Internet, there is a need to keep the mandatory components of
   the signaling protocol as simple as possible, in order to provide a
   simpler but adequate signaling service to various non-multicast
   signaling scenarios.

   Still, for example, the implementation of the daemon can have a huge
   effect on the scalability. In [KaSh01], the authors show that their
   RSVP daemon is able to handle much more flows than the de-facto ISI
   RSVP daemon implementation. Furthermore, the scalability concern
   commonly associated with RSVP are more or less subject to
   individual's views on what "scalability" is.

2.4.  Bandwidth Consumption

   (The frequency and size of the RSVP signaling messages.) During the
   RSVP setup and refresh process, typically there is a two-pass message
   exchange between the sender and the receiver group.  Since the
   refreshment is hop by hop, bandwidth consumption for RSVP could be
   reduced, but may result in more error/failure event handling.


2.5.  Mobility Support

   Two issues raise concern when RSVP is used by a mobile node (MN): the
   reservation identifier and reservation refresh. When an MN changes
   locations, it may need to change one of its assigned IP address. An
   MN may have an IP address by which it is reachable by nodes outside
   the access network and an IP address used to support local mobility
   management. Depending on the mobility management mechanism, a
   handover may force a change in any of these addresses. As a
   consequence the filters associated with a reservation may not
   identify the flow anymore and the resource reservation is lost, until
   a refresh with a new set of filters is initialized.

   The second issue is about following the movement of a mobile node.
   RFC2205 defines that Path messages can perform a local repair of
   reservation paths. When the route between the communicating end hosts
   changes, a Path message will set the state of the reservation on the
   new route and a subsequent Resv message will make the resource
   reservation. Therefore, by sending a Resv message a host cannot alone
   update the reservation, and thus perform a local repair, before a
   Path message has passed. Also, in order to provide fast adaptation to

Manner et al               Expires April 2003                   [Page 8]

Internet-Draft          Analysis of QoS Signaling           October 2002

   routing changes without the overhead of short refresh periods, the
   local routing protocol module can notify the RSVP process of route
   changes for particular destinations. The RSVP process should use this
   information to trigger a quick refresh of state for these
   destinations, using the new route (Chapter 3.6, RFC2205). However,
   not all local mobility protocols, or even Mobile IP, affect routing
   directly in routers, and thus mobility may not be noticed at RSVP
   routers. Thus, it may take a relatively long time before a
   reservation is refreshed following a handover.

   The interactions of RSVP and Mobile IP have been well documented in

2.6.  Security

   To allow a process on a system to securely identify the owner and the
   application of the communicating process (e.g. user id) and convey
   this information in RSVP messages (PATH or RESV) in a secure manner,
   [RFC2752] specifies the encoding of identities as RSVP POLICY_DATA

   To provide hop-by-hop integrity and authentication of RSVP messages,
   RSVP message may contain an INTEGRITY object ([RFC2747]) using a
   keyed cryptographic digest technique which assumes that RSVP
   neighbors share a secret.  (BTW - [RFC3097] updates [RFC2747] to
   resolve a duplication of RSVP message types.)

   The security issues have been well analyzed in [Tsch02].

2.7.  Deployment Issues

   As a well-acknowledged protocol in the Internet, RSVP is being more
   and more expected to provide a more generic service for various
   signaling applications. However, RSVP messages were designed in a way
   to optimally support end-to-end QoS signaling. To meet with the
   increasing demand for a signaling protocol to also operate in host-
   to-edge and edge-to-edge ways, and serve for some other signaling
   purposes in addition to end-to-end QoS signaling, RSVP needs to be
   developed more flexible and applicable for more generic signaling.
   RSVP proxies [BEGD02] extends RSVP by being able to originates or
   receive the RSVP message on behalf of the end node(s), so that
   applications may still benefit from reservations that are not truly
   end-to-end. However, there are certainly scenarios where an
   application would want to explicitly convey its non-QoS purposed (as
   well as QoS) data from a host into the network, or from an ingress
   node to an egress node of an administrative domain, but it must do so
   without burdening the network with excess messaging overhead. Typical
   examples are an end host desiring a firewall service from its
   provider's network and MPLS label setup within an MPLS domain.

   RSVP requires support from network routers and user space

Manner et al               Expires April 2003                   [Page 9]

Internet-Draft          Analysis of QoS Signaling           October 2002

   applications. Domains not supporting RSVP are traversed
   transparently. Unfortunately, like other IP options, RSVP messages
   implemented by way of IP alert option may result in themselfs being
   dropped by some routers [FrJo02].  Although applications need to be
   built with RSVP libraries, one article presents a mechanism that
   would allow any host to benefit from RSVP mechanisms without
   applications awareness [MHS02].

   A somewhat similar deployment benefit can be gained from the
   Localized RSVP [MSK+02]. The draft presents the concept of local
   RSVP-based reservation that can be used to trigger reservation within
   an access network alone. In those cases, an end-host may request QoS
   from its own access network without the co-operation of a
   correspondent node outside the access network. A proxy node responds
   to the messages sent by the end host and enables both upstream and
   downstream reservations. Furthermore, the scheme allows for faster
   reservation repairs following a handover by triggering the proxy to
   initiate an RSVP local repair.

   Still, in end-hosts which are low in processing power and
   functionality, having an rsvp daemon running and taking care of the
   signalling may introduce unnecessary overhead. One article [Kars01]
   proposes to create a remote API so that the daemon would in fact be
   running on the end-host's default router and the end-host application
   would send its requests to that daemon.

   Another potential problem lies in the limited sized of signaled data
   due to the limitation of message size. RSVP message must fit entirely
   into a single non-fragmented IP datagram. Bundle messages ([RFC2961])
   may be as large as an IP datagram, since they may be fragmented. This
   means a maximum size of 64K.

2.8.  Conclusions

   The design of RSVP was originally targeted at multicast applications.
   The result has been that the message processing within nodes is
   somewhat heavy, mainly due to flow merging. Still, merging rules
   could not appear in the specification as they are QoS-specific.

   RSVP has a comprehensive set of filtering rules (WF,FF, shared) and
   is not tied to certain QoS objects (RSVP is not tied to IntServ GS/CL
   specifications). Objects were designed to be modular, but Xspecs
   (TSpec, etc) are more or less QoS-specific and should be more
   generalized; there is no clear layering/separation between the
   signaled data and signaling protocol.

   RSVP uses a soft state mechanism to maintain states and allows each
   node to define its own refresh timer. The protocol is also
   independent of underlying routing protocols. Still, in mobile
   networks the movement of the mobile nodes may not properly trigger a
   reservation refresh for the new path and therefore a mobile node may
   be left without a reservation up to the length of the refresh timer.
   Furthermore, RSVP does not work properly with changing end-point

Manner et al               Expires April 2003                  [Page 10]

Internet-Draft          Analysis of QoS Signaling           October 2002

   identifiers, that is, if one of the IP addresses of a mobile node
   changes, the filters may not be able to identify the flow that had a

   From the security point of view, RSVP does provide the necessary
   building blocks for deploying the protocol in various environments.
   Still, one major problem of RSVP security is that no key distribution
   mechanism is provided.

   Finally, since the publication of the RSVP standard, tens of
   extensions have emerged that allow for much wider deployment than
   RSVP was originally designed for, as for instance, the Subnet
   Bandwidth Manager, the NULL service type, aggregation, operation over
   tunneling and MPLS as well as diagnostic messages.

   Domains not supporting RSVP are traversed transparently by default.
   Unfortunately, like other IP options, RSVP messages implemented by
   way of IP alert option may result in themselves being dropped by some
   routers. Also, the maximal size of RSVP-signaled data is limited.


   YESSIR (YEt another Sender Session Internet Reservations) [PaSc98] is
   a resource reservation protocol that seeks to simplify the process of
   establishing reserved flows while preserving many unique features
   introduced in RSVP. Simplicity is measured in terms of control
   message processing, data packet processing, and user-level
   flexibility. Features such as robustness, advertising network service
   availability and resource sharing among multiple senders are also
   supported in the proposal.

   The proposed mechanism generates reservation requests by senders to
   reduce the processing overhead. It is built as an extension to the
   Real-Time Transport Control Protocol (RTCP), taking advantages of
   Real-Time Protocol (RTP). YESSIR also introduces a concept called
   partial reservation.

3.1.  Reservation Functionality

   YESSIR was designed for one-way, sender-initiated end-to-end resource
   reservation. It also uses soft state to maintain states.  It supports
   resource query (similar to RSVP diagnosis message), advertising
   (similar to RSVP Adspec), shared reservation, partial reservations
   and flow merging.

   To support multicast, YESSIR simplies the reservation styles to
   individual and shared reservation styles. Individual reservations are
   made separately for each sender, whereas shared reservations allocate
   resources that can be used by all senders in an RTP session.  Unlike
   RSVP supports shared reservation (SE and WF styles) from the
   receiver's direction, YESSIR handles the shared reservation style
   from the sender's direction, thus new receivers can re-use the

Manner et al               Expires April 2003                  [Page 11]

Internet-Draft          Analysis of QoS Signaling           October 2002

   existing reservation of the previous sender.

3.2.  Processing Overhead

   In [PaSc00], it was proved that YESSIR one-pass reservation model has
   better performance and lower processing cost, comparing with a
   regular two-way signaling protocol.

3.3.  Bandwidth Consumption

   The bandwidth consumption of YESSIR is somewhat lower than that of,
   for example, RSVP, because it does not require additional IP and
   transport headers. Bandwidth consumption is limited to the extension
   header size.

3.4.  Mobility Support

   YESSIR does not have any particular support for mobility. The same
   issues that were identified with RSVP apply.

3.5.  Security

   The security of YESSIR relies on RTP/RTCP security measures.

3.6.  Deployment Issues

   YESSIR requires support in applications since it is an integral part
   of RTCP. Similarly, it requires network routers to inspect RTCP
   packets to identify reservation requests and refreshes. Routers
   unaware of YESSIR forward the RTCP packets transparently.

3.7.  Conclusions


4.  Boomerang

   Boomerang [FNM+99] is a light-weight resource reservation protocol
   for IP networks. The protocol has only one message type and a single
   signaling loop for reservation set-up and tear-down, has no
   requirements on the far end node, but, instead, concentrates the
   intelligence in the Initiating Node (IN).

   In addition, the Boomerang protocol allows for sender- or receiver-

Manner et al               Expires April 2003                  [Page 12]

Internet-Draft          Analysis of QoS Signaling           October 2002

   oriented reservations and resource query. Flows are identified with
   the common 5-tuple and the QoS can be specified with various means,
   eg. service class and bit rate. Boomerang messages are in the initial
   implementation transported in ICMP ECHO / REPLY messages.

4.1.  Reservation Functionality

   Boomerang can only be used for unicast sessions, no support for
   multicast exists. The requested QoS can be specified with various
   methods and both ends of a communication session can make a
   reservation for their transmitted flow.

4.2.  Processing Overhead

   The authors of Boomerang show in [FNS02] that the processing of the
   protocol is considerably lower than with the ISI RSVP daemon

4.3.  Bandwidth Consumption

   Boomerang messages are quite short and consume a relatively low
   amount of link bandwidth.


4.4.  Mobility Support

   The same issues that were identified with RSVP apply with Boomerang.

4.5.  Security

   No mechanisms for providing message integrity or user identification
   have been presented.

4.6.  Deployment Issues

   The Boomerang protocol has similar deployment issues as any host-
   network-host protocol. It requires an implementation at both
   communicating nodes and in routers. Boomerang-unaware routers should
   be able to forward Boomerang messages transparently.

Manner et al               Expires April 2003                  [Page 13]

Internet-Draft          Analysis of QoS Signaling           October 2002

4.7.  Conclusions

   Boomerang seems to be a very lightweight protocol and efficient in
   its own scenarios. Still, the apparent low processing overhead and
   bandwidth consumption results from the limited functionality. No
   support for multicast or any security features are present which
   allows for a different functionality than RSVP, which the authors
   like to compare Boomerang to.

5.  Other Protocols

   This section presents shortly other signalling protocols designed to
   carry resource information for flows.


   INSIGNIA [PaSc00] has been developed at the Columbia University and
   is proposed as a very simple signaling mechanism for supporting QoS
   in mobile ad-hoc networks. It avoids the need for separate signaling
   by carrying the signaling along with the data in IP packets using IP
   packet header options. This approach, known as "in-band signaling" is
   proposed as more suitable in the rapidly changing environment of
   mobile networks since the signalled QoS information is not tied to a
   particular path.  It also allows the flows to be rapidly established
   and, thus, is suitable for short lived and dynamic flows.

   INSIGNIA aims to minimize signaling by reducing the number of
   parameters that are provided to the network. It assumes that real-
   time flows may tolerate some loss, but are very delay sensitive so
   that the only QoS information needed is the required minimum and
   maximum bandwidth.

   The INSIGNIA protocol operates at the network layer and assumes that
   link status sensing and access schemes are provided by lower layer
   entities. The usefulness of the scheme depends upon the MAC layers
   but this is undefined so that INSIGNIA can run over any MAC layer.
   The protocol requires that each router maintains per-flow state.

   The INSIGNIA system implicitly supports mobility. A near-minimal
   amount of information is exchanged with the network. To achieve this,
   INSIGNIA makes many assumptions about the nature of traffic that a
   source will send. This may also simplify admission control and buffer
   allocation. The system basically assumes that "real-time" will be
   defined as a maximum delay and the user can simply request real-time
   service for a particular quantity of traffic.

   After handover, data that was transmitted to the old base station can
   be forwarded to the new base station so that no data loss should
   occur. However, there is no way to differentiate between re-routed
   and new traffic so priority cannot be given to handover traffic, for

Manner et al               Expires April 2003                  [Page 14]

Internet-Draft          Analysis of QoS Signaling           October 2002

5.2.  Mobile RSVP

   Mobile RSVP (MRSVP) [MRSVP] is an extension to standard RSVP. It is
   based on advance reservations, where neighboring access points keep
   resources reserved for mobile nodes moving to their coverage area.
   When a mobile node requests resources, the neighboring access points
   are checked too and a passive reservation is done around the mobile
   nodes current location.


5.3.  BGRP

   Border Gateway Reservation Protocol (BGRP) [BGRP] is a signaling
   protocol for interdomain aggregated resource reservation for unicast
   traffic. BGRP builds a sink tree for each of the stub domains.  Each
   sink tree aggregates bandwidth reservations from all data sources in
   the network. BGRP maintains these aggregated reservations using soft
   state and relies on Differentiated Services for data forwarding.

   BGRP scales in terms of message processing load, state storage and
   bandwidth.  Since backbone routers only maintain the sink tree
   information, the total number of reservations at each router scales
   linearly with the number of Internet domains.


5.4.  ST-II

   ST-II [RFC1819] is an experimental resource reservation protocol
   intended to provide end-to-end real-time guarantees over an internet.
   It allows applications to build multi-destination simplex data
   streams with a desired quality of service. ST-II consists of two
   protocols: ST for the data transport and SCMP, the Stream Control
   Message Protocol, for all control functions. ST is simple and
   contains only a single PDU format that is designed for fast and
   efficient data forwarding in order to achieve low communication
   delays. SCMP packets are transferred within ST packets.

   ST-II has no built-in soft states, thus requires that the network be
   responsible for correctness. It is sender-initiated, and the overhead
   for ST-II to handle group membership dynamics is higher than RSVP


Manner et al               Expires April 2003                  [Page 15]

Internet-Draft          Analysis of QoS Signaling           October 2002

5.5.  The ITSUMO Framework

   The ITSUMO Framework [CCM+00] is an example of an architecture with a
   hierarchy of bandwidth brokers.  The architecture is based on
   Differentiated Services: the traffic is aggregated and forwarded in
   backbone networks based on per-hop behaviors. In the architecture
   there is at least one global server and several local nodes in each
   Radio Access Network (RAN). The server is referred to as the QoS
   Global Server (QGS) and local nodes are referred to as QoS Local
   Nodes (QLN). The QLNs are ingress nodes of the DiffServ domain. They
   usually reside at the edge of a wired backbone network and a Layer 2
   Radio Access Network. The QGS retains the global information of the
   domain and informs QLNs what to do when traffic comes in.

   The mobile node communicates its QoS requirements directly to the QGS
   through the use of SIP messages, for example. Once the mobile node
   has had such a request accepted, it is guaranteed within the Service
   Level Agreement, that the node can move in the domain and receive the
   required QoS. The QGS server has a near-to-complete picture of the
   state of the network at any time. This is achieved by regular polling
   of all QLNs.  The QGS uses the received information to determine if a
   particular request can be supported. Once it has concluded that the
   request cab be fulfilled, it broadcasts the decision to all nodes
   likely to be affected by the mobile node. Mobility guarantees are
   made by notifying QLNs of mobile nodes likely to arrive into their

   The Service Level Specification (SLS) is usually agreed by both the
   user and the service provider when the user signs up a service
   subscription. To change the SLS in wired network, the mobile has to
   contact the service provider. Once the negotiation is done, the
   mobile can utilize the new SLS. Once the negotiation between the
   mobile and the QGS is done, the QGS multicasts the decision to all
   QLNs in the same administration domain. Therefore, the mobile node
   can utilize the new SLS anywhere within the same administrative
   domain. Thus, dynamic SLS for mobile environment is achieved with a
   single negotiation in one administration domain.

   The ITSUMO approach offers classes of services mainly based on the
   combination of two parameters: latency and loss. For each parameter
   possible values are high, moderate, and low for latency and high,
   moderate, low, and none for the packet loss. The combination of the
   two parameters forms a spectrum with 12 classes of services.

   Furthermore, the ITSUMO architecture includes a set of mobility
   protocols. The Dynamic Registration and Configuration Protocol (DRCP)
   is similar than the Dynamic Host Configuration Protocol (DHCP) and
   supports host configuration and registration. The Host Mobility and
   Management Protocol (HMMP) provides dynamic address binding and
   personal mobility.

Manner et al               Expires April 2003                  [Page 16]

Internet-Draft          Analysis of QoS Signaling           October 2002

6.  Summary

   - Gather the good ideas from the protocols as a basis for the future

   - Perhaps note that extensive features and simplicity do not go hand-
   in-hand:  "if you want features, be prepared to pay for the cost".

7.  Security Considerations

   There are no security issues in this document. Individual protocols
   include different levels of security issues and those are highlighted
   in the relevant sections.

8.  Contributors

   This document is part of the work done in the NSIS Working Group. The
   draft was initially written by Jukka Manner and Xiaoming Fu.

9.  Acknowledgement

   <TBD as needed>

10.  References

     [RFC1819] L. Delgrossi and L. Berger, Editors, Internet Stream
     Protocol Version 2 (ST2) Protocol Specification - Version ST2+,
     RFC 1819, August 1995.

     [MESZ94] D. Mitzel, D. Estrin, S. Shenker, and L. Zhang, An
     Architectural Comparison of ST-II and RSVP, INFOCOM'94.

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

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

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

     [RFC2207] L. Berger and T. O'Malley, RSVP Extensions for IPSEC Data
     Flows, RFC 2207, September 1997.

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

Manner et al               Expires April 2003                  [Page 17]

Internet-Draft          Analysis of QoS Signaling           October 2002

     [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
     Speer, M., Braden, R. and B. Davie, "Integrated Services Operation
     over Diffserv Networks", RFC 2998, November 2000.

     [RFC2749] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R.
     and A. Sastry, COPS usage for RSVP, RFC 2749, January 2000.

     [RFC2750] Herzog, S., RSVP Extensions for Policy Control, RFC
     2750, January 2000.

     [RFC2751] Herzog, S., Signaled Preemption Priority Policy Element,
     RFC 2751, January 2000.

     [RFC2752] Yadav, S., et al., "Identity Representation for RSVP",
     RFC 2752, January 2000.

     [RFC2747] Baker, F., Lindell, B. and M. Talwar, RSVP Cryptographic
     Authentication, RFC 2747, January 2000.

     [RFC2380] Berger, L., RSVP over ATM Implementation Requirements,
     RFC 2380, August 1998.

     [RFC2814] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and M.
     Speer, SBM (Subnet Bandwidth Manager): A Protocol for Admission
     Control over IEEE 802-style Networks, RFC 2814, May 2000.

     [RFC2745] Terzis, A., Braden B., S. Vincent, and L. Zhang, RSVP
     Diagnostic Messages, RFC 2745, January 2000.

     [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang,
     RSVP Operation Over IP Tunnels, RFC 2746, January 2000.

     [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P. and F. Tommasi,
     RSVP Refresh Reduction Extensions, RFC 2961, April 2001.

     [RFC2996] Bernet, Y., Format of the RSVP DCLASS Object, RFC 2996,
     November 2000.

     [RFC2997] Bernet, Y., Smiht, A. and B. Davie, Specification of the
     Null Service Type, RFC 2997, November 2000.

     [RFC3175] F. Baker, C. Iturralde, F. Le Faucheur, B. Davie,
     Aggregation of RSVP for IPv4 and IPv6 Reservations, RFC 3175,
     September 2001

     [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
     and G. Swallow, Extensions to RSVP for LSP Tunnels, RFC 3209,
     December 2001.

     [RFC3270] F. Le Faucheur (ed), L. Wu, and et al, Multi-Protocol
     Label Switching (MPLS) Support of Differentiated Services, RFC
     3270, May 2002.

     [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D.,

Manner et al               Expires April 2003                  [Page 18]

Internet-Draft          Analysis of QoS Signaling           October 2002

     Deering, S., Handley, M. and V. Jacobson, "Protocol Independent
     Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362,
     June, 1998.

     [Hame02] L-N. Hamer, et al, Session Authorization Policy Element,
     Internet Draft, October 2002.

     [BEGD02] Bernet, Y., Elfassy, N., Gai, S. and D. Dutt, "RSVP
     Proxy", draft-ietf-rsvp-proxy-03 (work in progress), Mar 2002.

     [Meer02] H. de Meer, et al. "Analysis of Existing QoS Solutions".
     Internet Draft. (draft-demeer-nsis-analysis-02.txt)

     [Tsch02] Hannes Tschofenig, "RSVP Security Properties". Internet
     Draft, June 2002. (draft-tschofenig-rsvp-sec-properties-00.txt)

     [Fu02] Xiaoming Fu, et al, "Analysis on RSVP Regarding Multicast".
     Internet Draft, October 2002.

     [Thom01] Michael Thomas, "Analysis of Mobile IP and RSVP
     Interactions".  draft-thomas-seamoby-rsvp-analysis-00.txt
     (expired). Available from eg.

     [RaNa98] B. Rajagopalan and R. Nair. "Multicast Routing with
     Resource Reservation". Journal of High Speed Networks, 7(2), pp.
     113-139, July 1998.

     [FrJo02] Pierre Fransson and Andreas Jonsson, "The need for an
     alternative to IPv4-options", in RVK (RadioVetenskap och
     Stockholm, Sweden, pp. 162-166, June 200.

     [MHS02] Yu-Ben Miao, Wen-Shyang Hwang, Ce-Kuen Shieh, "A
     transparent deployment method of RSVP-aware applications on UNIX".
     Computer Networks, 40 (2002), pp.  45-56.

     [FNS02] Gabor Feher, Krisztian Nemeth, Istvan Cselenyi,
     "Performance evaluation framework for IP resource reservation
     signalling". Performance Evaluation 48 (2002), pp. 131-156.

     [PaSc98] Ping Pan, Henning Schulzrinne, "YESSIR: A Simple
     Reservation Mechanism for the Internet". In the Proceedings of
     NOSSDAV, Cambridge, UK, July 1998.

     [PaSc00] P. Pan, and H. Schulzrinne, "Lightweight Resource
     Reservation Signaling: Design, Performance and Implementation",
     Bell Labs Technical Memorandum  10009669-03, July 2000.

     [KaSh01] Martin Karsten, Jens Schmitt, Ralf Steinmetz,
     "Implementation and Evaluation of the KOM RSVP Engine". IEEE
     Infocom 2001.

Manner et al               Expires April 2003                  [Page 19]

Internet-Draft          Analysis of QoS Signaling           October 2002

     [Kars01] Martin Karsten, "Experimental Extensions to RSVP -- Remote
     Client and One-Pass Signalling". IWQoS 2001, Karlsruhe, Germany,
     June 2001.

     [LGZC00] S. Lee, A. Gahng-Seop, X. Zhang, A. Campbell,"INSIGNIA: An
     IP-Based Quality of Service Framework for Mobile Ad Hoc
     Networks". Journal of Parallel and Distributed Computing (Academic
     Press), Special issue on Wireless and Mobile Computing and
     Communications}, Vol. 60, Number 4, April, 2000, pp. 374-406.

     [CCM+00] Jyh-Cheng Chen, Armando Caro, Anthony McAuley, Shinichi
     Baba, Yoshihiro Ohba, Parameswaran Ramanathan,"A QoS Architecture
     for Future Wireless IP Networks". Proceedings of the Twelfth IASTED
     International Conference on Parallel and Distributed Computing and
     Systems (PDCS 2000), Las Vegas, NV, November, 2000.

     [FNM+99] G. Feher, K. Nemeth, M. Maliosz, I. Cselenyi, J.
     Bergkvist, D. Ahlard, T. Engborg, "Boomerang A Simple Protocol for
     Resource Reservation in IP Networks", IEEE RTAS, 1999.

     [MSK+02] J. Manner, T. Suihko, M. Kojo, M. Liljeberg, K.
     Raatikainen, "Localized RSVP". Internet Draft, May 2002.

     [BGRP] P. Pan, E, Hahne, and H. Schulzrinne, "BGRP: A Tree-Based
     Aggregation Protocol for Inter-domain Reservations", Journal of
     Communications and Networks, Vol. 2, No. 2, June 2000, pp. 157-167.

     [MRSVP] A. Talukdar, B. Badrinath, and A. Acharya, MRSVP: A
     Resource Reservation Protocol for an Integrated Services Network
     with Mobile Hosts, Wireless Networks,    vol. 7, no. 1,
     pp. 5-19. 2001.

11.  Author's Addresses

      Questions about this document may be directed to:

      Jukka Manner
      Department of Computer Science
      University of Helsinki
      P.O. Box 26 (Teollisuuskatu 23)
      FIN-00014 HELSINKI

      Voice:  +358-9-191-44210
      Fax:    +358-9-191-44441
      E-Mail: jmanner@cs.helsinki.fi

      Xiaoming Fu
      Institute of Informatics
      Georg-August-University of Goettingen
      Lotzestrasse 16-18

Manner et al               Expires April 2003                  [Page 20]

Internet-Draft          Analysis of QoS Signaling           October 2002

      37083 Goettingen

      Voice:  +49-551-39-14411
      Fax:    +49-551-39-14403
      E-Mail: fu@cs.uni-goettingen.de

Manner et al               Expires April 2003                  [Page 21]

Internet-Draft          Analysis of QoS Signaling           October 2002

   Full Copyright Statement

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

   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

Manner et al               Expires April 2003                  [Page 22]

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