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