Internet Engineering Task Force J. Manner (ed.)
Internet-Draft X. Fu (ed.)
Expires: August, 2003
February, 2003
Analysis of Existing Quality of Service Signaling Protocols
<draft-ietf-nsis-signalling-analysis-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
This Internet-Draft will expire in August, 2003.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
All comments to this work should be directed to the NSIS mailing at
nsis@ietf.org.
Abstract
This document presents a review of existing protocols for signalling
the Quality of Service requirements of flows to nodes in an IP
network. Protocols are reviewed independently and not compared
against the NSIS requirements document nor to RSVP itself. The
purpose is to learn from existing work and to avoid common
misconceptions about the protocols. A further goal is to avoid to
redesign ideas already implemented in another protocol.
Manner et al Expires August 2003 [Page 1]
Internet-Draft Analysis of QoS Signaling February 2003
Changes since -00
- More text on RFC2207, 2961, 3175, 3209,
- Added [Berg02], [KoRe02], [LiPe02], RFC2379, 2380 and extensions
proposed by ITU-T, OIF, 3GPP,
- Re-wrote text on RSVP processing overhead,
- Updated text on RSVP security,
- Removed section on ITSUMO as it was mostly an architectural
discussion, rather than a protocol review,
- Updates various other parts of the document based on feedback,
- Re-structured the document.
TODO items
- Evaluate the rest of the protocols in more depth
- Add more protocols? Remove protocols?
Table of Contents
1 Introduction ................................................. 3
2 The Resource Reservation Protocol ............................ 4
2.1 Extensions to RSVP ......................................... 5
2.2 Reservation functionality .................................. 11
2.3 Processing Overhead ........................................ 12
2.4 Bandwidth Consumption ...................................... 13
2.5 Mobility Support ........................................... 14
2.6 Security ................................................... 15
2.7 Deployment Issues .......................................... 15
2.8 Conclusions ................................................ 16
3 YESSIR ....................................................... 17
3.1 Reservation Functionality .................................. 17
3.2 Processing Overhead ........................................ 18
3.3 Bandwidth Consumption ...................................... 18
3.4 Mobility Support ........................................... 18
3.5 Security ................................................... 18
3.6 Deployment Issues .......................................... 18
3.7 Conclusions ................................................ 18
4 Boomerang .................................................... 18
4.1 Reservation Functionality .................................. 19
4.2 Processing Overhead ........................................ 19
4.3 Bandwidth Consumption ...................................... 19
4.4 Mobility Support ........................................... 19
4.5 Security ................................................... 19
4.6 Deployment Issues .......................................... 19
4.7 Conclusions ................................................ 20
5 INSIGNIA ..................................................... 20
6 BGRP ......................................................... 21
7 ST-II ........................................................ 21
8 Summary ...................................................... 21
9 Security Considerations ...................................... 22
10 Contributors ................................................ 22
11 Acknowledgment .............................................. 22
12 References .................................................. 22
13 Author's Addresses .......................................... 26
Manner et al Expires August 2003 [Page 2]
Internet-Draft Analysis of QoS Signaling February 2003
1. Introduction
The aim of this document is to present existing mature protocols for
signalling the Quality of Service (QoS) requirements of flows to
nodes in an IP network. The various protocols are reviewed
independently and without comparing against the NSIS requirements
document, because the protocols have already been designed before the
work on present requirements was initialized. Neither do we want to
make any comparison of protocols against RSVP because this would be
of little value - all protocols have their own research backgrounds
and targets and therefore do things differently. We also hope that
the NSIS Working Group can learn from existing work and we can avoid
common misconceptions about the protocols. A further goal is to avoid
to redesign ideas already implemented in an existing protocol.
There have been a number of historic attempts in delivering QoS or
generic signaling into the Internet. In the early years, multicast
was believed to be going to be popular to majority of communications,
hence RSVP and earlier ST-II were designed in a way which is
multicast-oriented. ST-II was developed as a reservation protocol for
point-to-multipoint communication. However, since it is sender-
initiated, it does not scale with the number of receivers in a
multicast group. It is complex and since every sender needs to set up
its own reservation, the total amount of reservation states is large.
RSVP was then designed to provide support for multipoint-to-
multipoint reservation setup in a more efficient way, however its
complexity, scalability and ability to meet new requirements have
been criticized.
YESSIR [PaSc98] and Boomerang [FNM+99] are examples of protocols
designed after RSVP. Both protocols were meant to be simpler than
RSVP. YESSIR is an extension to RTCP, while Boomerang is used with
ICMP.
Previously, there has been a lot of work targeted at creating a new
signalling protocol for resource control. Istvan Cselenyi suggested
to request for QoSSIG BOF in IETF#47 (http://www-nrg.ee.lbl.gov/diff-
serv-arch/msg05055.html), for identifying problems in QoS signaling,
but failed. Some people argued, "in many ways, RSVP improved upon
ST-2, and it did start out simpler, but resulting a design with
complexity and scalability", while some others thought it is "new
knowledge and requirements" that made RSVP insufficient (http://www-
nrg.ee.lbl.gov/diff-serv-arch/msg05066.html), and there is no simpler
way to handle the same problem as RSVP.
Michael Welzl organized a special session "ABR to the Internet" in
SCI 2001, and gathered some inputs for requesting an "ABR to the
Internet" BOF in IETF#51, which was intended to introduce explicit
rate feedback related mechanisms for the Internet (e2e, edge2edge)
but failed because of "missing community interest"
(http://www.tk.uni-linz.ac.at/~michael/abr-internet/).
OPENSIG (http://comet.columbia.edu/opensig/) has been involved in the
Internet signaling for years. Ping Pan initiated a SIGLITE
Manner et al Expires August 2003 [Page 3]
Internet-Draft Analysis of QoS Signaling February 2003
(http://www.cs.columbia.edu/~pingpan/projects/siglite.html) BOF
mailing list to investigate light-weight Internet signaling. Finally,
NSIS BOF was successful and the NSIS WG was formed.
The most mature and original protocols are presented in their own
sections and other QoS signalling protocols are presented in later
subsections.
2. The Resource Reservation Protocol
RSVP (the Resource Reservation Protocol) [RSVP] [RFC2205] [BEBH96]
has evolved from ST-II to provide end-to-end QoS signaling services
for application data streams. Hosts use RSVP to request a specific
quality of service (QoS) from the network for particular application
flows. Routers use RSVP to deliver QoS requests to all routers along
the data path. RSVP also can maintain and refresh states for a
requested QoS application flow. This section shortly reviews the RSVP
basic model and its extensions.
RSVP tries to be well-fit in the Integrated Services (IntServ)
[RFC2210], [BEBH96] architecture with certain modularity and
scalability. The design of the RSVP protocol distinguished itself by
a number of fundamental ways, particularly, soft state management,
two-pass signaling message exchanges, receiver-based resource
reservation and separation of QoS signaling from routing.
RSVP Signaling Model: The RSVP signaling model is based on a special
handling of multicast. The sender of a multicast flow advertises the
traffic characteristics periodically to the receivers via "Path"
messages. On receipt of an advertisement, a receiver may generate a
"Resv" message to reserve resources along the flow path from the
sender. Receiver reservations may be heterogeneous. To accommodate
the multipoint-to-multipoint multicast applications, RSVP was
designed to support a vector of reservation attributes called the
"style". A style describes whether all senders of a multicast group
share a single reservation and which receiver is applied. The "Scope"
object additionally provides the explicit list of senders.
Soft State: Because the number of receivers in a multicast flow is
likely to change, and the flow of delivery paths might change during
the life of an application flow, RSVP takes a soft-state approach in
its design, creating and removing the protocol states (Path and Resv
states) in routers and hosts incrementally over time. RSVP sends
periodic refresh messages (Path and Resv) to maintain its states and
to recover from occasional lost messages. In the absence of refresh
messages, the RSVP states automatically time out and are deleted.
States may also be deleted explicitly by PathTear, PathErr with
Path_State_Removed flag, or ResvTear Message.
Two-pass Signaling Message Exchanges: The receiver in an application
flow is responsible for requesting the desired QoS from the sender.
To do this, the receiver issues an RSVP QoS request on behalf of the
local application. The request propagates to all routers in reverse
Manner et al Expires August 2003 [Page 4]
Internet-Draft Analysis of QoS Signaling February 2003
direction of the data paths toward the sender. In this process, RSVP
requests might be merged, resulting in a protocol that scales well
when there are a large number of receivers.
Receiver-based Resource Reservation: Receiver-initiation is critical
for RSVP to setup multicast sessions with a large number of
heterogeneous receivers. A receiver initiates a reservation request
at a leaf of the multicast distribution tree, traveling toward the
sender. Whenever a reservation is found to already exist in a node in
the distribution tree, the new request will be merged with the
existing reservation. This could result in fewer signalling
operations for the RSVP nodes in the multicast tree close to the
sender, but introduce a restriction to receiver-initiation.
Separation of QoS Signaling from Routing: RSVP messages follow normal
IP routing. RSVP is not a routing protocol, but rather is designed to
operate with current and future unicast and multicast routing
protocols. The routing protocols are responsible for choosing the
routes to use to forward packets, and RSVP consults local routing
tables to obtain routes. RSVP is responsible only for reservation
setup along a data path.
RFC 2205 defines 7 types of standard RSVP messages (Path, PathTear,
PathErr, Resv, ResvErr, ResvTear, ResvConf) and a number of
objects/object classes (SESSION, RSVP_HOP, INTEGRITY, TIME_VALUES,
ERROR_SPEC, SCOPE List, STYLE, FLOWSPEC, FILTERSPEC, SENDER_TEMPLATE,
IPv6 Flow-label SENDER_TEMPLATE, SENDER_TSPEC, ADSPEC, POLIY_DATA,
RESV_CONFIRM). A detailed description of their definition and
processing is given in [RFC2205].
2.1. Extensions to RSVP
Note: only IETF Standards Track RFCs and a limited set of other
organizations' specifications are discussed below; informational RFCs
(e.g., RFC2998) and work-in-progress I-Ds (e.g., proxy) are not
covered here.
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.
[RFC2750] specifies the format of POLICY_DATA objects and RSVP
handling of policy events. RFC 2750 introduces objects which are
interpreted only by policy aware nodes (PEPs) which interact with
policy decision points (PDPs). Nodes which are unable to interpret
the POLICY_DATA objects are called policy ignorant nodes (PINs). The
content of the POLICY_DATA object itself is protected only between
PEPs and therefore provides end-to-middle or middle-to-middle
security.
Manner et al Expires August 2003 [Page 5]
Internet-Draft Analysis of QoS Signaling February 2003
[RFC2749] specifies the usage of COPS policy services in RSVP
environments. [RFC2751] specifies a preemption priority policy
element (PREEMPTION_PRI) for use by RSVP POLICY_DATA Object. [Hame02]
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.
[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.
[RFC2746] describes an IP tunneling enhancement mechanism that allows
RSVP to make reservations across all IP-in-IP tunnels, basically, by
way of recursively applying RSVP over the tunnel portion of the path.
[RFC2961] describes mechanisms to reduce processing overhead
requirements of refresh messages, eliminate the state synchronization
latency incurred when an RSVP message is lost and, refreshing state
without the transmission of whole refresh messages. It defines the
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 message, which consists of a bundle header followed by a
body consisting one or more standard RSVP messages. Bundle messages
help in scaling RSVP in reducing processing overhead and bandwidth
consumption.
2) ACK message, which carries one or more MESSAGE_ID_ACK or
MESSAGE_ID_NACK objects. ACK messages are sent between neighboring
RSVP nodes to detect message loss and support reliable RSVP message
delivery on a per hop basis.
3) Srefresh message, which carries one or more MESSAGE_ID LIST,
MESSAGE_ID SRC_LIST and MESSAGE_ID MCAST_LIST objects. correspondent
to Path and Resv messages that establish the states. Srefresh
messages are used to refresh RSVP states without transmitting
standard Path or Resv messages.
Manner et al Expires August 2003 [Page 6]
Internet-Draft Analysis of QoS Signaling February 2003
[RFC3175] allows to install one or more aggregated reservations in an
aggregation region, thus the number of individual RSVP sessions can
be reduced. The protocol type is swapped from RSVP to RSVP-E2E-IGNORE
in E2E (standard) Path, PathTear and ResvConf messages when they
enter the aggregation region, and swapped back when they leave. In
addition to a new PathErr code (NEW_AGGREGATE_NEEDED), three new
objects are introduced:
1) SESSION object, which contains two values: the IP Address of the
aggregate session destination, and the DSCP that it will use on the
E2E data the reservation contains.
2) SENDER_TEMPLATE object, which identifies the aggregating router
for the aggregate reservation.
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 signalling and the handling of data
packets in the aggregation region, these cases are equivalent to the
case of aggregating E2E RSVP reservations. The only difference is
that E2E RSVP signalling does not take place and cannot therefore be
used as a trigger, so some additional knowledge is required in
setting up the aggregate reservation.
RSVP-TE [RFC3209] specifies the extension to RSVP for establishing
explicitly routed LSPs in MPLS networks using RSVP as a signaling
protocol. RSVP-TE is intended for use by label switching routers (as
well as hosts) to establish and maintain LSP-tunnels and to reserve
network resources for such LSP-tunnels. RFC3209 defines a new Hello
message (for rapid node failure detection), new C-Types
(LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6) for the SESSION (here a session
is implicitly defined as the set of packets that are assigned the
same MPLS label value at the originating node of an LSP-tunnel),
SENDER_TEMPLATE, and FILTER_SPEC objects, and the following 5 new
objects:
1) EXPLICIT_ROUTE object (ERO), which is incorporated into RSVP Path
messages, encapsulating a concatenation of hops which constitutes
the explicitly routed path. Using this object, the paths taken by
label-switched RSVP-MPLS flows can be pre-determined, independent
of conventional IP routing.
2) LABEL_REQUEST object. To establish an LSP tunnel, the sender can
create a Path message with a LABEL_REQUEST object. A node that
sends a LABEL_REQUEST object MUST be ready to accept and correctly
process a LABEL object in the corresponding Resv messages.
3) LABEL object. Each node that receives a Resv message containing a
LABEL object uses that label for outgoing traffic associated with
this LSP tunnel.
4) SESSION_ATTRIBUTE object, which can be added to Path messages to
Manner et al Expires August 2003 [Page 7]
Internet-Draft Analysis of QoS Signaling February 2003
aid in session identification and diagnostics. Additional control
information, such as setup and hold priorities, resource
affinities and local-protection, are also included in this object.
5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object may appear in
both Path and Resv messages. It is used to collect detailed path
information and is useful for loop detection and for diagnostics.
Section 5 of RFC3270 further specifies the extensions to RSVP to
establish LSPs supporting DiffServ in MPLS networks, introducing a
new DIFFSERV Object (applicable in the Path messages) and using pre-
configured or (e.g. RFC3270) signaled "EXP<-->PHB mapping".
GMPLS RSVP-TE [Berg02] defines a Notify message (for general event
notification), which may contain notifications being sent, with
respect to each listed session, both upstream and downstream. Notify
messages can be used together with Notify Request object for
expedited notification of failures and other events to nodes
responsible for restoring failed LSPs. A Notify message is sent
without the router alert option. Besides, a number of new RSVP-TE
(sub)objects are defined in GMPLS RSVP-TE for general uses of MPLS:
(for label management:)
- a Generalized Label Request Object;
- Bandwidth Encoding carried in SENDER_TSPEC and FLOWSPEC objects,
Generalized Label Object;
- a Waveband Switching Object;
- a Suggested Label Object;
- a Label Set Object; (to support bidirectional LSP setup:)
- an Upstream_Label object; (to support uni- and bi-directional
Explicit Label Control:)
- a Label ERO subobject;
- a Label RRO subobject, which is included in RROs as described in
[RFC3209]; (To Control Channel Separation:)
- IF_ID RSVP_HOP objects (IPv4 & v6);
- IF_ID ERROR_SPEC objects (IPv4 & v6); (to support rapid failure
notification:)
- a Acceptable Label Set object to support Notification on Label
Error;
- a Notify Request object, which may be inserted in Path or Resv
messages to indicate where a notification of LSP failure is to be
sent; (for fault handling:)
- a Restart_Cap Object; (for administrative purposes:)
- an Admin Status Object, which is used to notify each node along the
path of the status of the LSP.
Since RSVP-TE does not provide a way to indicate an unnumbered link
in its Explicit Route and Record Route Objects, [KoRe02] specifies
extensions to RSVP-TE to support (point-to-point) unnumbered links,
namely,
- an Unnumbered Interface ID Subobject, which is a new subobject of
the Explicit Route Object (ERO) used to specify unnumbered links;
- an LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to
Manner et al Expires August 2003 [Page 8]
Internet-Draft Analysis of QoS Signaling February 2003
form or use an identifier for the Forwarding Adjacency;
- a new subobject of the Record Route Object, used to record that the
LSP path traversed an unnumbered link.
[LiPe02] proposes additional extensions to GMPLS RSVP-TE to support
the capabilities of an Automatically Switched Optical Network (ASON,
an architecture developed by ITU-T SG15). To support Soft Permanent
Connection (SPC), it uses GENERALIZED_UNI object defined by [OIF-
UNI-1.0] but introduces a new subtype: SPC_LABEL. In addition, a Call
identifier (CALL_ID) object is used in logical call/connection
separation, which are used together with a new Call capability
(CALL_OPS) object for complete call/connection separation. Besides
new error codes, 3 new C-types are defined for the SESSION object:
UNI_IPv6 SESSION, ENNI_IPv4 SESSION and ENNI_IPv6 SESSION.
Optical Internetworking Forum (OIF) UNI 1.0 signaling ([OIF-UNI-1.0])
supports [RFC2205, RFC2961, RFC3209, Berg02] in a limited way. 10
types of RSVP(-TE) messages are supported, but used in a slightly
different way. For example, only FF style is supported; States are
always deleted explicitly; a state timer expiration will not deleted
the state, rather triggers a tear down message; any RSVP message must
be dropped silently when fails security validation. Besides new
error codes, a few new (sub)objects are introduced, including:
- a new C-type for ACCEPTABLE_LABEL_SET [Berg02];
- a new C-type for ADMIN_STATUS [Berg02];
- a new C-type for LABEL_SET [Berg02];
- a new C-type for RECOVER_LABEL [Berg02];
- a new C-type for RESTART_CAP [Berg02];
- a new C-type for UPSTEAM_LABEL [Berg02];
- a UNI_IPv4_SESSION object, combined with
LSP_TUNNEL_IPv4_SENDER_TEMPLATE object to uniquely identify a
connection at a local UNI;
- a GENERALIZED_LABEL_REQUEST object;
- a GENERALIZED_UNI_ATTRIBUTES object, which contains one or more new
SOURCE_TNA, DESTINATION_TNA, DIVERSITY, EGRESS_LABEL, SERVICE_LEVEL
subobjects. EGRESS_LABEL can be used to specify either uni- or
bi-directional connections;
- a SONET/SDH_SENDER_TSPEC object.
IETF ([RFC2379][RFC2380]) also defines RSVP over ATM implementation
guidelines and requirements to interwork with the ATM (Forum) UNI
3.x/4.0. [RFC2380] states that the RSVP (control) messages and RSVP
associated data packets must not be sent on the same VCs, and an
explicit release of RSVP associated QoS VCs must be performed once
the VC for forwarding RSVP control messages terminated. While a
separate control VC is also possible for forwarding RSVP control
messages, [RFC2379] recommends to create a best-effort short-cut (a
short-cut is a point-to-point VC where the two end-points locate in
different IP subnets) first (if not exist), which can allow setting
up RSVP triggered VCs to use the best-effort end-point. For data
flows, the subnet senders must establish all QoS VCs and the RSVP
enabled subnet receiver must be able to accept incoming QoS VCs. RSVP
must request the configurable inactivity timers of VCs be set to
Manner et al Expires August 2003 [Page 9]
Internet-Draft Analysis of QoS Signaling February 2003
"infinite", and if it is too complex to do this at the VC receiver,
RSVP over ATM implementations are required not to use an inactivity
timer to clear any received connections. In case of dynamic QoS, the
replacement of VC should be done gracefully.
ITU-T H.323 ([H.323]) recommends the IntServ resource reservation
procedure using RSVP. The information whether an endpoint supports
RSVP should be conveyed during the H.245 capability exchange phase,
by setting appropriate qOSMode fields. If both endpoints are RSVP-
capable, when opening an H.245 logical channel, a receiver port ID
should be conveyed to the sender by the openLogicalChannelAck
message. Only after that, can a "Path - Resv - ResvConf" process take
place. The timer of waiting for ResvConf message will be set by the
endpoint. The action in case of this timer expires, as well as RSVP
reservation fails in any point during an H.323 call, is up to the
vendor to take. Once a ResvConf message is sent or received, the
endpoints should stop reservation timers and resume with the H.323
call procedures. Only explicit release of reservations are supported
in [H.323]: before sending a closeLogicalChannel message for a
stream, a sender should send a PathTear message if an RSVP session
has been previous created for that stream; after receiving a
closeLogicalChannel, a receiver should send a ResvTear similarly.
Only the FF style is supported, even for point-to-multipoint calls.
3GPP TS 23.207 ([3GPP-TS23207]) specifies the QoS signaling procedure
with policy control within the UMTS end-to-end QoS architecture. When
using RSVP, the signaling source and/or destination are the User
Equipments (UEs, devices that allow users access to network services)
that locate in the Mobile Originating (MO) side and the Mobile
Terminating (MT) side, and an RSVP signaling process can either
trigger or be triggered by the (COPS) PDP Context
establishment/modification process. The operation of refreshing
states is not specified in [3GPP-TS23207]. If bidirectional
reservation is needed, the RSVP signaling should be proceeded twice
between the signaling source and the destination. The authorization
token and flow identifier(s) in a policy data object should be
included in the RSVP messages sent by the UE, if the token is
available in the UE. When both RSVP and Service-based Local Policy
are used, the Gateway GPRS Support Node (GGSN, the access point of
the network) should use the policy information to decide whether to
accept and forward Path/Resv messages.
In summary, in various RSVP extensions, new message type ("RSVP-E2E-
IGNORE") for RSVP Path, PathTear and ResvConf messages, at least 7
new RSVP message types (DREQ, DREP, Bundle, Ack, Srefresh, Hello,
Notify) and numerous new RSVP objects (e.g., new objects for
FILTER_SPEC, SESSION, and SENDER_TEMPLATE; LAN_NHOP RSVP_HOP_L2;
MESSAGE_ID, MESSAGE_ID_ACK, MESSAGE_ID_NACK, MESSAGE_ID LIST,
MESSAGE_ID SRC_LIST, MESSAGE_ID MCAST_LIST; ERO, RRO, LABEL_REQUEST,
LABEL, SESSION_ATTRIBUTE; DIFFSERV; Generalized Label Request,
Waveband Switching, Suggested Label, Label Set, Upstream_Label, Label
ERO, Label RRO, IF_ID RSVP_HOP, IF_ID ERROR_SPEC, Acceptable Label
Set, Notify Request, Restart_Cap, Admin Status;
LSP_TUNNEL_INTERFACE_ID; GENERALIZED_UNI, SONET/SDH_SENDER_TSPEC;
Manner et al Expires August 2003 [Page 10]
Internet-Draft Analysis of QoS Signaling February 2003
various new subobjects) have been defined.
o RFC2205 + policy_data (policy control + security) + RFC2961 (as a
critical extension) being regarded as "De facto Standard RSVP".
o Diagnostics messages, aggregation, (proxy,) DCLASS, operations over
IP-in-IP tunnels, ATM, 802.x and ITU-T ASON networks have been
defined.
o RSVP-TE extends RSVP mainly by introducing Label Request, Explicit
Routing, and Refresh Reduction (esp. local Acknowledgment).
o GMPLS RSVP-TE extends RSVP-TE mainly by introducing new label/path
types (Generalized Label Request TLV), new transport requirements
(new TSPEC format) and bidirectional reservation (Upstream Label
TLV).
o OIF UNI-1.0 extends GMPLS RSVP-TE by adding new signaling objects
used for optical networks.
2.2. Reservation functionality
RSVP carries QoS signalling 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.
The definition of the required resources is not part of the RSVP
standard, but commonly the IntServ specifications for Controlled Load
and Guaranteed Services are used. RSVP allows for unicast and
multicast reservations. Various filtering rules may be used to
identify flows belonging to a reservation - commonly the 5-tuple is
used. RFC 2207 [RFC2207] specifies an RSVP extension to use the IPsec
SPI (Security Parameter Index), in place of the UDP/TCP-like ports.
The IPv6 Flow Label can also be used as a key in the filters.
Furthermore, reservations may be distinct or shared by several
senders.
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.
For some applications, service parameters are specified by the
Manner et al Expires August 2003 [Page 11]
Internet-Draft Analysis of QoS Signaling February 2003
network, not by the application (e.g. ERP applications). The Null
Service [RFC2997] allows applications to identify themselves to
network QoS policy agents using RSVP signaling, but does not require
them to specify resource requirements. QoS policy agents in the
network respond by applying QoS policies appropriate for the
application (as determined by the network administrator). The RSVP
sender offers the new service type, 'Null Service Type' in the ADSPEC
that is included with the PATH message. A new TSPEC corresponding to
the new service type is added to the SENDER_TSPEC. In addition, the
RSVP sender will typically include with the PATH message policy
objects identifying the user, application and sub-flow, which will be
used for network nodes to manage the correspondent traffic flow.
2.3. Processing Overhead
By processing overhead we mean the amount of processing required to
handle messages belonging to a reservation session. This is the
processing required in addition to the processing needed for routing
an (ordinary) IP packet. The processing overhead of RSVP originates
from two major issues:
1) Complexity of the protocol elements. First, RSVP itself is
per-flow based, thus the number of states is proportional to RSVP
session number. Path and Resv states have to be maintained in each
RSVP router for each session (and Path state also record the
reverse route for the correspondent Resv message). Second, being
receiver-initiated, RSVP optimizes various merging operations for
multicast reservations while the Resv message is processed. To
handle multicast, other mechanisms like reservation styles, scope
object, and blockade state, are also required to present in the
basic protocol. This not only adds sources of failures and errors,
but also complicates the state machine. Third, the same RSVP
signaling messages are not only used for maintaining the state, but
also dealing with recovery of signaling message loss and discovery
of route change. Thus, although protocol elements that represent
the actual data (e.g., QoS parameters) specification are separated
from signalling elements, the processing overhead needed for all
RSVP messages is not marginal. Finally, the possible variations of
the order and existence of objects increases the complexity of
message parsing and internal message and state representation.
(Editor's note, XF: ref. current discussion on layer-splitting?
mainly regards to rethinking of RSVP if splitting different tasks
into two layers. E.g., functions like congestion control and
reliability may be challenged by current RSVP.)
2) Implementation-specific Overhead. There are two ways to send and
receive RSVP messages, either as "raw" IP datagrams with protocol
number 46, or as encapsulated UDP datagrams, the latter of which
increase the efficiency of RSVP processing. Typical RSVP
implementations are user-space daemons interacting with the
kernel, hence state management, message sending and reception
would affect the efficiency of the protocol processing. For
Manner et al Expires August 2003 [Page 12]
Internet-Draft Analysis of QoS Signaling February 2003
example, in the recent version of the implementation described in
[Kars01], the relative execution costs for message
sending/reception system calls "sendto", "select", "recvmsg" were
14-16%, 6-7%, 9-10%, individually, of the total execution cost;
[Kars01] also found that state (memory) management can use up to
17-18% of the total execution cost, but it is possible to decrease
that cost to 6-7%, if appropriate action is taken to replace the
standard memory management with dedicated memory management for
state information. RSVP/routing, RSVP/policy control, and
RSVP/traffic control interfaces can also pose different overhead
dependent on implementation. For example, the RSVP/routing
overhead has been measured to be approximately 11-12% of the total
execution cost [Kars01].
2.4. Bandwidth Consumption
By bandwidth consumption we mean the amount of bandwidth used to
during the lifetime of a session: set up a reservation session, keep
the session alive, and finally close it.
RSVP messages are sent either to trigger a new reservation or refresh
an existing reservation. In standard RSVP, Path/Resv messages are
used for triggering and refreshing/recovering reservations,
identically, which results in an increased size of refresh messages.
The hop-by-hop refreshment may reduce the bandwidth consumption for
RSVP, but could result in more sources of error/failure events.
[RFC2961] presents a way to bundle standard RSVP messages and reduces
the refreshment redundancy by Srefresh message.
Thus, the signalling for an RSVP session uses for a session lasting n
seconds:
F(n) = (bP + bR) + ((n/Ri) * (bP + bR)) + bPt ,where
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 the bandwidth consumption
would be (bP is 172 bytes, bR is 92, and bPt is 44 bytes and Ri is 30
seconds):
F(n): (172 + 92) + (n/30) * (172 + 92)) + 44 = 308 + (264n/30) bytes
(Editor's note: Same values could be calculated for other protocols?
Would these be of any use?)
Manner et al Expires August 2003 [Page 13]
Internet-Draft Analysis of QoS Signaling February 2003
2.5. Mobility Support
Two issues raise concern when RSVP is used by a mobile node (MN): the
flow identifier and reservation refresh. When an MN changes
locations, it may need to change one of its assigned IP address. An
MN may have an IP address by which it is reachable by nodes outside
the access network and an IP address used to support local mobility
management. Depending on the mobility management mechanism, a
handover may force a change in any of these addresses. As a
consequence the filters associated with a reservation may not
identify the flow anymore and the resource reservation is
ineffective, until a refresh with a new set of filters is
initialized.
The second issue is about following the movement of a mobile node.
RFC2205 defines that Path messages can perform a local repair of
reservation paths. When the route between the communicating end hosts
changes, a Path message will set the state of the reservation on the
new route and a subsequent Resv message will make the resource
reservation. Therefore, by sending a Resv message a host cannot alone
update the reservation, and thus perform a local repair, before a
Path message has passed. Also, in order to provide fast adaptation to
routing changes without the overhead of short refresh periods, the
local routing protocol module can notify the RSVP process of route
changes for particular destinations. The RSVP process should use this
information to trigger a quick refresh of state for these
destinations, using the new route (Chapter 3.6, RFC2205). However,
not all local mobility protocols, or even Mobile IP, affect routing
directly in routers, and thus mobility may not be noticed at RSVP
routers. Thus, it may take a relatively long time before a
reservation is refreshed following a handover.
There have been several designs for extensions to RSVP to allow for
more seamless mobility. One solution is presented in [MSK+03], which
discusses in one section the coupling of RSVP and the mobility
management mechanisms and proposes small extensions to RSVP to better
handle the handover event, among other things. The extension allows
the mobile host to request a Path for the downstream reservation when
a handover has happened.
Another example is Mobile RSVP (MRSVP) [MRSVP], which is an extension
to standard RSVP. It is based on advance reservations, where
neighboring access points keep resources reserved for mobile nodes
moving to their coverage area. When a mobile node requests resources,
the neighboring access points are checked too and a passive
reservation is done around the mobile nodes current location.
The problem with the various 'advance reservation' schemes is that
they require topological information of the access network and
usually advance knowledge of the handover event. Furthermore, the way
the resource reserved in advance are used in the neighboring service
areas is an open issue. A good overview of these different schemes
can be found in [MA01].
Manner et al Expires August 2003 [Page 14]
Internet-Draft Analysis of QoS Signaling February 2003
The interactions of RSVP and Mobile IP have been well documented in
[Thom02].
2.6. Security
To allow a process on a system to securely identify the owner and the
application of the communicating process (e.g. user id) and convey
this information in RSVP messages (PATH or RESV) in a secure manner,
[RFC2752] specifies the encoding of identities as RSVP POLICY_DATA
Object. However, to provide iron-clad security protection
cryptographic authentication combined with authorization has to be
provided. Such a functionality is typically offered by authentication
and key exchange protocols. Solely including a user identifier is
insufficient.
To provide hop-by-hop integrity and authentication of RSVP messages,
RSVP message may contain an INTEGRITY object ([RFC2747]) using a
keyed message digest. Since intermediate routers need to modify and
process the content of the signaling message a hop-by-hop security
architecture based on a chain-of-trust is used. However, with the
different usage of RSVP as described throughout this document and
with new requirements a re-evaluation of the original assumptions
might be necessary.
This provides protection against forgery and message modification.
However this does not provide non-repudiation and protect against
message deletion. In current RSVP security scheme, the two-way peer
authentication and key management procedures are still missing.
The security issues have been well analyzed in [Tsch02].
2.7. Deployment Issues
As a well-acknowledged protocol in the Internet, RSVP is being more
and more expected to provide a more generic service for various
signaling applications. However, RSVP messages were designed in a way
to optimally support end-to-end QoS signaling. To meet with the
increasing demand for a signaling protocol to also operate in host-
to-edge and edge-to-edge ways, and serve for some other signaling
purposes in addition to end-to-end QoS signaling, RSVP needs to be
developed more flexible and applicable for more generic signaling.
RSVP proxies [BEGD02] extends RSVP by being able to originates or
receive the RSVP message on behalf of the end node(s), so that
applications may still benefit from reservations that are not truly
end-to-end. However, there are certainly scenarios where an
application would want to explicitly convey its non-QoS purposed (as
well as QoS) data from a host into the network, or from an ingress
node to an egress node of an administrative domain, but it must do so
without burdening the network with excess messaging overhead. Typical
examples are an end host desiring a firewall service from its
provider's network and MPLS label setup within an MPLS domain.
Manner et al Expires August 2003 [Page 15]
Internet-Draft Analysis of QoS Signaling February 2003
RSVP requires support from network routers and user space
applications. Domains not supporting RSVP are traversed
transparently. Unfortunately, like other IP options, RSVP messages
implemented by way of IP alert option may result in themselves being
dropped by some routers [FrJo02]. Although applications need to be
built with RSVP libraries, one article presents a mechanism that
would allow any host to benefit from RSVP mechanisms without
applications awareness [MHS02].
A somewhat similar deployment benefit can be gained from the
Localized RSVP [MSK+03]. The draft presents the concept of local
RSVP-based reservation that can be used to trigger reservation within
an access network alone. In those cases, an end-host may request QoS
from its own access network without the co-operation of a
correspondent node outside the access network - this would be
especially helpful when the correspondent node is unaware of RSVP. A
proxy node responds to the messages sent by the end host and enables
both upstream and downstream reservations. Furthermore, the scheme
allows for faster reservation repairs following a handover by
triggering the proxy to assist in an RSVP local repair.
Still, in end-hosts which are low in processing power and
functionality, having an RSVP daemon running and taking care of the
signalling may introduce unnecessary overhead. One article [Kars01]
proposes to create a remote API so that the daemon would in fact be
running on the end-host's default router and the end-host application
would send its requests to that daemon.
Another potential problem lies in the limited sized of signaled data
due to the limitation of message size. RSVP message must fit entirely
into a single non-fragmented IP datagram. Bundle messages [RFC2961]
can aggregate multiple RSVP messages within a single PDU, but still
only occupy one IP datagram (i.e., approximately 64K); if it exceeds
the MTU, the datagram is fragmented by IP and reassembled at the
recipient node.
2.8. Conclusions
The design of RSVP was originally targeted at multicast applications.
The result has been that the message processing within nodes is
somewhat heavy, mainly due to flow merging. Still, merging rules
should not appear in the specification as they are QoS-specific.
RSVP has a comprehensive set of filtering rules (WF,FF, shared) and
is not tied to certain QoS objects (RSVP is not tied to IntServ GS/CL
specifications). Objects were designed to be modular, but Xspecs
(TSPEC, etc) are more or less QoS-specific and should be more
generalized; there is no clear layering/separation between the
signaled data and signaling protocol.
RSVP uses a soft state mechanism to maintain states and allows each
node to define its own refresh timer. The protocol is also
independent of underlying routing protocols. Still, in mobile
Manner et al Expires August 2003 [Page 16]
Internet-Draft Analysis of QoS Signaling February 2003
networks the movement of the mobile nodes may not properly trigger a
reservation refresh for the new path and therefore a mobile node may
be left without a reservation up to the length of the refresh timer.
Furthermore, RSVP does not work properly with changing end-point
identifiers, that is, if one of the IP addresses of a mobile node
changes, the filters may not be able to identify the flow that had a
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, current RSVP security mechanism does not provide
non-repudiation and protection against message deletion; the two-way
peer authentication and key management procedures are still missing.
Finally, since the publication of the RSVP standard, tens of
extensions have emerged that allow for much wider deployment than
RSVP was originally designed for, as for instance, the Subnet
Bandwidth Manager, the NULL service type, aggregation, operation over
tunneling and MPLS as well as diagnostic messages.
Domains not supporting RSVP are traversed transparently by default.
Unfortunately, like other IP options, RSVP messages implemented by
way of IP alert option may result in themselves being dropped by some
routers. Also, the maximal size of RSVP message is limited.
3. YESSIR
YESSIR (YEt another Sender Session Internet Reservations) [PaSc98] is
a resource reservation protocol that seeks to simplify the process of
establishing reserved flows while preserving many unique features
introduced in RSVP. Simplicity is measured in terms of control
message processing, data packet processing, and user-level
flexibility. Features such as robustness, advertising network service
availability and resource sharing among multiple senders are also
supported in the proposal.
The proposed mechanism generates reservation requests by senders to
reduce the processing overhead. It is built as an extension to the
Real-Time Transport Control Protocol (RTCP), taking advantages of
Real-Time Protocol (RTP). YESSIR also introduces a concept called
partial reservation.
3.1. Reservation Functionality
YESSIR was designed for one-way, sender-initiated end-to-end resource
reservation. It also uses soft state to maintain states. It supports
resource query (similar to RSVP diagnosis message), advertising
(similar to RSVP ADSPEC), shared reservation, partial reservations
and flow merging.
To support multicast, YESSIR simplifies the reservation styles to
Manner et al Expires August 2003 [Page 17]
Internet-Draft Analysis of QoS Signaling February 2003
individual and shared reservation styles. Individual reservations are
made separately for each sender, whereas shared reservations allocate
resources that can be used by all senders in an RTP session. While
RSVP supports shared reservation (SE and WF styles) from the
receiver's direction, YESSIR handles the shared reservation style
from the sender's direction, thus new receivers can re-use the
existing reservation of the previous sender.
3.2. Processing Overhead
In [PaSc00], it was proved that YESSIR one-pass reservation model has
better performance and lower processing cost, comparing with a
regular two-way signaling protocol.
3.3. Bandwidth Consumption
The bandwidth consumption of YESSIR is somewhat lower than that of,
for example, RSVP, because it does not require additional IP and
transport headers. Bandwidth consumption is limited to the extension
header size.
3.4. Mobility Support
YESSIR does not have any particular support for mobility.
<TBD>
3.5. Security
The security of YESSIR relies on RTP/RTCP security measures.
3.6. Deployment Issues
YESSIR requires support in applications since it is an integral part
of RTCP. Similarly, it requires network routers to inspect RTCP
packets to identify reservation requests and refreshes. Routers
unaware of YESSIR forward the RTCP packets transparently.
3.7. Conclusions
<TBD>
4. Boomerang
Boomerang [FNM+99] is a another resource reservation protocol for IP
networks. The protocol has only one message type and a single
signaling loop for reservation set-up and tear-down, has no
Manner et al Expires August 2003 [Page 18]
Internet-Draft Analysis of QoS Signaling February 2003
requirements on the far end node, but, instead, concentrates the
intelligence in the Initiating Node (IN).
In addition, the Boomerang protocol allows for sender- or receiver-
oriented reservations and resource query. Flows are identified with
the common 5-tuple and the QoS can be specified with various means,
eg. service class and bit rate. Boomerang messages are in the initial
implementation transported in ICMP ECHO / REPLY messages.
4.1. Reservation Functionality
Boomerang can only be used for unicast sessions, no support for
multicast exists. The requested QoS can be specified with various
methods and both ends of a communication session can make a
reservation for their transmitted flow.
4.2. Processing Overhead
The authors of Boomerang show in [FNS02] that the processing of the
protocol is considerably lower than with the ISI RSVP daemon
implementation. However, this is mainly due to the limited
functionality provided by the protocol compared to RSVP.
4.3. Bandwidth Consumption
Boomerang messages are quite short and consume a relatively low
amount of link bandwidth. This is due to the limited functionality of
the protocol, for example, no security specific information or
policy-based interaction are provided. Being sender oriented, the
bandwidth consumption mostly affects the downstream direction, from
the sender to the receiver.
4.4. Mobility Support
As Boomerang is sender oriented, there is no need to store backward
information. This reduces the signalling required. The rest of the
issues that were identified with RSVP apply with Boomerang.
4.5. Security
No security mechanism is specified for Boomerang.
4.6. Deployment Issues
The Boomerang protocol has similar deployment issues as any host-
network-host protocol. It requires an implementation at both
communicating nodes and in routers. Boomerang-unaware routers should
be able to forward Boomerang messages transparently. Still, often
Manner et al Expires August 2003 [Page 19]
Internet-Draft Analysis of QoS Signaling February 2003
firewalls drop ICMP packets making the protocol useless.
4.7. Conclusions
Boomerang seems to be a very lightweight protocol and efficient in
its own scenarios. Still, the apparent low processing overhead and
bandwidth consumption results from the limited functionality. No
support for multicast or any security features are present which
allows for a different functionality than RSVP, which the authors
like to compare Boomerang to.
5. INSIGNIA
INSIGNIA [LGZC00] has been developed at the Columbia University and
is proposed as a very simple signaling mechanism for supporting QoS
in mobile ad-hoc networks. It avoids the need for separate signaling
by carrying the QoS signaling data along with the normal data in IP
packets using IP packet header options. This approach, known as "in-
band signaling" is proposed as more suitable in the rapidly changing
environment of mobile networks since the signaled QoS information is
not tied to a particular path. It also allows the flows to be
rapidly established and, thus, is suitable for short lived and
dynamic flows.
INSIGNIA aims to minimize signaling by reducing the number of
parameters that are provided to the network. It assumes that real-
time flows may tolerate some loss, but are very delay sensitive so
that the only QoS information needed is the required minimum and
maximum bandwidth.
The INSIGNIA protocol operates at the network layer and assumes that
link status sensing and access schemes are provided by lower layer
entities. The usefulness of the scheme depends upon the MAC layers
but this is undefined so that INSIGNIA can run over any MAC layer.
The protocol requires that each router maintains per-flow state.
The INSIGNIA system implicitly supports mobility. A near-minimal
amount of information is exchanged with the network. To achieve this,
INSIGNIA makes many assumptions about the nature of traffic that a
source will send. This may also simplify admission control and buffer
allocation. The system basically assumes that "real-time" will be
defined as a maximum delay and the user can simply request real-time
service for a particular quantity of traffic.
After handover, data that was transmitted to the old base station can
be forwarded to the new base station so that no data loss should
occur. However, there is no way to differentiate between re-routed
and new traffic so priority cannot be given to handover traffic, for
example.
INSIGNIA, however, (completely) lacks a security framework and does
not investigate how to secure signaled QoS data in ad-hoc network
Manner et al Expires August 2003 [Page 20]
Internet-Draft Analysis of QoS Signaling February 2003
where relatively weak trust or even no trust exists between the
participating nodes. Hence authorization and charging especially
might be a challenge. The security protection of in-band signaling is
costly since the data delivery itself experiences increased latency
if security processing is done hop-by-hop. Since the QoS signaling
information is encoded into the flow label and end-to-end addressing
is used, it is very difficult to provide security other than IPsec in
tunnel mode.
6. BGRP
Border Gateway Reservation Protocol (BGRP) [BGRP] is a signaling
protocol for inter-domain aggregated resource reservation for unicast
traffic. BGRP builds a sink tree for each of the stub domains. Each
sink tree aggregates bandwidth reservations from all data sources in
the network. BGRP maintains these aggregated reservations using soft
state and relies on Differentiated Services for data forwarding.
BGRP scales in terms of message processing load, state storage and
bandwidth. Since backbone routers only maintain the sink tree
information, the total number of reservations at each router scales
linearly with the number of Internet domains.
7. ST-II
ST-II [RFC1819] is an experimental resource reservation protocol
intended to provide end-to-end real-time guarantees over an internet.
It allows applications to build multi-destination simplex data
streams with a desired quality of service. ST-II consists of two
protocols: ST for the data transport and SCMP, the Stream Control
Message Protocol, for all control functions. ST is simple and
contains only a single PDU format that is designed for fast and
efficient data forwarding in order to achieve low communication
delays. SCMP packets are transferred within ST packets.
ST-II has no built-in soft states, thus requires that the network be
responsible for correctness. It is sender-initiated, and the overhead
for ST-II to handle group membership dynamics is higher than RSVP
[MESZ94].
ST-II does not provide security but RFC 1819 describes some objects
related to charging.
8. Summary
- Gather the good ideas from the protocols as a basis for the future
designs
- Note that extensive features and simplicity do not go hand-in-hand:
"if you want features, be prepared to pay for the cost".
Manner et al Expires August 2003 [Page 21]
Internet-Draft Analysis of QoS Signaling February 2003
9. Security Considerations
There are no security issues in this document. Individual protocols
include different levels of security issues and those are highlighted
in the relevant sections and references.
10. Contributors
This document is part of the work done in the NSIS Working Group. The
draft was initially written by Jukka Manner and Xiaoming Fu. Since
the first version, Martin Karsten has provided text about the
processing overhead of RSVP and Hannes Tschofenig has provided text
about various security issues in the protocols.
11. Acknowledgment
We would like to acknowledge Bob Braden and Vlora Rexhepi for their
useful comments.
12. References
[RFC1819] L. Delgrossi and L. Berger, Editors, Internet Stream
Protocol Version 2 (ST2) Protocol Specification - Version ST2+,
RFC 1819, August 1995.
[MESZ94] D. Mitzel, D. Estrin, S. Shenker, and L. Zhang, An
Architectural Comparison of ST-II and RSVP, INFOCOM'94.
[BEBH96] Braden, R., Estrin, D., Berson, S., Herzog, S. and D.
Zappala, "The Design of the RSVP Protocol", ISI Final Technical
Report, Jul 1996.
[RSVP] Zhang, L., Deering, S., Estrin, D. and D. Zappala, "RSVP: A
New Resource Reservation Protocol", IEEE Network, Volume 7, Pages
8-18, Sep 1993.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, Sep 1997.
[RFC2207] L. Berger and T. O'Malley, RSVP Extensions for IPSEC Data
Flows, RFC 2207, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
Speer, M., Braden, R. and B. Davie, "Integrated Services Operation
over Diffserv Networks", RFC 2998, November 2000.
[RFC2749] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R.
Manner et al Expires August 2003 [Page 22]
Internet-Draft Analysis of QoS Signaling February 2003
and A. Sastry, COPS usage for RSVP, RFC 2749, January 2000.
[RFC2750] Herzog, S., RSVP Extensions for Policy Control, RFC
2750, January 2000.
[RFC2751] Herzog, S., Signaled Preemption Priority Policy Element,
RFC 2751, January 2000.
[RFC2752] Yadav, S., et al., "Identity Representation for RSVP",
RFC 2752, January 2000.
[RFC2747] Baker, F., Lindell, B. and M. Talwar, RSVP Cryptographic
Authentication, RFC 2747, January 2000.
[RFC2380] Berger, L., RSVP over ATM Implementation Requirements,
RFC 2380, August 1998.
[RFC2814] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and M.
Speer, SBM (Subnet Bandwidth Manager): A Protocol for Admission
Control over IEEE 802-style Networks, RFC 2814, May 2000.
[RFC2745] Terzis, A., Braden B., S. Vincent, and L. Zhang, RSVP
Diagnostic Messages, RFC 2745, January 2000.
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang,
RSVP Operation Over IP Tunnels, RFC 2746, January 2000.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P. and F. Tommasi,
RSVP Refresh Reduction Extensions, RFC 2961, April 2001.
[RFC2996] Bernet, Y., Format of the RSVP DCLASS Object, RFC 2996,
November 2000.
[RFC2997] Bernet, Y., Smiht, A. and B. Davie, Specification of the
Null Service Type, RFC 2997, November 2000.
[RFC3175] F. Baker, C. Iturralde, F. Le Faucheur, B. Davie,
Aggregation of RSVP for IPv4 and IPv6 Reservations, RFC 3175,
September 2001
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
and G. Swallow, Extensions to RSVP for LSP Tunnels, RFC 3209,
December 2001.
[RFC3270] F. Le Faucheur (ed), L. Wu, and et al, Multi-Protocol
Label Switching (MPLS) Support of Differentiated Services, RFC
3270, May 2002.
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D.,
Deering, S., Handley, M. and V. Jacobson, "Protocol Independent
Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362,
June, 1998.
[Hame02] L-N. Hamer, B. Gage, B. Kosinski, and Hugh Shieh, Session
Manner et al Expires August 2003 [Page 23]
Internet-Draft Analysis of QoS Signaling February 2003
Authorization Policy Element, Internet Draft (in RFC editor
queue), Nov 2002. (draft-ietf-rap-rsvp-authsession-05.txt)
[Berg02] L. Berger (ed), Generalized MPLS Signaling - RSVP-TE
Extensions, Internet draft (in RFC editor queue), Sept. 2002.
(draft-ietf-mpls-generalized-rsvp-te-09.txt)
[KoRe02] K. Kompella, Y. Rekhter, Signalling Unnumbered Links in
RSVP-TE, Internet draft (in RFC editor queque), Oct. 2002.
(draft-ietf-mpls-rsvp-unnum-08.txt)
[LiPe02] Z. Lin, D. Pendarakis, Generalized MPLS (GMPLS) RSVP-TE
Usage and Extensions for Automatically Switched Optical Network
(ASON), Internet draft (in RFC editor queue), Oct. 2002.
(draft-lin-ccamp-gmpls-ason-rsvpte-04.txt)
[OIF-UNI-1.0] Optical Internetworking Forum (OIF) Implementation
Agreement OIF-UNI-01.0, User Network Interface (UNI) 1.0 Signaling
Specification, Oct. 2001.
[RFC2379] L. Berger, RSVP over ATM Implementation Guidelines, RFC
2379 (BCP), Aug 1998.
[RFC2380] L. Berger, RSVP over ATM Implementation Requirements, RFC
2380, Aug 1998.
[H.323] ITU-T Recommendation H.323, Packet-based Multimedia
Communications Systems, Nov. 2000.
[H.245] ITU-T Recommendation H.245, Control Protocol for Multimedia
Communication, July 2000.
[Raja03] B. Rajagopalan, LDP and RSVP Extensions for Optical UNI
Signaling, Internet draft (under IESG review), Jan. 2003.
[3GPP-TS23207] 3GPP TS 23.207 V5.6.0, End-to-end Quality of Service
(QoS) Concept and Architecture, Release 5, Dec. 2002.
[BEGD02] Bernet, Y., Elfassy, N., Gai, S. and D. Dutt, "RSVP
Proxy", draft-ietf-rsvp-proxy-03 (work in progress), Mar 2002.
[Meer02] H. de Meer, et al. "Analysis of Existing QoS Solutions".
Internet Draft. (draft-demeer-nsis-analysis-02.txt)
[Tsch02] H. Tschofenig, "RSVP Security Properties". Internet
Draft, Oct 2002. (draft-ietf-nsis-rsvp-sec-properties-00.txt)
[Fu02] X. Fu, et al, "Analysis on RSVP Regarding Multicast".
Internet Draft, Oct. 2002.
(draft-fu-rsvp-multicast-analysis-01.txt)
[Thom02] M. Thomas, "Analysis of Mobile IP and RSVP
Interactions". Internet draft, Oct. 2002.
(draft-thomas-nsis-rsvp-analysis-00.txt)
Manner et al Expires August 2003 [Page 24]
Internet-Draft Analysis of QoS Signaling February 2003
[RaNa98] B. Rajagopalan and R. Nair. "Multicast Routing with
Resource Reservation". Journal of High Speed Networks, 7(2), pp.
113-139, July 1998.
[FrJo02] Pierre Fransson and Andreas Jonsson, "The need for an
alternative to IPv4-options", in RVK (RadioVetenskap och
Kommunikation), Stockholm, Sweden, pp. 162-166, June 200.
[MHS02] Yu-Ben Miao, Wen-Shyang Hwang, Ce-Kuen Shieh, "A
transparent deployment method of RSVP-aware applications on UNIX".
Computer Networks, 40 (2002), pp. 45-56.
[FNS02] Gabor Feher, Krisztian Nemeth, Istvan Cselenyi,
"Performance evaluation framework for IP resource reservation
signalling". Performance Evaluation 48 (2002), pp. 131-156.
[PaSc98] Ping Pan, Henning Schulzrinne, "YESSIR: A Simple
Reservation Mechanism for the Internet". In the Proceedings of
NOSSDAV, Cambridge, UK, July 1998.
[PaSc00] P. Pan, and H. Schulzrinne, "Lightweight Resource
Reservation Signaling: Design, Performance and Implementation",
Bell Labs Technical Memorandum 10009669-03, July 2000.
[KaSh01] Martin Karsten, Jens Schmitt, Ralf Steinmetz,
"Implementation and Evaluation of the KOM RSVP Engine". IEEE
Infocom 2001.
[Kars01] Martin Karsten, "Experimental Extensions to RSVP -- Remote
Client and One-Pass Signalling". IWQoS 2001, Karlsruhe, Germany,
June 2001.
[LGZC00] S. Lee, A. Gahng-Seop, X. Zhang, A. Campbell,"INSIGNIA: An
IP-Based Quality of Service Framework for Mobile Ad Hoc
Networks". Journal of Parallel and Distributed Computing (Academic
Press), Special issue on Wireless and Mobile Computing and
Communications}, Vol. 60, Number 4, April, 2000, pp. 374-406.
[FNM+99] G. Feher, K. Nemeth, M. Maliosz, I. Cselenyi, J.
Bergkvist, D. Ahlard, T. Engborg, "Boomerang A Simple Protocol for
Resource Reservation in IP Networks", IEEE RTAS, 1999.
[MSK+03] J. Manner, T. Suihko, M. Kojo, M. Liljeberg, K.
Raatikainen, "Localized RSVP". Internet Draft, January 2003.
(draft-manner-lrsvp-01.txt)
[BGRP] P. Pan, E, Hahne, and H. Schulzrinne, "BGRP: A Tree-Based
Aggregation Protocol for Inter-domain Reservations", Journal of
Communications and Networks, Vol. 2, No. 2, June 2000, pp. 157-167.
[MRSVP] A. Talukdar, B. Badrinath, and A. Acharya, MRSVP: A
Resource Reservation Protocol for an Integrated Services Network
with Mobile Hosts, Wireless Networks, vol. 7, no. 1,
pp. 5-19. 2001.
Manner et al Expires August 2003 [Page 25]
Internet-Draft Analysis of QoS Signaling February 2003
[MA01] Bobgkyo Moon, Hamid Aghvami, "RSVP Extensions for Real-Time
Services in Wireless Mobile Networks". IEEE Communications
Magazine, December 2001, pp. 52-59.
13. Author's Addresses
Questions about this document may be directed to:
Jukka Manner
Department of Computer Science
University of Helsinki
P.O. Box 26 (Teollisuuskatu 23)
FIN-00014 HELSINKI
Finland
Voice: +358-9-191-44210
Fax: +358-9-191-44441
E-Mail: jmanner@cs.helsinki.fi
Xiaoming Fu
Institute for Informatics
Georg-August-University of Goettingen
Lotzestrasse 16-18
37083 Goettingen
Germany
Voice: +49-551-39-14411
Fax: +49-551-39-14403
E-Mail: fu@cs.uni-goettingen.de
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
Manner et al Expires August 2003 [Page 26]
Internet-Draft Analysis of QoS Signaling February 2003
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Manner et al Expires August 2003 [Page 27]
