GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4094

Network Working Group J. Manner Request for Comments: 4094 X. Fu Category: Informational May 2005

    Analysis of Existing Quality-of-Service Signaling Protocols

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

Abstract

 This document reviews some of the existing Quality of Service (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 mistakes during the design and implementation of any new
 protocol in this area.

Table of Contents

 1. Introduction ....................................................3
 2. RSVP and RSVP Extensions ........................................4
    2.1. Basic Design ...............................................4
         2.1.1. Signaling Model .....................................4
         2.1.2. Soft State ..........................................5
         2.1.3. Two-Pass Signaling Message Exchanges ................5
         2.1.4. Receiver-Based Resource Reservation .................5
         2.1.5. Separation of QoS Signaling from Routing ............5
    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 ......................................8
         2.2.6. IEEE 802-Style LAN Interface ........................8
         2.2.7. ATM Interface .......................................9
         2.2.8. DiffServ Interface ..................................9
         2.2.9. Null Service Type ...................................9
         2.2.10. MPLS Traffic Engineering ..........................10
         2.2.11. GMPLS and RSVP-TE .................................11

Manner & Fu Informational [Page 1] RFC 4094 Analysis of QoS Signaling May 2005

         2.2.12. GMPLS Operation at UNI and E-NNI Reference
                 Points ............................................12
         2.2.13. MPLS and GMPLS Future Extensions ..................12
         2.2.14. ITU-T H.323 Interface .............................13
         2.2.15. 3GPP Interface ....................................13
    2.3. Extensions for New Deployment Scenarios ...................14
    2.4. Conclusion ................................................15
 3. RSVP Transport Mechanism Issues ................................16
    3.1. Messaging Reliability .....................................16
    3.2. Message Packing ...........................................17
    3.3. MTU Problem ...............................................17
    3.4. RSVP-TE vs. Signaling Protocol for RT Applications ........18
    3.5. What Would Be a Better Alternative? .......................18
 4. RSVP Protocol Performance Issues ...............................19
    4.1. Processing Overhead .......................................19
    4.2. Bandwidth Consumption .....................................20
 5. RSVP Security and Mobility .....................................21
    5.1. Security ..................................................21
    5.2. Mobility Support ..........................................22
 6. Other QoS Signaling Proposals ..................................23
    6.1. Tenet and ST-II ...........................................23
    6.2. YESSIR ....................................................24
         6.2.1. Reservation Functionality ..........................24
         6.2.2. Conclusion .........................................25
    6.3. Boomerang .................................................25
         6.3.1. Reservation Functionality ..........................25
         6.3.2. Conclusions ........................................26
    6.4. INSIGNIA ..................................................26
 7. Inter-Domain Signaling .........................................27
    7.1. BGRP ......................................................27
    7.2. SICAP .....................................................27
    7.3. DARIS .....................................................28
 8. Security Considerations ........................................30
 9. Summary ........................................................30
 10. Contributors ..................................................31
 11. Acknowledgements ..............................................31
 12. Appendix A: Comparison of RSVP to the NSIS Requirements .......32
 13. Normative References ..........................................38
 14. Informative References ........................................38

Manner & Fu Informational [Page 2] RFC 4094 Analysis of QoS Signaling May 2005

1. Introduction

 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 mistakes during the
 design and implementation of any new protocol in this area.
 There have been a number of historic attempts to deliver QoS or
 generic signaling to the Internet.  In the early years, it was
 believed that multicast would be popular for the majority of
 communications; thus, both RSVP and earlier ST-II were designed in a
 way that 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 (YEt another Sender Session Internet Reservations) [PS98] and
 Boomerang [FNM+99] are examples of protocols designed after RSVP.
 Both were meant to be simpler than RSVP.  YESSIR is an extension to
 RTCP, whereas Boomerang is used with ICMP.
 Previously, a lot of work has been targeted at creating a new
 signaling protocol for resource control.  Istvan Cselenyi suggested
 having a QoSSIG BOF in IETF47, for identifying problems in QoS
 signaling, but failed to get enough support [URL1].  Some people
 argued, "in many ways, RSVP improved upon ST-2, and it did start out
 simpler, but it resulted in a design with complexity and
 scalability", while others thought that "new knowledge and
 requirements" made RSVP insufficient.  Some concluded that there is
 no simpler way to handle the same problem than 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).
 This failed because of "missing community interest".
 OPENSIG [URL2] has been involved in the Internet signaling for years.
 Ping Pan initiated a SIGLITE [URL3] BOF mailing list to investigate
 lightweight Internet signaling.  Finally, NSIS BOF was successful,
 and the NSIS WG was formed.

Manner & Fu Informational [Page 3] RFC 4094 Analysis of QoS Signaling May 2005

 The most mature and original protocols are presented in their own
 sections, and other QoS signaling protocols are presented in later
 subsections.  The presented protocols are chosen based on relevance
 to the work within NSIS.  The aim is not to review every existing
 protocol.

2. RSVP and RSVP Extensions

 RSVP (the Resource Reservation Protocol) [ZDSZ93] [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.

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

Manner & Fu Informational [Page 4] RFC 4094 Analysis of QoS Signaling May 2005

 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.

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

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

2.1.4. Receiver-Based Resource Reservation

 Receiver-initiation is critical for RSVP to set up 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 could introduce a restriction to receiver-
 initiation.

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

Manner & Fu Informational [Page 5] RFC 4094 Analysis of QoS Signaling May 2005

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

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 [RFC2998]) and work-in-progress I-Ds (e.g., proxy) are not
 covered here.

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
 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's
 handling of policy events.  It introduces objects that are
 interpreted only by policy-aware nodes (PEPs) that interact with
 policy decision points (PDPs).  Nodes that are unable to interpret
 the POLICY_DATA objects are called policy-ignorant nodes (PINs).  The

Manner & Fu Informational [Page 6] RFC 4094 Analysis of QoS Signaling May 2005

 content of the POLICY_DATA object itself is protected only between
 PEPs and therefore provides end-to-middle or middle-to-middle
 security.
 [RFC2749] specifies the usage of COPS policy services in RSVP
 environments.  [RFC3181] specifies a preemption priority policy
 element (PREEMPTION_PRI) for use by RSVP POLICY_DATA Object.
 [RFC3520] 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
 object.

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 refresh state
 without the transmission of whole refresh messages.  It defines the
 following objects: MESSAGE_ID, MESSAGE_ID_ACK, MESSAGE_ID_NACK,
 MESSAGE_ID LIST, MESSAGE_ID SRC_LIST, and MESSAGE_ID MCAST_LIST
 objects.  Three new RSVP message types are defined:
 1) Bundle messages consist of a bundle header followed by a body
    consisting one or more standard RSVP messages.  Bundle messages
    help in scaling RSVP to reduce processing overhead and bandwidth
    consumption.
 2) ACK messages carry one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK
    objects.  ACK messages are sent between neighboring RSVP nodes to
    detect message loss and to support reliable RSVP message delivery
    on a per-hop basis.
 3) Srefresh messages carry one or more MESSAGE_ID LIST, MESSAGE_ID
    SRC_LIST, and MESSAGE_ID MCAST_LIST objects.  They correspond to
    Path and Resv messages that establish the states.  Srefresh
    messages are used to refresh RSVP states without transmitting
    standard Path or Resv messages.

Manner & Fu Informational [Page 7] RFC 4094 Analysis of QoS Signaling May 2005

2.2.5. RSVP over RSVP

 [RFC3175] allows installation of 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 is 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 Differentiated Services
    Code Point (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.
 3) FILTER_SPEC object, which identifies the aggregating router for
    the aggregate reservation, and is syntactically identical to the
    SENDER_TEMPLATE object.
 From the perspective of RSVP signaling and the handling of data
 packets in the aggregation region, these cases are equivalent to that
 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 for 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.

Manner & Fu Informational [Page 8] RFC 4094 Analysis of QoS Signaling May 2005

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 virtual circuits
 (VCs), and that an explicit release of RSVP associated QoS VCs must
 be performed once the VC for forwarding RSVP control messages
 terminates.  Although a separate control VC is also possible for
 forwarding RSVP control messages, [RFC2379] recommends creating a
 best-effort short-cut first (if one does not exist), which can allow
 setting up RSVP-triggered VCs to use the best-effort end-point.  (A
 short-cut is a point-to-point VC where the two end-points are located
 in different IP subnets.)  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 that the
 configurable inactivity timers of VCs be set to "infinite".  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.  For 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
 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., enterprise resource planning
 (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.

Manner & Fu Informational [Page 9] RFC 4094 Analysis of QoS Signaling May 2005

2.2.10. MPLS Traffic Engineering

 RSVP-TE [RFC3209] specifies the core extensions to RSVP for
 establishing constraint-based 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).
 RFC3209 also defines new C-Types (LSP_TUNNEL_IPv4 and
 LSP_TUNNEL_IPv6) for the SESSION, SENDER_TEMPLATE, and FILTER_SPEC
 objects.  Here, a session is the association of LSPs that support the
 LSP-tunnel.  The traffic on an LSP can be classified as the set of
 packets that are assigned the same MPLS label value at the
 originating node of an LSP-tunnel.
 The following 5 new objects are also defined:
 1) EXPLICIT_ROUTE object (ERO), which is incorporated into RSVP Path
    messages, encapsulating a concatenation of hops that constitutes
    the explicitly routed path.  Using this object, the paths taken by
    label-switched RSVP-MPLS flows can be pre-determined independently
    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
    information, such as setup and holding 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.

Manner & Fu Informational [Page 10] RFC 4094 Analysis of QoS Signaling May 2005

 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 signaled "EXP<-->PHB mapping" (e.g., [RFC3270]).
 RSVP-TE provides a way to indicate an unnumbered link in its Explicit
 Route and Record Route Objects through [RFC3477].  This specifies the
 following extensions:
  1. An Unnumbered Interface ID Subobject, which is a subobject of the

Explicit Route Object (ERO) used to specify unnumbered links.

  1. An LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to

form or use an identifier for an unnumbered Forwarding Adjacency.

  1. A new subobject of the Record Route Object, used to record that the

LSP path traversed an unnumbered link.

2.2.11. GMPLS and RSVP-TE

 GMPLS RSVP-TE [RFC3473] is an extension of RSVP-TE.  It enables the
 provisioning of data-paths within networks supporting a variety of
 switching types including packet and cell switching networks, layer
 two networks, TDM networks, and photonic networks.
 It defines the new Notify message (for general event notification),
 which may contain notifications being sent, with respect to each
 listed LSP, both upstream and downstream.  Notify messages can be
 used 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.
 A number of new RSVP-TE (sub)objects are defined in GMPLS RSVP-TE for
 general uses of MPLS:
  1. a Generalized Label Request Object;
  1. a Generalized Label Object;
  1. a Suggested Label Object;
  1. a Label Set Object (to restrict label choice);
  1. an Upstream_Label object (to support bidirectional LSPs);
  1. a Label ERO subobject;

Manner & Fu Informational [Page 11] RFC 4094 Analysis of QoS Signaling May 2005

  1. IF_ID RSVP_HOP objects (IPv4 & IPv6; to identify interfaces in

out-of-band signaling or in bundled links);

  1. IF_ID ERROR_SPEC objects (IPv4 & IPv6; to identify interfaces in

out-of-band signaling or in bundled links);

  1. an Acceptable Label Set object (to support negotiation of label

values in particular for bidirectional LSPs)

  1. a Notify Request object (may be inserted in a Path or Resv message

to indicate where a notification of LSP failure is to be sent)

  1. a Restart_Cap Object (used on Hello messages to identify recovery

capabilities)

  1. an Admin Status Object (to notify each node along the path of the

status of the LSP, and to control that state).

2.2.12. GMPLS Operation at UNI and E-NNI Reference Points

 The ITU-T defines network reference points that separate
 administrative or operational parts of the network.  The reference
 points are designated as:
  1. User to Network Interfaces (UNIs) if they lie between the user or

user network and the core network, or

  1. External Network to Network Interfaces (E-NNIs) if they lie between

peer networks, network domains, or subnetworks.

 GMPLS is applicable to the UNI and E-NNI without further
 modification, and no new messages, objects, or C-Types are required.
 See [OVERLAY].

2.2.13. MPLS and GMPLS Future Extensions

 At the time of writing, MPLS and GMPLS are being extended by the MPLS
 and CCAMP Working Groups to support additional sophisticated
 functions.  This will inevitably lead to the introduction of new
 C-Types for existing objects, and to the requirement for new objects
 (CNums).  It is possible that new messages will also be introduced.

Manner & Fu Informational [Page 12] RFC 4094 Analysis of QoS Signaling May 2005

 Some of the key features and functions being introduced include the
 following:
  1. Protection and restoration. Features will be developed to provide
    1. end-to-end protection
    2. segment protection
    3. various protection schemes (1+1, 1:1, 1:n)
    4. support of extra traffic on backup LSPs
  2. Diverse path establishment for protection and load sharing.
  3. Establishment of point-to-multipoint paths.
  4. Inter-area and inter-AS path establishment with
    1. explicit path control
    2. bandwidth reservation
    3. path diversity
  5. Support for the requirements of Automatic Switched Optical Network

(ASON) signaling as defined by the ITU-T, including call and

   connection separation.
 - Crankback during LSP setup.

2.2.14. ITU-T H.323 Interface

 ITU-T H.323 ([H.323]) recommends the IntServ resource reservation
 procedure using RSVP.  The information as to whether an endpoint
 supports RSVP should be conveyed during the H.245 [H.245] capability
 exchange phase, by setting appropriate qOSMode fields.  If both
 endpoints are RSVP-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.  If this timer expires or RSVP
 reservation fails at any point during an H.323 call, the action is up
 to the vendor.  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.15. 3GPP Interface

 Third Generation Partnership Project (3GPP) TS 23.207
 ([3GPP-TS23207]) specifies the QoS signaling procedure with policy
 control within the Universal Mobile Telecommunications System (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

Manner & Fu Informational [Page 13] RFC 4094 Analysis of QoS Signaling May 2005

 Originating (MO) side and the Mobile Terminating (MT) side.  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 a
 bidirectional reservation is needed, the RSVP signaling exchange must
 be performed twice between the end-points.  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 expected
 more and more to provide a more generic service for various signaling
 applications.  However, RSVP messages were designed in a way to
 support end-to-end QoS signaling optimally.  To meet the increasing
 demand that a signaling protocol also operate in host-to-edge and
 edge-to-edge ways, and that it serve for some other signaling
 purposes in addition to end-to-end QoS signaling, RSVP needs to be
 made more flexible and applicable for more generic signaling.
 RSVP proxies [BEGD02] extend RSVP by originating or receiving 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.  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 be dropped by some routers
 [FJ02].  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 (LRSVP) [JR03] [MSK+04].  The documents present the
 concept of local RSVP-based reservation that alone can be used to
 trigger reservation within an access network.  In those cases, an
 end-host may request QoS from its own access network without the

Manner & Fu Informational [Page 14] RFC 4094 Analysis of QoS Signaling May 2005

 cooperation 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 that are low in processing power and
 functionality, having an RSVP daemon run and take care of the
 signaling may introduce unnecessary overhead.  One article [Kars01]
 proposes to create a remote API so that the daemon would in fact run
 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 size of signaled data
 due to the limitation of message size.  An 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 they 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 to the applications.
 RSVP has proven to be a very well designed protocol.  However, it has
 a number of fundamental protocol design issues that require 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.
 RSVP has a comprehensive set of filtering styles, including
 Wildcard-Filter (WF), Fixed-Filter (FF), and Shared-Explicit (SE),
 and is not tied to certain QoS objects.  (RSVP is not tied to IntServ
 Guaranteed Service/Controlled Load (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.

Manner & Fu Informational [Page 15] RFC 4094 Analysis of QoS Signaling May 2005

 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
 reservation.
 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, the 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 -- 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 be 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.
 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
 [PS00], with minor kernel changes IP option processing introduces
 very little overhead on a Free BSD box.
 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
 network would be one soft-state refresh interval later.  By default,
 a soft-state refresh interval is 30 seconds.

Manner & Fu Informational [Page 16] RFC 4094 Analysis of QoS Signaling May 2005

 To overcome this problem, [PS97] 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 the mechanism's 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.

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 OSes are based on
 UNIX.  [PS00] 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 interfaces.
 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.  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 example, on
 some routers, a Frame Relay interface can support a link MTU size up
 to 9600 bytes.  Currently, the RSVP MTU problem is not a realistic
 concern in MPLS networks.

Manner & Fu Informational [Page 17] RFC 4094 Analysis of QoS Signaling May 2005

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

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 (LSPs) do not
 change frequently.
 In fact, the network operators typically set up the MPLS LSPs so that
 they cannot switch too quickly.  For example, the operators often
 regulate the Constraint-based Shortest Path First (CSPF) computation
 interval to prevent or delay a large volume of user traffic from
 shifting from one session to another during LSP path optimization.
 (CSPF is a routing algorithm that operates from the network edge to
 compute the "most" optimal routes for the LSPs.)  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 IDs 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 for which 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 Would Be a Better Alternative?

 A good signaling protocol should be transparent to the applications.
 On the other hand, the design of a signaling protocol must take the
 intended and potential applications into consideration.
 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.

Manner & Fu Informational [Page 18] RFC 4094 Analysis of QoS Signaling May 2005

 In the last several years, a number of new applications have emerged
 that are proposed to need IP signaling, beyond the traditional ones
 associated with quality of service and resource allocation.  On-path
 firewall control/NAT traversal (synergistic with the midcom design of
 [RFC3303]) is one of these.  There are far-out applications such as
 depositing active network code in network devices.  Next-generation
 signaling protocols dealing with novel applications, with network
 security requirements, and with the MTU problems described above,
 will prevent the re-use of the existing RSVP transport mechanism.
 If a new transport protocol is needed, the protocol must be able to
 handle the following:
  1. reliable messaging;
  1. message packing;
  1. the MTU problem;
  1. small triggered message volume.

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 has to
    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 such as
    reservation styles, scope object, and blockade state, are also
    required to be presented in the basic protocol.  This not only
    adds sources of failures and errors, but also complicates the
    state machine [Fu02].  Third, the same RSVP signaling messages are
    used not only for maintaining the state, but also for 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

Manner & Fu Informational [Page 19] RFC 4094 Analysis of QoS Signaling May 2005

    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, which increase the
    efficiency of RSVP processing.  Typical RSVP implementations are
    user-space daemons interacting with the kernel; thus, 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 [KSS01], the relative
    execution costs for the message sending/reception system calls
    "sendto", "select", and "recvmsg" were 14-16%, 6-7%, 9-10%,
    individually, of the total execution cost.  [KSS01] 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 depending on
    implementation.  For example, the RSVP/routing overhead has been
    measured to be approximately 11-12% of the total execution cost
    [KSS01].

4.2. Bandwidth Consumption

 By "bandwidth consumption" we mean the amount of bandwidth used
 during the lifetime of a session: to set up a reservation session, to
 keep the session alive, and finally to close it.
 RSVP messages are sent either to trigger a new reservation or to
 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.

Manner & Fu Informational [Page 20] RFC 4094 Analysis of QoS Signaling May 2005

 Thus, the following formula represents the bandwidth consumption in
 bytes for an RSVP session lasting n seconds:
    F(n) = (bP + bR) + ((n/Ri) * (bP + bR)) + bPt
    bP:  IP payload size of Path message
    bR:  IP payload size of Resv message
    bPt: IP payload size of Path Tear message
    Ri:  refresh interval
 For example, for a simple Controlled Load reservation without
 security and identification requirements (where bP is 172 bytes, bR
 is 92, bPt is 44 bytes, and Ri is 30 seconds), the bandwidth
 consumption would be as follows:
    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 to
 convey this information in RSVP messages (PATH or RESV) in a secure
 manner, [RFC3182] specifies the encoding of identities as RSVP
 POLICY_DATA Object.  However, to provide ironclad 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 insufficient.
 To provide hop-by-hop integrity and authentication of RSVP messages,
 an 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 or protect against
 message deletion.  In the current RSVP security scheme, the two-way
 peer authentication and key management procedures are still missing.
 The security issues have been well analyzed in [Tsch03].

Manner & Fu Informational [Page 21] RFC 4094 Analysis of QoS Signaling May 2005

5.2. Mobility Support

 Two issues raise concern when a mobile node (MN) uses RSVP: the flow
 identifier and reservation refresh.  When an MN changes locations, it
 may need to change one of its assigned IP addresses.  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 initialized.
 The second issue relates to 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 it cannot 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 (Section 3.6,
 [RFC2205]).  However, not all local mobility protocols affect routing
 directly in routers (not even Mobile IP), and thus mobility may not
 be noticed at RSVP routers.  Therefore, 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+04], in
 which one section discusses the coupling of RSVP and the mobility
 management mechanisms and proposes small extensions to RSVP to handle
 the handover event better, 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) [TBA01], 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.

Manner & Fu Informational [Page 22] RFC 4094 Analysis of QoS Signaling May 2005

 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 resources 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
 [Thom02].

6. Other QoS Signaling Proposals

6.1. Tenet and ST-II

 Tenet and ST-II are two original QoS signaling protocols for the
 Internet.
 In the original Tenet architecture [BFM+96], the receiver sends a
 reservation request toward the source.  Each network node along the
 way makes the reservation.  Once the request arrives 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 in the following way: 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 the
 Stream Control Message Protocol (SCMP) for all control functions.
 ST is simple and contains only a single PDU format, which 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, it 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
 that for RSVP [MESZ94].  ST-II does not provide security, but
 [RFC1819] describes some objects related to charging.

Manner & Fu Informational [Page 23] RFC 4094 Analysis of QoS Signaling May 2005

6.2. YESSIR

 YESSIR (YEt another Sender Session Internet Reservations) [PS98] 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 advantage of
 Real-Time Protocol (RTP).  YESSIR also introduces a concept called
 partial reservation, in which, for certain types of applications, the
 reservation requests can be passed to the next hop, even though there
 are 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 [PS98] 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 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.
 Although 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 has been shown that the YESSIR one-pass reservation model has
 better performance and lower processing cost than a regular two-way
 signaling protocol, such as RSVP [PS98].  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.

Manner & Fu Informational [Page 24] RFC 4094 Analysis of QoS Signaling May 2005

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 setup and teardown, and it has no
 requirements on the far end node.  Instead, it 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 by various means;
 e.g., service class and bit rate.  In the initial implementation,
 Boomerang messages are 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 that of the ISI RSVP daemon
 implementation.  However, this is mainly due to the limited
 functionality provided by the protocol compared to that provided by
 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 is 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.

Manner & Fu Informational [Page 25] RFC 4094 Analysis of QoS Signaling May 2005

 The Boomerang protocol has deployment issues similar to those of 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,
 firewalls often 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.  However, 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.

6.4. INSIGNIA

 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 on the MAC layers,
 but this is undefined, so 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.

Manner & Fu Informational [Page 26] RFC 4094 Analysis of QoS Signaling May 2005

 After handover, data that was transmitted to the old base station can
 be forwarded to the new base station, so 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
 example.
 INSIGNIA, however, (completely) lacks a security framework and does
 not investigate how to secure signaled QoS data in an ad-hoc network,
 where relatively weak trust or even no trust exists between the
 participating nodes.  Therefore, 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.  Because
 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.

7. Inter-Domain Signaling

 This section gives a short overview of protocols designed for inter-
 domain signaling.

7.1. 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.
 In terms of message processing load, BGRP scales state storage and
 bandwidth.  Because 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.2. SICAP

 SICAP (Shared-segment Inter-domain Control Aggregation protocol)
 [SGV03] is an inter-domain signaling solution that performs shared-
 segment aggregation [SGV02] on the Autonomous System (AS) level in
 order to reduce state required at Boundary Routers (BRs).  SICAP
 performs aggregation based on path segments that different
 reservations share.  Thus, reservations may be merged into aggregates
 that do not necessarily extend all the way to the reservation's
 destination.  The motivation for creating "shorter" aggregates is
 that, on one hand, their ability to accommodate future requests more
 easily, and, on the other hand, the minimization of aggregates

Manner & Fu Informational [Page 27] RFC 4094 Analysis of QoS Signaling May 2005

 created and consequently, the reduction of state required to manage
 established reservations.  However, in contrast to the sink-tree
 approach (used by BGRP [BGRP]), the shared-segment approach
 introduces intermediate de-aggregation locations.  These are ASes
 where aggregates may experience "re-aggregation".  At these
 locations, routers that perform aggregation (AS egress routers) have
 to keep track of the mapping between reservations and aggregates.
 One possible way to do this is to keep each reservation identifier
 and the corresponding resources stored at each aggregator.  However,
 this solution incurs a high state penalty.  SICAP avoids this state
 penalty by keeping track of the mapping between aggregates and
 reservations at the level of destination domains rather than
 explicitly map individual reservations to aggregates.  In other
 words, SICAP maintains, per aggregate, a list of the destination
 prefixes advertised by the destination AS an aggregate provides
 access to.
 Pan et al. show that BGRP scales well in terms of control state,
 message processing, and bandwidth efficiency, when compared to RSVP
 without aggregation.  However, partially given that BGRP was the
 first approach to explore the issue of inter-domain control
 aggregation in detail, they did not provide a comparison with other
 aggregation protocols.
 SICAP and BGRP messaging sequences are similar, and consequently,
 these protocols attain the same signaling load.  This load is exactly
 the same as that attained by proposals that do not perform
 aggregation, given that SICAP and BGRP exchange messages per
 individual reservation.  In terms of bandwidth, both protocols
 provision aggregates with the exact bandwidth required by their
 merged reservations.  Therefore, the major difference between SICAP
 and BGRP is state maintained at BRs, which is significantly reduced
 by SICAP.  We consider this to be of importance not so much for
 offering a better-performing alternative to BGRP, but for quantifying
 the performance improvements that might still be available in the
 research field of control path aggregation.  Finally, to deal with
 the possible problem of the signaling load, SICAP uses an over-
 reservation mechanism [SGV03b], whose design took into consideration
 a possible support for BGRP.

7.3. DARIS

 Dynamic Aggregation of Reservations for Internet Services (DARIS)
 [Bless02] [Bless04] defines an inter-domain aggregation scheme for
 resource reservations.  Basically, it aggregates reservations along
 Autonomous System (AS) paths (or parts thereof).  A set of
 reservations whose data paths share a common sequence of ASes are
 integrated into a joint reservation aggregate along that shared sub-

Manner & Fu Informational [Page 28] RFC 4094 Analysis of QoS Signaling May 2005

 path.  All entities within the aggregate, except for aggregate
 starting and end point, can remove state information of the included
 individual reservations, thereby saving states.  They just need to
 hold the necessary information about the encompassing aggregate.
 Moreover, these intermediate ASes are no longer involved in signaling
 that is related to the aggregated reservations.  If more aggregate
 resources are reserved than were actually required, the capacity of
 the aggregate does not need to be adapted with every new or released
 reservation (thereby reducing the number of message exchanges).
 An aggregate between two ASes is created as soon as a threshold k is
 exceeded that describes the active number of unidirectional
 reservations between them.  It is, however, possible to apply
 different aggregation triggers.  Furthermore, DARIS allows aggregates
 to be nested hierarchically.  Therefore, the existence of shorter
 aggregates does not prevent the creation of longer (and thus more
 efficient) aggregates, and vice versa.  An evaluation of recent BGP
 routing information in [Bless02] showed that 92% of all end-to-end
 paths contain at least four ASes.  Consequently, an aggregate from
 edge AS to edge AS can span four or more ASes, thus saving states and
 signaling message processing in at least two ASes.
 There is, however, a small chance that a reservation cannot be
 included in a new aggregate, because it was already aggregated
 elsewhere.  This so-called "aggregation conflict" is caused by the
 prior removal of state information related to individual reservations
 within intermediate ASes of the encompassing aggregate.  This may
 also bring difficulties if reservations or aggregates are re-routed
 between ASes.  One must be careful when considering how to define
 sophisticated adaptation techniques for these special cases, because
 they seem to become very complex.
 The signaling protocol DMSP (Domain Manager Signaling Protocol)
 supports aggregation by special extensions that reduce the
 reservation setup time for more than one round-trip time in some
 cases (e.g., if an aggregate's capacity must be increased before a
 new reservation can be included).  Details can be found in [Bless02].
 The DARIS concept was evaluated by using a simulation with a topology
 that was derived from real BGP routing table information and
 comprised more than 5500 ASes.  In comparison to a non-aggregated
 scenario, the number of saved states lay in the range of one to two
 orders of magnitude, and similar results were obtained with respect
 to the number of signaling messages.  Though [Bless02] describes
 DARIS in the context of distributed Domain Management entities
 (similar to a bandwidth broker), it can be applied in a router-based

Manner & Fu Informational [Page 29] RFC 4094 Analysis of QoS Signaling May 2005

 resource management environment, too.  This will achieve a higher
 degree of distribution, which is beneficial for large ASes, which are
 highly interconnected.
 A general issue with aggregation is that it is not the aggregating
 and de-aggregating ASes that profit from their initiated aggregates,
 but all intermediate ASes within an aggregate.  Therefore, some
 incentive for aggregate creation has to be given.  This may lead to
 novel cost models that have to be developed for aggregation concepts
 in the future.

8. Security Considerations

 This document does not present new technology or protocols.  Thus,
 there are no explicit security issues.  Still, individual protocols
 include different levels of security issues and those are highlighted
 in the relevant sections and references.

9. Summary

 Supporting flow-based soft state reservations has been proven useful.
 Still, there have been different ways to improve the performance,
 including refresh reduction and aggregation.  However, some of the
 main concerns with these signaling protocols are the complexity of
 the protocol, which affects implementations and processing overhead,
 and the security of the signaling.  Especially, a proper scheme to
 handle authentication and authorization of QoS resource requests and
 a framework for providing signaling message security seem to be
 missing from most protocols.  RSVP has a mechanism to protect
 signaling messages based on manually distributed keys and concepts
 for authorization, but they seem to be insufficient for a dynamic and
 mobile environment.  [Tsch03] provides more details on security
 properties provided by RSVP.  Moreover, secure and efficient
 signaling to and from mobile nodes has been one of the critical
 challenges not fully met by existing protocols.
 Moving QoS signaling protocols into a generic messenger can provide
 much adoption.  It is expected that the development of future
 protocols should learn from the lessons of existing ones.
 Nevertheless, the tradeoffs between the expected functionality,
 protocol complexity/performance would still be taken into account.
 For example, RSVP uses the two-way signaling mechanism, whereas
 YESSIR employs only one-pass signaling.  Both can be shown to out-
 perform the other in specific carefully chosen signaling scenarios.

Manner & Fu Informational [Page 30] RFC 4094 Analysis of QoS Signaling May 2005

10. Contributors

 This document is part of the work done in the NSIS Working Group.
 The document 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.  Kireeti Kompella and Adrian Farrel
 provided a review and updates to the discussion on RSVP-TE and GMPLS.

11. Acknowledgements

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

Manner & Fu Informational [Page 31] RFC 4094 Analysis of QoS Signaling May 2005

12. 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 [RFC3726].  The numbering
 follows the division in the requirements document.
 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+04] have relaxed this
      assumption.  RSVP relies on receiver-initiation way to perform
      QoS reservations.

Manner & Fu Informational [Page 32] RFC 4094 Analysis of QoS Signaling May 2005

    5.2.2.  NSIS MUST support Path-Coupled and MAY Support Path-
            Decoupled Signaling
      Standard RSVP is path-coupled, but the Subnet Bandwidth
      Manager (SBM) work makes RSVP somewhat path-decoupled.
    5.2.3.  Concealment of Topology and Technology Information SHOULD
            Be Possible
      RSVP itself does not provide such capability.
    5.2.4.  Transparent Signaling through Networks SHOULD Be Possible
      RSVP messages are intercepted 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
      messages.
    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
      errors.
    5.3.4.  Establishment and Refusal To Set Up State MUST Be Notified
      PathErr and ResvErr messages provide refusal to set up state in
      RSVP.
    5.3.5.  NSIS MUST Allow for Local Information Exchange
      RSVP NULL service type [RFC2997] provides such a feature.

Manner & Fu Informational [Page 33] RFC 4094 Analysis of QoS Signaling May 2005

 5.4.  Control Information
    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
            Information
      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
      met.
    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
            Provided
      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.

Manner & Fu Informational [Page 34] RFC 4094 Analysis of QoS Signaling May 2005

    5.5.4.  NSIS SHOULD Allow To Constrain Load on Devices
      See discussions on RSVP performance (section 4).
    5.5.5.  NSIS SHOULD Target the Highest Possible Network
            Utilization
      This depends on the IntServ service types, Controlled Load can
      provide better overall utilization than Guaranteed Service.
 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
      refreshment.
    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.

Manner & Fu Informational [Page 35] RFC 4094 Analysis of QoS Signaling May 2005

    5.7.4.  Replay Protection
      The INTEGRITY Object to replay protect the content of the
      signaling messages between two RSVP nodes.
    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.

Manner & Fu Informational [Page 36] RFC 4094 Analysis of QoS Signaling May 2005

    5.9.4.  SHOULD Provide Hooks for AAA Protocols
      COPS and RSVP work together.
    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.

Manner & Fu Informational [Page 37] RFC 4094 Analysis of QoS Signaling May 2005

13. Normative References

 [RFC3726]      Brunner, M., "Requirements for Signaling Protocols",
                RFC 3726, April 2004.

14. Informative References

 [3GPP-TS23207] 3GPP TS 23.207 V5.6.0, End-to-end Quality of Service
                (QoS) Concept and Architecture, Release 5, December
                2002.
 [BEBH96]       Braden, R., Estrin, D., Berson, S., Herzog, and D.
                Zappala, "The Design of the RSVP Protocol", ISI Final
                Technical Report, July 1996.
 [BEGD02]       Y. Bernet, N. Elfassy, S. Gai, and D. Dutt, "RSVP
                Proxy", Work in Progress, March 2002.
 [BFM+96]       A. Banerjea, D. Ferrari, B. Mah, M. Moran, D. Verma,
                and H.  Zhang, "The Tenet Real-Time Protocol Suite:
                Design, Implementation, and Experiences", IEEE/ACM
                Transactions on Networking, Volume 4, Issue 1,
                February 1996, pp. 1-10.
 [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.
 [Bless02]      R. Bless, "Dynamic Aggregation of Reservations for
                Internet Services", Proceedings of the Tenth
                International Conference on Telecommunication Systems
                - Modeling and Analysis (ICTSM 10), Vol. 1, pp. 26-38,
                October 3-6 2002, Monterey, California, available at
                http://www.tm.uka.de/doc/2003/ictsm-daris-journal-
                crc-web.pdf.
 [Bless04]      R. Bless, "Towards Scalable Management of QoS-based
                End-to- End Services" (PDF), Proceedings of NOMS 2004
                (IEEE/IFIP 2004 Network Operations and Management
                Symposium), April 2004, Seoul, Korea.
 [FAST-REROUTE] P. Pan, G. Swallow, and A. Atlas, "Fast Reroute
                Extensions to RSVP-TE for LSP Tunnels", Work in
                Progress, January 2004.

Manner & Fu Informational [Page 38] RFC 4094 Analysis of QoS Signaling May 2005

 [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.
 [FNS02]        G. Feher, K. Nemeth, and I. Cselenyi, "Performance
                evaluation framework for IP resource reservation
                signalling". Performance Evaluation 48 (2002), pp.
                131-156.
 [FJ02]         P. Fransson and A. Jonsson, "The need for an
                alternative to IPv4-options", in RVK (RadioVetenskap
                och Kommunikation), Stockholm, Sweden, pp. 162-166,
                June 2002.
 [Fu02]         X. Fu, C. Kappler, and H. Tschofenig, "Analysis on
                RSVP Regarding Multicast". Technical Report No. IFI-
                TB-2002-001, ISSN 1611-1044, Institute for
                Informatics, University of Goettingen, Oct 2002.
 [H.245]        ITU-T Recommendation H.245, Control Protocol for
                Multimedia Communication, July 2000.
 [H.323]        ITU-T Recommendation H.323, Packet-based Multimedia
                Communications Systems, Nov. 2000.
 [JR03]         Jukka Manner, Kimmo Raatikainen, "Localized QoS
                Management for Multimedia Applications in Wireless
                Access Networks". IASTED International Conference on
                Internet and Multimedia Systems and Applications (IMSA
                2003), August, 2003, pp. 193-200.
 [Kars01]       M. Karsten, "Experimental Extensions to RSVP -- Remote
                Client and One-Pass Signalling".  IWQoS 2001,
                Karlsruhe, Germany, June 2001.
 [KSS01]        M. Karsten, Jens Schmitt, Ralf Steinmetz,
                "Implementation and Evaluation of the KOM RSVP
                Engine", IEEE Infocom 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.

Manner & Fu Informational [Page 39] RFC 4094 Analysis of QoS Signaling May 2005

 [MA01]         B. Moon, and H. Aghvami, "RSVP Extensions for Real-
                Time Services in Wireless Mobile Networks".  IEEE
                Communications Magazine, December 2001, pp. 52-59.
 [MESZ94]       D. Mitzel, D. Estrin, S. Shenker, and L. Zhang, "An
                Architectural Comparison of ST-II and RSVP", Infocom
                1994.
 [MHS02]        Y Miao, W. Hwang, and C. Shieh, "A transparent
                deployment method of RSVP-aware applications on UNIX".
                Computer Networks, 40 (2002), pp. 45-56.
 [MSK+04]       J. Manner, T. Suihko, M. Kojo, M. Liljeberg, K.
                Raatikainen, "Localized RSVP", Work in Progress,
                September 2004.
 [OVERLAY]      G. Swallow, J. Drake, H. Ishimatsu, and Y. Rekhter,
                "GMPLS UNI: RSVP Support for the Overlay Model", Work
                in Progress, February 2004.
 [PS97]         P. Pan and H. Schulzrinne, "Staged refresh timers for
                RSVP", Global Internet, Phoenix, Arizona, November
                1997.
 [PS98]         P. Pan, and H. Schulzrinne, "YESSIR: A Simple
                Reservation Mechanism for the Internet". Proceedings
                of NOSSDAV, Cambridge, UK, July 1998.
 [PS00]         P. Pan, and 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.
 [RFC1819]      Delgrossi, L. and L. Berger, "Internet Stream Protocol
                Version 2 (ST2) Protocol Specification - Version
                ST2+", RFC 1819, August 1995.
 [RFC2113]      Katz, D., "IP Router Alert Option", RFC 2113, February
                1997.
 [RFC2205]      Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
                Jamin, "Resource ReSerVation Protocol (RSVP) --
                Version 1 Functional Specification", RFC 2205,
                September 1997.
 [RFC2207]      Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
                Data Flows", RFC 2207, September 1997.

Manner & Fu Informational [Page 40] RFC 4094 Analysis of QoS Signaling May 2005

 [RFC2210]      Wroclawski, J., "The Use of RSVP with IETF Integrated
                Services", RFC 2210, September 1997.
 [RFC2379]      Berger, L., "RSVP over ATM Implementation Guidelines",
                BCP 24, RFC 2379, August 1998.
 [RFC2380]      Berger, L., "RSVP over ATM Implementation
                Requirements", RFC 2380, August 1998.
 [RFC2745]      Terzis, A., Braden, B., Vincent, S., 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.
 [RFC2747]      Baker, F., Lindell, B., and M. Talwar, "RSVP
                Cryptographic Authentication", RFC 2747, January 2000.
 [RFC2749]      Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan,
                R., and A. Sastry, "COPS usage for RSVP", RFC 2749,
                January 2000.
 [RFC2750]      Herzog, S., "RSVP Extensions for Policy Control", RFC
                2750, January 2000.
 [RFC2814]      Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F., and
                M. Speer, "SBM (Subnet Bandwidth Manager): A Protocol
                for RSVP-based Admission Control over IEEE 802-style
                networks", RFC 2814, May 2000.
 [RFC2961]      Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
                F., and S. Molendini, "RSVP Refresh Overhead Reduction
                Extensions", RFC 2961, April 2001.
 [RFC2996]      Bernet, Y., "Format of the RSVP DCLASS Object", RFC
                2996, November 2000.
 [RFC2997]      Bernet, Y., Smith, A., and B. Davie, "Specification of
                the Null Service Type", RFC 2997, November 2000.
 [RFC2998]      Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang,
                L., Speer, M., Braden, R., Davie, B., Wroclawski, J.,
                and E. Felstaine, "A Framework for Integrated Services
                Operation over Diffserv Networks", RFC 2998, November
                2000.

Manner & Fu Informational [Page 41] RFC 4094 Analysis of QoS Signaling May 2005

 [RFC3175]      Baker, F., Iturralde, C., Le Faucheur, F., and B.
                Davie, "Aggregation of RSVP for IPv4 and IPv6
                Reservations", RFC 3175, September 2001.
 [RFC3181]      Herzog, S., "Signaled Preemption Priority Policy
                Element", RFC 3181, October 2001
 [RFC3182]      Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore,
                T., Herzog, S., and R. Hess, "Identity Representation
                for RSVP", RFC 3182, October 2001.
 [RFC3209]      Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
                V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
                LSP Tunnels", RFC 3209, December 2001.
 [RFC3270]      Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
                Vaananen, P., Krishnan, R., Cheval, P., and J.
                Heinanen, "Multi-Protocol Label Switching (MPLS)
                Support of Differentiated Services", RFC 3270, May
                2002.
 [RFC3303]      Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
                and A. Rayhan, "Middlebox communication architecture
                and framework", RFC 3303, August 2002.
 [RFC3473]      Berger, L., "Generalized Multi-Protocol Label
                Switching (GMPLS) Signaling Resource ReserVation
                Protocol-Traffic Engineering (RSVP-TE) Extensions",
                RFC 3473, January 2003.
 [RFC3477]      Kompella, K. and Y. Rekhter, "Signalling Unnumbered
                Links in Resource ReSerVation Protocol - Traffic
                Engineering (RSVP-TE)", RFC 3477, January 2003.
 [RFC3520]      Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh,
                "Session Authorization Policy Element", RFC 3520,
                April 2003.
 [SGV02]        R. Sofia, R. Guerin, and P. Veiga, "An Investigation
                of Inter-Domain Control Aggregation Procedures",
                International Conference on Networking Protocols, ICNP
                2002, Paris, France, November 2002.
 [SGV03]        R. Sofia, R. Guerin, and P. Veiga. SICAP, a Shared-
                segment Inter-domain Control Aggregation Protocol.
                High Performance Switching and Routing, HPSR 2003,
                Turin, Italy, June 2003.

Manner & Fu Informational [Page 42] RFC 4094 Analysis of QoS Signaling May 2005

 [SGV03b]       R. Sofia, R. Guerin, and P. Veiga. A Study of Over-
                reservation for Inter-Domain Control Aggregation
                Protocols. Technical report (short version under
                submission), University of Pennsylvania, May 2003,
                available at http://einstein.seas.upenn.edu/mnlab/
                publications.html.
 [TBA01]        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.
 [Thom02]       M. Thomas, "Analysis of Mobile IP and RSVP
                Interactions", Work in Progress, October 2002.
 [Tsch03]       H. Tschofenig, "RSVP Security Properties", Work in
                Progress, February 2004.
 [ZDSZ93]       L. Zhang, S. Deering, D. Estrin, and D. Zappala,
                "RSVP: A New Resource Reservation Protocol", IEEE
                Network, Volume 7, Pages 8-18, September 1993.
 [URL1]         http://www.atm.tut.fi/list-archive/diffserv/thrd3.html
 [URL2]         OPENSIG http://comet.columbia.edu/opensig/
 [URL3]         SIGLITE http://www1.cs.columbia.edu/~pingpan/projects/
                siglite.html

Manner & Fu Informational [Page 43] RFC 4094 Analysis of QoS Signaling May 2005

Authors' Addresses

 Jukka Manner
 Department of Computer Science
 University of Helsinki
 P.O. Box 68 (Gustav Hallstrominkatu 2b)
 FIN-00014 HELSINKI
 Finland
 Phone: +358-9-191-51298
 Fax:   +358-9-191-51120
 EMail: jmanner@cs.helsinki.fi
 Xiaoming Fu
 Institute for Informatics
 Georg-August-University of Goettingen
 Lotzestrasse 16-18
 37083 Goettingen
 Germany
 Phone: +49-551-39-14411
 Fax:   +49-551-39-14403
 EMail: fu@cs.uni-goettingen.de

Manner & Fu Informational [Page 44] RFC 4094 Analysis of QoS Signaling May 2005

Full Copyright Statement

 Copyright (C) The Internet Society (2005).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Manner & Fu Informational [Page 45]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4094.txt · Last modified: 2005/05/25 18:19 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki