Internet Engineering Task Force                         J. Manner (ed.)
Internet-Draft                                              X. Fu (ed.)
Expires: December, 2003                                  Ping Pan (ed.)
                                                             June, 2003

        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 December, 2003.

   Copyright Notice

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

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


   This document reviews some of the existing QoS signaling protocols
   for an IP network. The goal here is to learn from them and to avoid
   common misconceptions. Further, we need to avoid the mistakes during
   the design and the implementation of any new protocol in this area.

Manner et al             Expires December, 2003                 [Page 1]

Internet-Draft          Analysis of QoS Signaling              June 2003

Changes since -01
   - Merged with [RSVP-TRANS],
   - Added a very preliminary Appendix that compares RSVP to the NSIS
   - Restructured the document for easier reading, and
   - Minor reference updates.

Changes since -00
   - More text on RFC2207, 2961, 3175, 3209,
   - Added [Berg02], [KoRe02], [LiPe02], RFC2379, 2380 and extensions
     proposed by ITU-T, OIF, 3GPP,
   - Re-wrote text on RSVP processing overhead,
   - Updated text on RSVP security,
   - Removed section on ITSUMO as it was mostly an architectural
     discussion, rather than a protocol review,
   - Updates various other parts of the document based on feedback,
   - Re-structured the document.

Table of Contents

   1 Background ...................................................    3
   2 RSVP and RSVP Extensions .....................................    4
   2.1 Basic Design ...............................................    4
   2.2 RSVP Extensions ............................................    6
   2.2.1 Simple Tunneling .........................................    6
   2.2.2 IPSEC Interface ..........................................    6
   2.2.3 Policy Interface .........................................    6
   2.2.4 Refresh Reduction ........................................    7
   2.2.5 RSVP over RSVP ...........................................    7
   2.2.6 IEEE 802-style LAN Interface .............................    8
   2.2.7 ATM Interface ............................................    8
   2.2.8 DiffServ Interface .......................................    8
   2.2.9 Null Service Type ........................................    9
   2.2.10 MPLS Traffic Engineering ................................    9
   2.2.11 GMPLS RSVP: Provision Optical Networks ..................   10
   2.2.12 GMPLS Interworking with ITU and OIF .....................   11
   2.2.13 ITU-T H.323 Interface ...................................   11
   2.2.14 3GPP Interface ..........................................   12
   2.3 Extensions For New Deployment Scenarios ....................   12
   2.4 Conclusion .................................................   13
   3 RSVP Transport Mechanism Issues ..............................   14
   3.1 Messaging Reliability ......................................   14
   3.2 Message Packing ............................................   15
   3.3 MTU Problem ................................................   15
   3.4 RSVP-TE vs. Signaling Protocol for RT Applications .........   16
   3.5 What will be a better alternative?  ........................   16
   4 RSVP Protocol Performance Issues .............................   17
   4.1 Processing Overhead ........................................   17
   4.2 Bandwidth Consumption ......................................   18
   5 RSVP Security and Mobility ...................................   19
   5.1 Security ...................................................   19
   5.2 Mobility Support ...........................................   19

Manner et al             Expires December, 2003                 [Page 2]

Internet-Draft          Analysis of QoS Signaling              June 2003

   6 Other QoS Signaling Proposals ................................   20
   6.1 Tenet and ST-II ............................................   20
   6.2 YESSIR .....................................................   21
   6.2.1 Reservation Functionality ................................   21
   6.2.2 Conclusion ...............................................   22
   6.3 Boomerang ..................................................   22
   6.3.1 Reservation Functionality ................................   22
   6.3.2 Conclusions ..............................................   23
   6.4 INSIGNIA ...................................................   23
   6.5 BGRP .......................................................   24
   7 Summary ......................................................   24
   8 Security Considerations ......................................   25
   9 Contributors .................................................   25
   10 Acknowledgment ..............................................   25
   11 References ..................................................   25
   12 Authors' Information ........................................   29
   13 Appendix A - Comparison of RSVP to the  NSIS  Requirements

1.  Background

   This document reviews some of the existing QoS signaling protocols
   for an IP network. The goal here is to learn from them and to avoid
   common misconceptions. Further, we need to avoid the mistakes during
   the design and the implementation of any new protocol in this area.

   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 for the majority of
   communications, hence, both 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. Its
   processing is fairly complex. Since every sender needs to set up its
   own reservation, the total amount of reservation states 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
   signaling protocol for resource control.  Istvan Cselenyi suggested
   to request for QoSSIG BOF in IETF#47 (
   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

Manner et al             Expires December, 2003                 [Page 3]

Internet-Draft          Analysis of QoS Signaling              June 2003

   knowledge and requirements" that made RSVP insufficient (http://www-, 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 ( has been involved in the
   Internet signaling for years. Ping Pan initiated a SIGLITE
   ( 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 signaling protocols are presented in later

2.  RSVP and RSVP Extensions

   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.

   By original design, RSVP fits well into the framework of the
   Integrated Services (IntServ) [RFC2210] [BEBH96] with certain
   modularity and scalability.

   RSVP carries QoS signaling messages 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 provides authorization for the QoS
   request. 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
   classifier and packet scheduler to obtain the desired QoS.

2.1.  Basic Design

   The design of RSVP 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.

Manner et al             Expires December, 2003                 [Page 4]

Internet-Draft          Analysis of QoS Signaling              June 2003

   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 (Path and Resv
   states)  in routers and hosts incrementally over time. RSVP sends
   periodic refresh messages (Path and Resv) to maintain its states and
   to recover from occasional lost messages. In the absence of refresh
   messages, the RSVP states automatically time out and are deleted.
   States may also be deleted explicitly by PathTear, PathErr with
   Path_State_Removed flag, or ResvTear Message.

   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
   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 toward 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 signaling 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.

   A number of messages and objects have been defined for the protocol.
   A detailed description is given in [RFC2205].

Manner et al             Expires December, 2003                 [Page 5]

Internet-Draft          Analysis of QoS Signaling              June 2003

2.2.  RSVP Extensions

   RSVP [RFC2205] was originally designed to support real-time
   applications over the Internet. Over the past several years, the
   demand for multicast-capable real-time teleconferencing, which many
   people had envisioned to be one of the key Internet applications that
   could benefit from network-wide deployment of RSVP, has never
   materialized.  Instead, RSVP-TE [RFC3209], a RSVP extension for
   traffic engineering, has been widely deployed by a large number of
   network providers to support MPLS applications.

   There are a large number of protocol extensions based on RSVP. Some
   provide additional features, such as security and scalability, to the
   original protocol. Some introduce additional interfaces to other
   services, such as DiffServ. And some simply define new applications,
   such as MPLS and GMPLS, that are completely irrelevant from
   protocol's original intent.

   In this section, we list only IETF-based RFCs and a limited set of
   other organizations' specifications. Informational RFCs (e.g.,
   RFC2998) and work-in-progress I-Ds (e.g., proxy) are not covered

2.2.1.  Simple Tunneling

   [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.

2.2.2.  IPSEC Interface

   RSVP can support IPsec on a per address, per protocol basis instead
   of on a per flow basis. [RFC2207] extends RSVP by using the IPSEC
   Security Parameter Index (SPI) in place of the UDP/TCP-like ports.
   This introduces a new FILTER_SPEC object, which contains the IPSEC
   SPI, and a new SESSION object.

2.2.3.  Policy Interface

   [RFC2750] specifies the format of POLICY_DATA objects and RSVP
   handling of policy events. It introduces objects which are
   interpreted only by policy aware nodes (PEPs) which interact with
   policy decision points (PDPs). Nodes which are unable to interpret
   the POLICY_DATA objects are called policy ignorant nodes (PINs). The
   content of the POLICY_DATA object itself is protected only between
   PEPs and therefore provides end-to-middle or middle-to-middle

   [RFC2749] specifies the usage of COPS policy services in RSVP
   environments. [RFC2751] specifies a preemption priority policy
   element (PREEMPTION_PRI) for use by RSVP POLICY_DATA Object. [Hame02]

Manner et al             Expires December, 2003                 [Page 6]

Internet-Draft          Analysis of QoS Signaling              June 2003

   describes how authorization provided by a separate protocol (such as
   SIP) can be reused with the help of an authorization token within
   RSVP. The token might therefore contain either the authorized
   information itself (e.g. QoS parameters) or a reference to those
   values. The token might be unprotected (which is strongly
   discouraged) or protected based on symmetric or asymmetric
   cryptography. Moreover, the document describes how to provide the
   host with encoded session authorization information as a POLICY_DATA

2.2.4.  Refresh Reduction

   [RFC2961] describes mechanisms to reduce processing overhead
   requirements of refresh messages, eliminate the state synchronization
   latency incurred when an RSVP message is lost and, refreshing state
   without the transmission of whole refresh messages. It defines the
   objects. Three new RSVP message types are defined:

   1) Bundle message, which consists of a bundle header followed by a
   body consisting one or more standard RSVP messages. Bundle messages
   help in scaling RSVP in reducing processing overhead and bandwidth

   2) ACK message, which carries one or more MESSAGE_ID_ACK or
   MESSAGE_ID_NACK objects. ACK messages are sent between neighboring
   RSVP nodes to detect message loss and support reliable RSVP message
   delivery on a per hop basis.

   3) Srefresh message, which carries one or more MESSAGE_ID LIST,
   MESSAGE_ID SRC_LIST and MESSAGE_ID MCAST_LIST objects. correspondent
   to Path and Resv messages that establish the states. Srefresh
   messages are used to refresh RSVP states without transmitting
   standard Path or Resv messages.

2.2.5.  RSVP over RSVP

   [RFC3175] allows to install one or more aggregated reservations in an
   aggregation region, thus the number of individual RSVP sessions can
   be reduced. The protocol type is swapped from RSVP to RSVP-E2E-IGNORE
   in E2E (standard) Path, PathTear and ResvConf messages when they
   enter the aggregation region, and swapped back when they leave. In
   addition to a new PathErr code (NEW_AGGREGATE_NEEDED), three new
   objects are introduced:

   1) SESSION object, which contains two values: the IP Address of the
   aggregate session destination, and the DSCP that it will use on the
   E2E data the reservation contains.

   2) SENDER_TEMPLATE object, which identifies the aggregating router
   for the aggregate reservation.

Manner et al             Expires December, 2003                 [Page 7]

Internet-Draft          Analysis of QoS Signaling              June 2003

   3) FILTER_SPEC object, which identifies the aggregating router for
   the aggregate reservation, and is syntactically identical to the

   From the perspective of RSVP signaling and the handling of data
   packets in the aggregation region, these cases are equivalent to the
   case of aggregating E2E RSVP reservations.  The only difference is
   that E2E RSVP signaling does not take place and cannot therefore be
   used as a trigger, so some additional knowledge is required in
   setting up the aggregate reservation.

2.2.6.  IEEE 802-style LAN Interface

   [RFC2814] introduces an RSVP LAN_NHOP address object that keeps track
   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.

2.2.7.  ATM Interface

   [RFC2379] and [RFC2380] define RSVP over ATM implementation
   guidelines and requirements to interwork with the ATM (Forum) UNI
   3.x/4.0.  [RFC2380] states that the RSVP (control) messages and RSVP
   associated data packets must not be sent on the same VCs, and an
   explicit release of RSVP associated QoS VCs must be performed once
   the VC for forwarding RSVP control messages terminated. While a
   separate control VC is also possible for forwarding RSVP control
   messages, [RFC2379] recommends to create a best-effort short-cut (a
   short-cut is a point-to-point VC where the two end-points locate in
   different IP subnets) first (if not exist), which can allow setting
   up RSVP triggered VCs to use the best-effort end-point. For data
   flows, the subnet senders must establish all QoS VCs and the RSVP
   enabled subnet receiver must be able to accept incoming QoS VCs. RSVP
   must request the configurable inactivity timers of VCs be set to
   "infinite", and if it is too complex to do this at the VC receiver,
   RSVP over ATM implementations are required not to use an inactivity
   timer to clear any received connections. In case of dynamic QoS, the
   replacement of VC should be done gracefully.

2.2.8.  DiffServ Interface

   RFC2996 [RFC2996] introduces a DCLASS Object to carry Differentiated
   Services Code Points (DSCPs) in RSVP message objects. If the network

Manner et al             Expires December, 2003                 [Page 8]

Internet-Draft          Analysis of QoS Signaling              June 2003

   element determines that the RSVP request is admissible to the
   DiffServ 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 toward the RSVP sender.

2.2.9.  Null Service Type

   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.2.10.  MPLS Traffic Engineering

   RSVP-TE [RFC3209] specifies the extension to RSVP for establishing
   explicitly routed LSPs in MPLS networks using RSVP as a signaling
   protocol. RSVP-TE is intended for use by label switching routers (as
   well as hosts) to establish and maintain LSP-tunnels and to reserve
   network resources for such LSP-tunnels.  RFC3209 defines a new Hello
   message (for rapid node failure detection), new C-Types
   (LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6) for the SESSION (here a session
   is implicitly defined as the set of packets that are assigned the
   same MPLS label value at the originating node of an LSP-tunnel),
   SENDER_TEMPLATE, and FILTER_SPEC objects, and the following 5 new

   1) EXPLICIT_ROUTE object (ERO), which 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.

   2) LABEL_REQUEST object. To establish an LSP tunnel, the sender can
      create a Path message with a LABEL_REQUEST object. A node that
      sends a LABEL_REQUEST object MUST be ready to accept and correctly
      process a LABEL object in the corresponding Resv messages.

   3) LABEL object.  Each node that receives a Resv message containing a
      LABEL object uses that label for outgoing traffic associated with
      this LSP tunnel.

   4) SESSION_ATTRIBUTE object, which can be added to Path messages to
      aid in session identification and diagnostics.  Additional control

Manner et al             Expires December, 2003                 [Page 9]

Internet-Draft          Analysis of QoS Signaling              June 2003

      information, such as setup and hold priorities, resource
      affinities and local-protection, are also included in this object.

   5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object may appear in
      both Path and Resv messages. It is used to collect detailed path
      information and is useful for loop detection and for diagnostics.

   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.11.  GMPLS RSVP: Provision Optical Networks

   [RFC3473] is developed on top of RSVP-TE. It enables network
   operations to provision data-path within optical networks.  It
   defines a Notify message (for general event notification), which may
   contain notifications being sent, with respect to each listed
   session, both upstream and downstream. Notify messages can be used
   together with Notify Request object for expedited notification of
   failures and other events to nodes responsible for restoring failed
   LSPs. A Notify message is sent without the router alert option.
   Besides, a number of new RSVP-TE (sub)objects are defined in GMPLS
   RSVP-TE for general uses of MPLS: (for label management:)

   - a Generalized Label Request Object;
   - Bandwidth Encoding carried in SENDER_TSPEC and FLOWSPEC objects,
     Generalized Label Object;
   - a Waveband Switching Object;
   - a Suggested Label Object;
   - a Label Set Object; (to support bidirectional LSP setup:)
   - an Upstream_Label object; (to support uni- and bi-directional
     Explicit Label Control:)
   - a Label ERO subobject;
   - a Label RRO subobject, which is included in RROs as described in
     [RFC3209]; (To Control Channel Separation:)
   - IF_ID RSVP_HOP objects (IPv4 & v6);
   - IF_ID ERROR_SPEC objects (IPv4 & v6); (to support rapid failure
   - a Acceptable Label Set object to support Notification on Label
   - a Notify Request object, which may be inserted in Path or Resv
     messages to indicate where a notification of LSP failure is to be
     sent; (for fault handling:)
   - a Restart_Cap Object; (for administrative purposes:)
   - an Admin Status Object, which is used to notify each node along the
     path of the status of the LSP.

   Since RSVP-TE does not provide a way to indicate an unnumbered link
   in its Explicit Route and Record Route Objects, [KoRe03] specifies
   extensions to RSVP-TE to support (point-to-point) unnumbered links,

Manner et al             Expires December, 2003                [Page 10]

Internet-Draft          Analysis of QoS Signaling              June 2003

   - an Unnumbered Interface ID Subobject, which is a new subobject of
     the Explicit Route Object (ERO) used to specify unnumbered links;
   - an LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to
     form or use an identifier for the Forwarding Adjacency;
   - a new subobject of the Record Route Object, used to record that the
     LSP path traversed an unnumbered link.

2.2.12.  GMPLS Interworking with ITU and OIF

   [LiPe02] proposes additional extensions to GMPLS RSVP-TE to support
   the capabilities of an Automatically Switched Optical Network (ASON,
   an architecture developed by ITU-T SG15).  To support Soft Permanent
   Connection (SPC), it uses GENERALIZED_UNI object defined by [OIF-
   UNI-1.0] but introduces a new subtype: SPC_LABEL. In addition, a Call
   identifier (CALL_ID) object is used in logical call/connection
   separation, which are used together with a new Call capability
   (CALL_OPS) object for complete call/connection separation. Besides
   new error codes, 3 new C-types are defined for the SESSION object:

   Optical Internetworking Forum (OIF) UNI 1.0 signaling ([OIF-UNI-1.0])
   supports [RFC2205, RFC2961, RFC3209, Berg03] in a limited way. 10
   types of RSVP(-TE) messages are supported, but used in a slightly
   different way.  For example, only FF style is supported; States are
   always deleted explicitly; a state timer expiration will not deleted
   the state, rather triggers a tear down message; any RSVP message must
   be dropped silently when fails security validation.  Besides new
   error codes, a few new (sub)objects are introduced, including

   - a new C-type for ACCEPTABLE_LABEL_SET;
   - a new C-type for ADMIN_STATUS;
   - a new C-type for LABEL_SET;
   - a new C-type for RECOVER_LABEL;
   - a new C-type for RESTART_CAP;
   - a new C-type for UPSTEAM_LABEL;
   - a UNI_IPv4_SESSION object, combined with
     LSP_TUNNEL_IPv4_SENDER_TEMPLATE object to uniquely identify a
     connection at a local UNI;
   - a GENERALIZED_UNI_ATTRIBUTES object, which contains one or more new
     subobjects. EGRESS_LABEL can be used to specify either uni- or
     bi-directional connections;

2.2.13.  ITU-T H.323 Interface

   ITU-T H.323 ([H.323]) recommends the IntServ resource reservation
   procedure using RSVP. The information whether an endpoint supports
   RSVP should be conveyed during the H.245 capability exchange phase,
   by setting appropriate qOSMode fields. If both endpoints are RSVP-

Manner et al             Expires December, 2003                [Page 11]

Internet-Draft          Analysis of QoS Signaling              June 2003

   capable, when opening an H.245 logical channel, a receiver port ID
   should be conveyed to the sender by the openLogicalChannelAck
   message. Only after that, can a "Path - Resv - ResvConf" process take
   place. The timer of waiting for ResvConf message will be set by the
   endpoint. The action in case of this timer expires, as well as RSVP
   reservation fails in any point during an H.323 call, is up to the
   vendor to take. Once a ResvConf message is sent or received, the
   endpoints should stop reservation timers and resume with the H.323
   call procedures. Only explicit release of reservations are supported
   in [H.323]: before sending a closeLogicalChannel message for a
   stream, a sender should send a PathTear message if an RSVP session
   has been previous created for that stream; after receiving a
   closeLogicalChannel, a receiver should send a ResvTear similarly.
   Only the FF style is supported, even for point-to-multipoint calls.

2.2.14.  3GPP Interface

   3GPP TS 23.207 ([3GPP-TS23207]) specifies the QoS signaling procedure
   with policy control within the UMTS end-to-end QoS architecture. When
   using RSVP, the signaling source and/or destination are the User
   Equipments (UEs, devices that allow users access to network services)
   that locate in the Mobile Originating (MO) side and the Mobile
   Terminating (MT) side, and an RSVP signaling process can either
   trigger or be triggered by the (COPS) PDP Context
   establishment/modification process. The operation of refreshing
   states is not specified in [3GPP-TS23207]. If bidirectional
   reservation is needed, the RSVP signaling should be proceeded twice
   between the signaling source and the destination. The authorization
   token and flow identifier(s) in a policy data object should be
   included in the RSVP messages sent by the UE, if the token is
   available in the UE. When both RSVP and Service-based Local Policy
   are used, the Gateway GPRS Support Node (GGSN, the access point of
   the network) should use the policy information to decide whether to
   accept and forward Path/Resv messages.

2.3.  Extensions For New Deployment Scenarios

   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

Manner et al             Expires December, 2003                [Page 12]

Internet-Draft          Analysis of QoS Signaling              June 2003

   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
   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 themselves 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+03]. 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 - this would be
   especially helpful when the correspondent node is unaware of RSVP. 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 assist in 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
   signaling 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]
   can aggregate multiple RSVP messages within a single PDU, but still
   only occupy one IP datagram (i.e., approximately 64K); if it exceeds
   the MTU, the datagram is fragmented by IP and reassembled at the
   recipient node.

2.4.  Conclusion

   A good signaling protocol should be transparent or oblivious to the
   applications. RSVP has proven to be a very well designed protocol.
   However, it has a number of fundamental protocol design issues that
   requires more careful re-evaluation.

   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
   should not appear in the specification as they are QoS-specific.

Manner et al             Expires December, 2003                [Page 13]

Internet-Draft          Analysis of QoS Signaling              June 2003

   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
   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 basic building
   blocks for deploying the protocol in various environments to protect
   its messages from forgery and modification. Hop-by-hop protection is
   provided. However, current RSVP security mechanism does not provide
   non-repudiation and protection against message deletion; the two-way
   peer authentication and key management procedures are still missing.

   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 message is limited.

   The transport mechanisms, performance, security and mobility issues
   are detailed in the following sections.

3.  RSVP Transport Mechanism Issues

3.1.  Messaging Reliability

   RSVP messages are defined as a new IP protocol (that is, a new ptype
   in the IP header). RSVP Path messages must be delivered end-to-end.
   In order for the transit routers to intercept the Path messages, a
   new IP Router Alert option [RFC2113] was introduced. This design is
   simple to implement and efficient to run. As shown from the
   experiments in [IP-OPT], IP option processing introduces very little
   overhead on a FreeBSD box with minor kernel changes.

   However, RSVP does not have a good message delivery mechanism.  If a
   message is lost on the wire, the next re-transmit cycle by the

Manner et al             Expires December, 2003                [Page 14]

Internet-Draft          Analysis of QoS Signaling              June 2003

   network would be one soft-state refresh interval later.  By default,
   a soft-state refresh interval is 30 seconds.

   To overcome this problem, [STAGED] introduced a staged refresh timer
   mechanism, which has been defined as a RSVP extension in [RFC2961].
   The staged refresh timer mechanism retransmits RSVP messages until
   the receiving node acknowledges. It can address the reliability
   problem in RSVP.

   However, during its implementation, a lot of effort had to be spent
   on per-session timer maintenance, message retransmission (e.g., avoid
   message bursts) and message sequencing. In addition, we have to make
   an effort to try to separate the transport functions from protocol
   processing. For example, if a protocol extension requires a natural
   RSVP session time-out (such as RSVP-TE one-to-one fast-reroute [FAST-
   REROUTE]), we have to turn off the staged refresh timers.

   In summary, in trying to introduce reliability in RSVP, we are
   getting closer to reinvent TCP. Furthermore, if head of line blocking
   is likely to occur, SCTP can be used. Certainly, if TCP, SCTP or
   similar protocols is the transport protocol for RSVP, the message
   reliability would not have been an issue.

3.2.  Message Packing

   According to RSVP [RFC2205], each RSVP message can only contain
   information for one session. In a network that has a reasonably large
   number of RSVP sessions, this constraint imposes a heavy processing
   burden on the routers. Many router OS is based on UNIX. [IP-OPT]
   showed that the UNIX socket I/O processing is not very sensitive to
   packet size. In fact, processing small packets takes almost as much
   CPU overhead as processing large ones. However, processing too many
   individual messages can easily cause congestion at socket I/O

   To overcome this problem, RFC2961 introduced the message bundling
   mechanism.  The bundling mechanism packs multiple RSVP messages
   between two adjacent nodes into a single packet. In one deployed
   router platform, the bundling mechanism has improved the number of
   RSVP sessions that a router can handle from 2,000 to over 7,000.

3.3.  MTU Problem

   RSVP does not support message fragmentation and reassembly at
   protocol level.  If the size of a RSVP message is larger than the
   link MTU, the message will be fragmented. And the routers simply
   cannot detect and process RSVP message fragments.

   There is no solution for the MTU problem. Fortunately, at places
   where RSVP-TE has been used, either the amount of per-session RSVP
   data is never too large, or the link MTU is adjustable - PPP and
   Frame Relay can always increase or decrease the MTU sizes. For

Manner et al             Expires December, 2003                [Page 15]

Internet-Draft          Analysis of QoS Signaling              June 2003

   example, on some routers, a Frame Relay interface can support the
   link MTU size up to 9600 bytes.  Currently, the RSVP MTU problem is
   not a realistic concern in MPLS networks.

   However, when and if RSVP is used for end-user applications, where
   network security is an essential and critical concern, it is possible
   that the size of RSVP messages can be larger than the link MTU. It is
   important to notice that end-users are most likely to have to deal
   with a small 1500-byte Ethernet MTU.

   Once again, if RSVP is operated on top of TCP or similar protocols,
   there would be no MTU issue here.

3.4.  RSVP-TE vs. Signaling Protocol for RT Applications

   RSVP-TE works in an environment that is different from what the
   original RSVP has been designed for: in MPLS networks, the RSVP
   sessions that are used to support Label-Switched-Paths (LSP's) do not
   change frequently.

   In fact, the network operators typically set up the MPLS LSP's in
   such a way that they cannot switch too quickly. For example, the
   operators often regulate the CSPF (Constraint-based Shortest Path
   First, a routing algorithm operates from the network edge to compute
   the "most" optimal routes for the LSP's) computation interval to
   prevent or delay large volume of user traffic to shift from one
   session to the other during LSP path optimization. As a result, RSVP-
   TE does not have to handle a large amount of "triggered" (new or
   modified)  messages. Most of the messages are refresh messages, which
   can be handled by the mechanisms introduced in RFC2961. In
   particular, in the Summary Refresh extension [RFC2961], each RSVP
   refresh message can be represented as a 4-byte ID. The routers can
   simply exchange the ID's to refresh RSVP sessions. With the full
   implementation of RFC2961, MPLS routers do not have any RSVP scaling
   issue. On one deployed router platform, it can support over 50,000
   RSVP sessions in a stable backbone network.

   On the other hand, in many of the new applications where a signaling
   protocol is required, the user session duration can be relatively
   short.  The dynamics of adding/dropping user sessions could introduce
   a large number of "triggered" messages in the network. This can
   clearly introduce a substantial amount of processing overhead to the
   routers. This is one area where a new signaling protocol may be
   needed to reduce the processing complexity in the resource
   reservation process.

3.5.  What will be a better alternative?

   A good signaling protocol should be transparent or oblivious to the
   applications.  On the other hand, the design of a signaling protocol
   must take the intended and potential applications into consideration.

Manner et al             Expires December, 2003                [Page 16]

Internet-Draft          Analysis of QoS Signaling              June 2003

   With the addition of RFC2961, RSVP-TE is sufficient to support its
   intended application, MPLS, within the backbone. There is no
   significant transport-layer problem that needs to be solved.

   In the last several years, a number of new applications has been
   developed and they require the use of IP signaling. One example is
   midcom, which has been designed for firewall control. There are also
   some far-out applications such as depositing active network code on
   network devices.  It is likely that the next-generation signaling
   protocols will have to deal with the network security problems. The
   MTU problem prevents the re-use of the existing RSVP transport

   If a new transport protocol is needed, the protocol must be able to
   handle the following:
   - reliable messaging;

   - message packing;

   - the MTU problem;

   - small triggered message volume.

   TCP satisfies all the criteria.  TCP-based signaling/routing
   protocols have been deployed in the Internet for years. BGP [BGP] and
   LDP [RFC3036] establish peering relationship between network nodes
   over TCP sessions.  Various control information, such as routes and
   MPLS labels, can be exchanged between the nodes. It is quite possible
   that any given node may have many peers over a large number of TCP
   sessions. Peering and session management thus become an important
   implementation issue.  However, this can be handled with some proper
   software techniques.

4.  RSVP Protocol Performance Issues

4.1.  Processing Overhead

   By processing overhead we mean the amount of processing required to
   handle messages belonging to a reservation session. This is the
   processing required in addition to the processing needed for routing
   an (ordinary) IP packet. The processing overhead of RSVP originates
   from two major issues:

   1) Complexity of the protocol elements. First, RSVP itself is
     per-flow based, thus the number of states is proportional to RSVP
     session number. Path and Resv states have to be maintained in each
     RSVP router for each session (and Path state also record the
     reverse route for the correspondent Resv message). Second, being
     receiver-initiated, RSVP optimizes various merging operations for
     multicast reservations while the Resv message is processed. To
     handle multicast, other mechanisms like reservation styles, scope
     object, and blockade state, are also required to present in the
     basic protocol. This not only adds sources of failures and errors,

Manner et al             Expires December, 2003                [Page 17]

Internet-Draft          Analysis of QoS Signaling              June 2003

     but also complicates the state machine.  Third, the same RSVP
     signaling messages are not only used for maintaining the state, but
     also dealing with recovery of signaling message loss and discovery
     of route change.  Thus, although protocol elements that represent
     the actual data (e.g., QoS parameters) specification are separated
     from signaling elements, the processing overhead needed for all
     RSVP messages is not marginal.  Finally, the possible variations of
     the order and existence of objects increases the complexity of
     message parsing and internal message and state representation.

   2) Implementation-specific Overhead. There are two ways to send and
     receive RSVP messages, either as "raw" IP datagrams with protocol
     number 46, or as encapsulated UDP datagrams, the latter of which
     increase the efficiency of RSVP processing. Typical RSVP
     implementations are user-space daemons interacting with the
     kernel, hence state management, message sending and reception
     would affect the efficiency of the protocol processing.  For
     example, in the recent version of the implementation described in
     [Kars01], the relative execution costs for message
     sending/reception system calls "sendto", "select", "recvmsg" were
     14-16%, 6-7%, 9-10%, individually, of the total execution cost;
     [Kars01] also found that state (memory) management can use up to
     17-18% of the total execution cost, but it is possible to decrease
     that cost to 6-7%, if appropriate action is taken to replace the
     standard memory management with dedicated memory management for
     state information.  RSVP/routing, RSVP/policy control, and
     RSVP/traffic control interfaces can also pose different overhead
     dependent on implementation. For example, the RSVP/routing
     overhead has been measured to be approximately 11-12% of the total
     execution cost [Kars01].

4.2.  Bandwidth Consumption

   By bandwidth consumption we mean the amount of bandwidth used to
   during the lifetime of a session: set up a reservation session, keep
   the session alive, and finally close it.

   RSVP messages are sent either to trigger a new reservation or refresh
   an existing reservation. In standard RSVP, Path/Resv messages are
   used for triggering and refreshing/recovering reservations,
   identically, which results in an increased size of refresh messages.
   The hop-by-hop refreshment may reduce the bandwidth consumption for
   RSVP, but could result in more sources of error/failure events.
   [RFC2961] presents a way to bundle standard RSVP messages and reduces
   the refreshment redundancy by Srefresh message.

   Thus, the signaling for an RSVP session uses for a session lasting n

   F(n) = (bP + bR) + ((n/Ri) * (bP + bR)) + bPt ,where

   bP IP payload size of Path message
   bR IP payload size of Resv message

Manner et al             Expires December, 2003                [Page 18]

Internet-Draft          Analysis of QoS Signaling              June 2003

   bPt IP payload size of Path Tear message
   Ri refresh interval

   For example, for a simple Controlled Load reservation without
   security and identification requirements the bandwidth consumption
   would be (bP is 172 bytes, bR is 92, and bPt is 44 bytes and Ri is 30

   F(n): (172 + 92) + (n/30) * (172 + 92)) + 44 =  308 + (264n/30) bytes

5.  RSVP Security and Mobility

5.1.  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
   Object. However, to provide iron-clad security protection
   cryptographic authentication combined with authorization has to be
   provided. Such a functionality is typically offered by authentication
   and key exchange protocols. Solely including a user identifier is

   To provide hop-by-hop integrity and authentication of RSVP messages,
   RSVP message may contain an INTEGRITY object ([RFC2747]) using a
   keyed message digest. Since intermediate routers need to modify and
   process the content of the signaling message a hop-by-hop security
   architecture based on a chain-of-trust is used. However, with the
   different usage of RSVP as described throughout this document and
   with new requirements a re-evaluation of the original assumptions
   might be necessary.

   RFC2747 provides protection against forgery and message modification.
   However this does not provide non-repudiation and protect against
   message deletion. In current RSVP security scheme, the two-way peer
   authentication and key management procedures are still missing.

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

5.2.  Mobility Support

   Two issues raise concern when RSVP is used by a mobile node (MN): the
   flow 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
   ineffective, until a refresh with a new set of filters is

Manner et al             Expires December, 2003                [Page 19]

Internet-Draft          Analysis of QoS Signaling              June 2003


   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
   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.

   There have been several designs for extensions to RSVP to allow for
   more seamless mobility. One solution is presented in [MSK+03], which
   discusses in one section the coupling of RSVP and the mobility
   management mechanisms and proposes small extensions to RSVP to better
   handle the handover event, among other things. The extension allows
   the mobile host to request a Path for the downstream reservation when
   a handover has happened.

   Another example is Mobile RSVP (MRSVP) [MRSVP], which 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.

   The problem with the various 'advance reservation' schemes is that
   they require topological information of the access network and
   usually advance knowledge of the handover event. Furthermore, the way
   the resource reserved in advance are used in the neighboring service
   areas is an open issue. A good overview of these different schemes
   can be found in [MA01].

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

6.  Other QoS Signaling Proposals

6.1.  Tenet and ST-II

   Tenet and ST-II are two original QoS signaling protocols for the

   In the original Tenet architecture [], the receiver sends a

Manner et al             Expires December, 2003                [Page 20]

Internet-Draft          Analysis of QoS Signaling              June 2003

   reservation request toward the source.  Each network node along the
   way makes the reservation. Upon arriving at the source, the source
   sends another Relax message back toward to the receiver, and has the
   option to modify the previous reservation at each node.

   ST-II [RFC1819] basically works as the following: a sender originates
   a Connect message to a set of receivers. Each intermediate node
   determines the next hop subnets, and makes reservations on the links
   going to these next hops.  Upon receiving a Connect indication, a
   receiver must send back either an Accept or a Refuse message to the
   sender.  In the case of an Accept, the receiver may further reduce
   the resource request by updating the returned flow specifications.

   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
   [MESZ94].  ST-II does not provide security but RFC 1819 describes
   some objects related to charging.

6.2.  YESSIR

   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, where, for certain types of applications, the
   reservation requests can be passed to the next hop, even though there
   is not enough resources on a local node. The local node can rely on
   optimized retries to complete the reservations.

6.2.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.

Manner et al             Expires December, 2003                [Page 21]

Internet-Draft          Analysis of QoS Signaling              June 2003

   To support multicast, YESSIR simplifies 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. While
   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
   existing reservation of the previous sender.

   It was proven that YESSIR one-pass reservation model has better
   performance and lower processing cost, comparing with a regular two-
   way signaling protocol, such as RSVP.

   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.

   YESSIR does not have any particular support for mobility and the
   security of YESSIR relies on RTP/RTCP security measures.

6.2.2.  Conclusion

   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.

6.3.  Boomerang

   Boomerang [FNM+99] is a another 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-
   oriented reservations and resource query. Flows are identified with
   the common 5-tuple and the QoS can be specified with various means,
   e.g.. service class and bit rate. Boomerang messages are in the
   initial implementation transported in ICMP ECHO / REPLY messages.

6.3.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.

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

Manner et al             Expires December, 2003                [Page 22]

Internet-Draft          Analysis of QoS Signaling              June 2003

   implementation. However, this is mainly due to the limited
   functionality provided by the protocol compared to RSVP.

   Boomerang messages are quite short and consume a relatively low
   amount of link bandwidth. This is due to the limited functionality of
   the protocol, for example, no security specific information or
   policy-based interaction are provided. Being sender oriented, the
   bandwidth consumption mostly affects the downstream direction, from
   the sender to the receiver.

   As Boomerang is sender oriented, there is no need to store backward
   information. This reduces the signaling required. The rest of the
   issues that were identified with RSVP apply with Boomerang. No
   security mechanism is specified for Boomerang.

   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. Still, often
   firewalls drop ICMP packets making the protocol useless.

6.3.2.  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.


   INSIGNIA [LGZC00] 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 QoS signaling data along with the
   normal 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
   signaled 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.

Manner et al             Expires December, 2003                [Page 23]

Internet-Draft          Analysis of QoS Signaling              June 2003

   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

   INSIGNIA, however, (completely) lacks a security framework and does
   not investigate how to secure signaled QoS data in ad-hoc network
   where relatively weak trust or even no trust exists between the
   participating nodes. Hence authorization and charging especially
   might be a challenge. The security protection of in-band signaling is
   costly since the data delivery itself experiences increased latency
   if security processing is done hop-by-hop. Since the QoS signaling
   information is encoded into the flow label and end-to-end addressing
   is used, it is very difficult to provide security other than IPsec in
   tunnel mode.

6.5.  BGRP

   Border Gateway Reservation Protocol (BGRP) [BGRP] is a signaling
   protocol for inter-domain 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.

7.  Summary

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

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

Manner et al             Expires December, 2003                [Page 24]

Internet-Draft          Analysis of QoS Signaling              June 2003

8.  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 and references.

9.  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. Since
   the first version, Martin Karsten has provided text about the
   processing overhead of RSVP and Hannes Tschofenig has provided text
   about various security issues in the protocols. Henning Schulzrinne
   and Ping Pan have provided more information on RSVP transportation
   after the second revision.

10.  Acknowledgment

   We would like to acknowledge Bob Braden and Vlora Rexhepi for their
   useful comments.

11.  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.

   [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.

Manner et al             Expires December, 2003                [Page 25]

Internet-Draft          Analysis of QoS Signaling              June 2003

   [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

   [RFC2362] 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, June, 1998.

   [Hame02] L-N. Hamer, B. Gage, B. Kosinski, and Hugh Shieh, Session

Manner et al             Expires December, 2003                [Page 26]

Internet-Draft          Analysis of QoS Signaling              June 2003

   Authorization Policy Element, Internet Draft (in RFC editor queue),
   Nov 2002.  (draft-ietf-rap-rsvp-authsession-05.txt)

   [Berg03] L. Berger (ed), Generalized MPLS Signaling - RSVP-TE
   Extensions. RFC 3473, January 2003.

   [KoRe03] K. Kompella, Y. Rekhter, Signalling Unnumbered Links in
   RSVP-TE, RFC 3477, January 2003.

   [LiPe02] Z. Lin, D. Pendarakis, Generalized MPLS (GMPLS) RSVP-TE
   Usage and Extensions for Automatically Switched Optical Network
   (ASON), Internet draft (in RFC editor queue), Oct. 2002.  (draft-lin-

   [OIF-UNI-1.0] Optical Internetworking Forum (OIF) Implementation
   Agreement OIF-UNI-01.0, User Network Interface (UNI) 1.0 Signaling
   Specification, Oct. 2001.

   [RFC2379] L. Berger, RSVP over ATM Implementation Guidelines, RFC
   2379 (BCP), Aug 1998.

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

   [H.323] ITU-T Recommendation H.323, Packet-based Multimedia
   Communications Systems, Nov. 2000.

   [H.245] ITU-T Recommendation H.245, Control Protocol for Multimedia
   Communication, July 2000.

   [Raja03] B. Rajagopalan, LDP and RSVP Extensions for Optical UNI
   Signaling, Internet draft (under IESG review), Jan. 2003.

   [3GPP-TS23207] 3GPP TS 23.207 V5.6.0, End-to-end Quality of Service
   (QoS) Concept and Architecture, Release 5, Dec. 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] H. Tschofenig, "RSVP Security Properties". Internet Draft,
   Oct 2002. (draft-ietf-nsis-rsvp-sec-properties-00.txt)

   [Fu02] X. Fu, et al, "Analysis on RSVP Regarding Multicast".
   Internet Draft, Oct. 2002.  (draft-fu-rsvp-multicast-analysis-01.txt)

   [Thom02] M. Thomas, "Analysis of Mobile IP and RSVP Interactions".
   Internet draft, Oct. 2002.  (draft-thomas-nsis-rsvp-analysis-00.txt)

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

Manner et al             Expires December, 2003                [Page 27]

Internet-Draft          Analysis of QoS Signaling              June 2003

   [FrJo02] Pierre Fransson and Andreas Jonsson, "The need for an
   alternative to IPv4-options", in RVK (RadioVetenskap och
   Kommunikation), 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

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

   [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.

   [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+03] J. Manner, T. Suihko, M. Kojo, M. Liljeberg, K.
   Raatikainen, "Localized RSVP". Internet Draft, January 2003.  (draft-

   [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.

   [MA01] Bobgkyo Moon, Hamid Aghvami, "RSVP Extensions for Real-Time
   Services in Wireless Mobile Networks". IEEE Communications Magazine,
   December 2001, pp. 52-59.

Manner et al             Expires December, 2003                [Page 28]

Internet-Draft          Analysis of QoS Signaling              June 2003

   [RFC2205] R. Braden, Ed., et al, "Resource ReSerVation protocol
   (RSVP) -- version 1 functional specification," RFC2205.

   [RFC3209] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP

   [RFC2113] D. Katz, "IP Router Alert Option".

   [IP-OPT] P. Pan, H. Schulzrinne, "PF_IPOPTION: A kernel extension for
   IP option packet processing", Technical Memorandum 10009669-02TM,
   Bell Labs, Lucent Technologies, Murray Hill, NJ, June 2000.

   [STAGED] P. Pan, H. Schulzrinne, "Staged refresh timers for {RSVP}",
   Global Internet, Phoenix, Arizona, Nov. 1997.

   [RFC2961] L. Berger, et al, "RSVP refresh overhead reduction
   extensions", RFC 2961.

   [FAST-REROUTE] P. Pan, et al, "Fast Reroute Extensions to RSVP-TE for
   LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt.

   [RFC3036] L. Andersson, et al, "LDP Specification".

   [BGP] Y. Rekhter, et al, "A Border Gateway Protocol 4 (BGP-4)",
   draft-ietf-idr-bgp4-18.txt, 2002.

   [REQ] M. Brunner (ed.), "Requirements for Signaling Protocols".
   Internet draft (work in progress), June 2003.

12.  Authors' Information

      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

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

      Voice:  +49-551-39-14411
      Fax:    +49-551-39-14403

Manner et al             Expires December, 2003                [Page 29]

Internet-Draft          Analysis of QoS Signaling              June 2003

13.  Appendix A - Comparison of RSVP to the NSIS Requirements

   This section provides a comparison of RSVP to the requirements
   identified as part of the work in NSIS [REQ]. The numbering follows
   the division in the requirements document.

   <To be continued>

   5.1 Architecture and Design Goals

      5.1.1 NSIS SHOULD provide availability information on request

        RSVP itself does not support query-type of operations. However,
        the RSVP diagnosis messages extension [RFC2745] provides a means
        to query resource availability.

      5.1.2 NSIS MUST be designed modularly

        RSVP was designed to be modular by way of TLV objects, however
        it is regarded being lack of sufficient extensibility in various
        kind of signalling applications.

      5.1.3 NSIS MUST decouple protocol and information

        RSVP is decoupled from the IntServ QoS specifications. Still,
        the concept of sessions in RSVP are somewhat coupled to the
        information it carries.

      5.1.4 NSIS MUST support independence of signaling and network
            control paradigm

        The IntServ information carried by RSVP does not tie the QoS
        provisioning mechanisms.

      5.1.5 NSIS SHOULD be able to carry opaque objects

        RSVP supports this.

   5.2 Signaling Flows

      5.2.1 The placement of NSIS Initiator, Forwarder, and Responder
            anywhere in the network MUST be allowed

        Standard RSVP works only end-to-end, although the RSVP proxy
        [BEGD02] and the Localized RSVP [MSK+03] have relaxed this
        assumption. RSVP relies on receiver-initiation way to perform
        QoS reservations.

Manner et al             Expires December, 2003                [Page 30]

Internet-Draft          Analysis of QoS Signaling              June 2003

      5.2.2 NSIS MUST support path-coupled and MAY support path-
            decoupled signaling

        Standard RSVP is path-coupled, but the SBM work makes RSVP
        somewhat path-decoupled.

      5.2.3 Concealment of topology and technology information SHOULD be

        RSVP itself does not provide such capability.

      5.2.4 Transparent signaling through networks SHOULD be possible

        RSVP messages are intecepted and evaluated in each RSVP router,
        and thus they may not cross certain RSVP-routers unnoticed.
        Still, the message processing rules allow unknown RSVP messages
        to be forwarded unharmed.

   5.3 Messaging

      5.3.1 Explicit erasure of state MUST be possible

        Supported by the PathTear and ResvTear messages.

      5.3.2 Automatic release of state after failure MUST be possible

        On error reservation states are torn down with PathTear

      5.3.3 NSIS SHOULD allow for sending notifications upstream

        There are two notifications in RSVP, confirm of a reservation
        set-up and tear down of reservation states as a result of

      5.3.4 Establishment and refusal to set up state MUST be notified

        PathErr and ResvErr messages provide refusal to set up state in

      5.3.5 NSIS MUST allow for local information exchange

        RSVP NULL service type [RFC2997] provides such a feature.

   5.4 Control Information

Manner et al             Expires December, 2003                [Page 31]

Internet-Draft          Analysis of QoS Signaling              June 2003

      5.4.1 Mutability information on parameters SHOULD be possible

        Rspec and Adspec are mutable; Tspec is (generally) end-to-end
        not mutable.

      5.4.2 It SHOULD be possible to add and remove local domain

        RSVP aggregation [RFC3175] and NULL service type [RFC2997] can
        provide such a feature.

      5.4.3 State MUST be addressed independent of flow identification

        RSVP states are tied to the flows, thus this requirement is not

      5.4.4 Modification of already established state SHOULD be seamless

        Modifications of a reservation is possible with RSVP.

      5.4.5 Grouping of signaling for several micro-flows MAY be

        Aggregated RSVP and RFC2961 allow this.

   5.5 Performance

      5.5.1 Scalability

        RSVP scales linearly to the number of reservation states.

      5.5.2 NSIS SHOULD allow for low latency in setup

        Setting up an RSVP reservation takes one round-trip time and the
        processing times are each RSVP router.

      5.5.3 NSIS MUST allow for low bandwidth consumption for the
            signaling protocol

        The initial reservations messages can not be compressed, but the
        refresh interval can be adjusted to consume less bandwidth, at
        the expense of possible inefficient resource usage.

      5.5.4 NSIS SHOULD allow to constrain load on devices

        See discussions on RSVP performance (section 4).

Manner et al             Expires December, 2003                [Page 32]

Internet-Draft          Analysis of QoS Signaling              June 2003

      5.5.5 NSIS SHOULD target the highest possible network utilization

        Don't use Guaranteed Service, use Controlled Load?

   5.6 Flexibility

      5.6.1 Flow aggregation

        Aggregated RSVP and RFC2961 allow this.

      5.6.2 Flexibility in the placement of the NSIS Initiator/Responder

        RSVP allows receiver as initiator of reservations.

      5.6.3 Flexibility in the initiation of state change

        RSVP receivers can initiate the state change during its

      5.6.4 SHOULD support network-initiated state change

        As RSVP supports hop-by-hop refreshment, this is made possible.

      5.6.5 Uni / bi-directional state setup

        RSVP is only uni-directional.

   5.7 Security

      5.7.1 Authentication of signaling requests

        Authentication is available in RSVP.

      5.7.2 Request Authorization

        Authorization with a PDP is possible in RSVP.

      5.7.3 Integrity protection

        The INTEGRITY Object is available in RSVP.

      5.7.4 Replay protection

        The INTEGRITY Object to replay protect the content of the
        signaling messages between two RSVP nodes.

Manner et al             Expires December, 2003                [Page 33]

Internet-Draft          Analysis of QoS Signaling              June 2003

      5.7.5 Hop-by-hop security

        The RSVP security model works only hop-by-hop.

      5.7.6 Identity confidentiality and network topology hiding

        The INTEGRITY Object can be used for this purpose.

      5.7.7 Denial-of-service attacks

        Challenging with RSVP.

      5.7.8 Confidentiality of signaling messages

        Not supported by RSVP.

      5.7.9 Ownership of state

        Challenging with RSVP.

   5.8 Mobility

      5.8.1 Allow efficient service re-establishment after handover

        Works for upstream but may not be achieved for the downstream
        if mobility is not noticed at the cross-over router.

   5.9 Interworking with other protocols and techniques

      5.9.1 MUST interwork with IP tunneling

        RFC 2746 discusses these issues.

      5.9.2 MUST NOT constrain either to IPv4 or IPv6

        RSVP supports both IP versions.

      5.9.3 MUST be independent from charging model

        RSVP does not discuss this.

      5.9.4 SHOULD provide hooks for AAA protocols

        COPS and RSVP work together.

Manner et al             Expires December, 2003                [Page 34]

Internet-Draft          Analysis of QoS Signaling              June 2003

      5.9.5 SHOULD work with seamless handoff protocols

        Not supported by RSVP. Still, RFC2205 suggests that route
        changes should be indicated to the local RSVP daemon, which can
        then initiate state refresh.

      5.9.6 MUST work with traditional routing

        RSVP expects traditional routing.

   5.10 Operational

      5.10.1 Ability to assign transport quality to signaling messages

        This is a network design issue, but is possible with DiffServ.

      5.10.2 Graceful fail over

        RSVP supports this.

      5.10.3 Graceful handling of NSIS entity problems

        RSVP itself does not supports this.

   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
   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

Manner et al             Expires December, 2003                [Page 35]