Internet Draft Analysis of Existing QoS Solutions June 2002
Internet Engineering Task Force H. de Meer
INTERNET-DRAFT Piers O'Hanlon
Expires December 2002 University College London, UK
G. Feher
University of Budapest, Hungary
N. Blefari-Melazzi
University of Perugia, Italy
H. Tschofenig
Siemens, AG
G. Karagiannis
D. Partain
V. Rexhepi
L. Westberg
Ericsson
June 2002
Analysis of Existing QoS Solutions
draft-demeer-nsis-analysis-02.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.
de Meer, et al. Expires December 2002 [Page 1]
Internet Draft Analysis of Existing QoS Solutions June 2002
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This memo provides a brief analysis of existing IP quality of service
(QoS) solutions and the implied signaling issues. This analysis is
intended to point out open issues in QoS signaling. In particular,
this analysis is done in order to understand the issues related to
reservation state, scalability, mobility and security issues. The
existing IP QoS solutions can be categorized as follows:
* End-to-end per-flow resource reservation protocols
* Integrated Services over Differentiated Services
* Statically assigned trunk reservations based on
Differentiated Services
* Dynamic trunk reservations with Aggregated RSVP
de Meer, et al. Expires December 2002 [Page 2]
Internet Draft Analysis of Existing QoS Solutions June 2002
Table of Contents
1 Introduction ................................................. 4
2 Issues Used in the Analysis .................................. 6
3 End-to-end per-flow resource reservation protocol ............ 7
4 Integrated Services over Differentiated Services ............. 10
5 Statically-assigned trunk reservations based on DiffServ ..... 14
6 Dynamic trunk reservations with Aggregated RSVP .............. 18
7 Conclusions .................................................. 21
8 References ................................................... 23
9 Acknowledgments .............................................. 26
10 Editors' Addresses .......................................... 26
de Meer, et al. Expires December 2002 [Page 3]
Internet Draft Analysis of Existing QoS Solutions June 2002
1. Introduction
QoS support in IP networks can be traced back to the seminal
Sigcomm92 paper on the "Integrated Service Packet Network" model
(ISPN) by Clark, Shenker and Zhang [CSZ92]. Roughly, the ISPN model
is built on four columns:
* A QoS specification and requirements description, which could
be seen as a description of a service level agreement that
must be honored by a given QoS architecture.
* Mechanisms for admission control or traffic conditioning
when resources are finite and contention may arise.
* Scheduling and other mechanisms to be in place at the network
nodes to enforce preferential forwarding and processing of
data packets. Network resources must be in place to assure
the specified QoS.
* Signaling and service interfaces to convey information on
preferences and expectations (requirements) of data packet
processing and forwarding from applications to relevant
control elements of network resources and from there back
to the applications.
Finally, a QoS architecture is needed that integrates all four
columns into an end-to-end solution. At this point nothing is
precluded in terms of the interpretation of such an end-to-end
architecture. The requirement for an end-to-end QoS solution does
not necessarily mean that a single resource reservation signaling
protocol must be applied end-to-end. In fact, it is most likely that
the end-to-end QoS management architecture will consist of many
interoperable and concatenated QoS management architectures rather
than one global end-to-end QoS infrastructure.
In the practical sense such a QoS architecture may also provide means
for accounting and charging for QoS reservations and for data traffic
experiencing preferential treatment. By using such a scheme it is
possible to create incentives to restrict resource reservation
requests.
"Next Steps for the IP QoS Architecture" [RFC2990] for example,
recognizes that, "both the Integrated Services architecture and the
Differentiated Services architecture have some critical elements in
terms of their current definition which appear to be acting as
de Meer, et al. Expires December 2002 [Page 4]
Internet Draft Analysis of Existing QoS Solutions June 2002
deterrents to widespread deployment... There appears to be no single
comprehensive service environment that possesses both service
accuracy and scaling properties". This statement sums up the reasons
behind both the proposal of hybrid architectures composed of IntServ
and DiffServ regions (with the associated problems related to mapping
and interworking procedures between different regions) and the
necessity/opportunity of improving/upgrading the IntServ and DiffServ
paradigms.
Well-known interpretations are IntServ, DiffServ and even
heterogeneous interpretations such as IntServ over DiffServ. Other
interpretations may still be to come.
Each column, however, may be realized differently in each
interpretation. For example, resources may be claimed based on the
granularity of flows or aggregates. signaling would similarly reflect
the right level of granularity and could be implicit or explicit.
For example, RSVP [RFC2205], one of most prominent signaling
protocols has been adopted within the IntServ architecture for
resource reservations. Admission control could be explicit by or
implicit by overprovisioning and conditioning, etc.
In this draft a brief analysis is given of existing IP QoS solutions
and the implied signaling issues. The analysis is intended to point
out open QoS signaling issues (column 4). Where needed, we will also
touch on related admission control or traffic conditioning issues.
The main existing IP QoS solutions can be categorized as follows:
* End-to-end per-flow resource reservation protocol:
uses a per-flow resource reservation signaling protocol
that is applied in an end-to-end communication path.
* Integrated Services over Differentiated Services: a framework
that provides end-to-end QoS using the IntServ model over
heterogeneous networks.
* Statically assigned trunk reservations based on
Differentiated Services: several individual reservations
are aggregated into a common reservation trunk that is
statically configured.
* Dynamic trunk reservations with Aggregated RSVP: several
individual reservations are aggregated into a common
reservation trunk. Additionally, these trunks are dynamically
de Meer, et al. Expires December 2002 [Page 5]
Internet Draft Analysis of Existing QoS Solutions June 2002
configured by using a signaling protocol that manages
various mechanisms for dynamic creation of an aggregate
reservation.
2. Issues Used in the Analysis
The main goal of this analysis is to bring the observations on the
main existing QoS solutions related to reservation state management,
scalability, support for mobility and security issues in order to
point out the differences and open issues. The existing IP QoS
solutions explained in this draft will be analysed in terms of:
* Reservation State
Depending on the set-up, maintenance and release a reservation
state can be:
- hard state where the resources are released by means of
explicit release
- soft state that needs to be refreshed in certain periods
in time, otherwise it will be released. Soft state can also
be released by means of explicit release messages.
* Scalability
Scalability can be defined as the ability to increase the number
of reservation states in a network entity, while maintaining the
required network performance. However, scalability is not only
related to the number of the reservation states, but also to the
number of messages that need to be processed, number
of hand-offs in case of mobility, CPU utilization, etc.
* Support for Mobility
During the development of the existing IP QoS solutions presented
in this draft, mobility support was not one of the design goals.
However, currently mobility support is very important. Due to this
the implications of mobility in the exisiting IP QoS solutions
are to be addressed as well.
* Security Issues
Quality of Service is a valuable item which requires protection. Both
signaling messages distributing and installing reservation state at
de Meer, et al. Expires December 2002 [Page 6]
Internet Draft Analysis of Existing QoS Solutions June 2002
routers along the path and data messages experiencing QoS treatment
must be protected accordingly. Security of the data traffic in the
context of QoS usually applies to the marking of packets. Packet
marking and address spoofing may be used by an adversary to mount
denial of service attacks, to steal traffic or for fraud purposes.
From a trust perspective there is a distinction between intra-domain,
inter-domain and access network signaling. Each of these regions place
different security requirements on signaling messages and the payloads
embedded inside. Access network signaling refers to the signaling
messages exchanged between the user's host (end-host) and the access
network. These security issues are discussed briefly for each of the
existing IP QoS solutions given in this draft.
3. End-to-end per-flow resource reservation protocol
An end-to-end per-flow resource reservation signaling protocol is
applied in an end-to-end data path, and it can be used by an
application to signal its QoS requirements to nodes (participating in
the signaling) along the path. This type of protocol is typically
initiated per flow by an application at the beginning of a
communication session. A flow (in RSVP) is typically identified by
the combination of the source and destination IP address, transport
layer protocol, and source/destination port number. Other flow
identifications are also possible as for example IPSec (when used
end-to-end between the two communicating end-points) then some of the
previously mentioned header information is not available to interior
nodes. Hence the flow identification is limited IP addresses and the
available SPI as described in [RFC2207]. The resources reserved per
flow by such a protocol for a certain communication session will be
used for all packets belonging to that particular flow. Therefore,
all resource reservation signaling packets will include details of
the session to which they belong.
The end-to-end per-flow resource reservation signaling protocol most
widely used today is the Resource Reservation Protocol (RSVP) (see
[RFC2205]). The main RSVP messages are the PATH and RESV messages.
The PATH message is sent by a source that initiates the communication
session. It installs states on the nodes along a data path.
Furthermore, it describes the capabilities of the source. The RESV
message is issued by the receiver of the communication session, and
it follows exactly the path that the RSVP PATH message traveled back
to the communication session source. On its way back to the source,
the RESV message may install QoS states at each hop. These states are
associated with the specific QoS resource requirements of the
de Meer, et al. Expires December 2002 [Page 7]
Internet Draft Analysis of Existing QoS Solutions June 2002
destination. The RSVP reservation states are temporary states (soft
states) that have to be updated regularly. This means that PATH and
RESV messages will have to be retransmitted periodically. If these
states are not refreshed then they will be removed. RSVP uses
additional messages either to provide information about the QoS state
or explicitly to delete the QoS states along the communication
session path. RSVP uses in total seven types of messages:
* PATH and RESV messages
* RESV Confirm message
* PATH Error and RESV Error messages
* PATH Tear and RESV Tear messages
Reservation State
-----------------
RSVP reservation state is per-flow soft state. This per-flow reservation
state is identified by means of the flow identifier, which is a combination
of the source and destination IP address, transport layer protocol, and
source/destination port number.
The reservation state management is a combination of the soft state
principle and explicit release. As explained above the reserved resources
will be released if not refreshed in a certain period of time.
The explicit release of resources in RSVP[RFC2205]is done by means of
RESV TEARDOWN and PATH TEARDOWN message that can only be sent by the
receiver end-host or sender-end host respectively.
In RSVP, the success of resource request is reported by a successful
admission control function. The amount of initially reserved resources
can be modified during the duration of RSVP session by means of RSVP
refresh messages and the modify function in traffic admission control.
Scalability
-----------
In the research community it is a well known fact that RSVP [RFC2205]
does not scale well in large networks due to per-flow reservation
state management. Due to this the number of states increases linearly
with the number of flows. This introduces severe scalability problems
in the networks where the number of flows is large (see also [ChNe98]).
de Meer, et al. Expires December 2002 [Page 8]
Internet Draft Analysis of Existing QoS Solutions June 2002
In terms of number of messages that need to be processed, in RSVP
there are seven types of messages defined needed for setting up,
maintaining and releasing the RSVP signaling session. All of these
messages are sent per-flow, thus the number of messages received by
a signaling communication host increases linearly proportional to the
number of flows, i.e. RSVP signaling sessions. This may scale
well in those type of networks where the number of flows is
modest, but it will introduce scalability problems in networks
with a large number of flows.
In terms of CPU utilization at the end terminal and intermediate
nodes, RSVP is a receiver-initiated protocol designed for unicast
and multicast reservations. As such the RSVP "soft" state
maintenance is complex as it needs to support dynamic membership
changes in the multicast group, i.e. reservation state
merging and maintenance. This requires complex processing that
will most probably affect the CPU utilization. Furthermore
the CPU utilization will also be affected by the per-flow
filtering/classification of the data traffic required in RSVP.
Add ref.
Support for Mobility
--------------------
RSVP wass not designed with mobility in mind and as such it does
not support roaming and handovers in an efficient way. In a handover
event new end-to-end signaling needs to be triggered which may causes
double reservations in some parts of the communication path and an
increased latency.
The main problems of the interworking between RSVP and Mobile IP are
analyzed in [To01] and in [Pa01].
Security Issues
---------------
[RFC2747] provides authentication, integrity and replay
protection of the entire RSVP message in a hop-by-hop fashion
by using the INTEGRITY object for RSVP. Based on the principle
of chain-of-trust the signaling messages are protected hop-by-hop
from one signaling endpoint to the other. The Policy Object may
additionally contain an INTEGRITY object which provides protection
of the object inside this object between two policy aware nodes.
The functionality and the structure of the POLICY_DATA element a
de Meer, et al. Expires December 2002 [Page 9]
Internet Draft Analysis of Existing QoS Solutions June 2002
re described in [RFC2205]. Additionally the POLICY_DATA object allows
user authentication (by including various types of credentials in
the AUTH_DATA attribute). Replay protection in RSVP is done with
the help of the 64-bit sequence number field included in the
INTEGRITY object. Sequence number resynchronization in case of a
crashed or rebooted host is done with the Integrity Handshake mechanism.
The starting sequence number is set with the establishment of the
security association. RSVP assumes that most security associations
are already available before the protocol execute. This seems to be
feasible within the internal network. Authentication of a user either
to first-hop router or the Policy Decision Point (PDP) is very likely
based on Kerberos. This allows Kerberos service tickets to be used to
establish a session key between the two communicating parties. A detailed
description of the RSVP security properties can be found at [Ts02].
For more analysis on RSVP security issues see [Ha02].
4. Integrated Services over Differentiated Services
The IntServ over DiffServ architecture addresses the problem of
providing end-to-end QoS using the IntServ model over heterogeneous
networks. In this scenario, DiffServ is one of these networks
providing edge-to-edge QoS.
The IntServ over DiffServ architecture allows at least two different
possible deployment strategies. The first is based on statically
allocated resources in the DiffServ domain. In this strategy, the
DiffServ domain is statically provisioned. Furthermore, with this
strategy the devices in the DiffServ network region are not RSVP (or
any other dynamic signaling) aware. However, it is considered that
each edge node in the customer network consists of two parts. One
part of a node is a standard IntServ that interfaces to the
customer's network region and the other part of the same node
interfaces to the DiffServ network region. All edge nodes in the
customer network maintain a table that indicates the capacity
provisioned per SLS (Service Level Specification) at each DiffServ
service level. This table is used to make admission control decisions
on IntServ flows that cross the DiffServ region.
A disadvantage of this approach is that the edge nodes in the
customer network will not be aware of the traffic load in the nodes
located within the DiffServ domain. Therefore, a congestion
situation on a communication path within the DiffServ domain cannot
be detected by any of these edge nodes. Congestion within a DiffServ
de Meer, et al. Expires December 2002 [Page 10]
Internet Draft Analysis of Existing QoS Solutions June 2002
domain may arise due to difficulties in static provisioning
[RFC2990]. Repeated steps of aggregations/disaggregations of traffic
aggregates or other stochastic disturbances may adversely affect the
QoS. In contrast to the IntServ architecture, no mathematical proof
of a reliable QoS delivery by DiffServ architectures has yet been
provided. An immediate conclusion is to take such possibilities into
account from the outset.
Accordingly, further improvements could be achieved by providing
congestion signaling from within such a DiffServ domain to the border
between the two administrative domains in question. As is the case
with TCP control, it is anticipated that (some) "subscribers" to such
a disturbed service would back off and thus improve the traffic load
situation within the domain. Appropriate signaling mechanisms would
be needed that reflect violation of a specified QoS level. If
subscribers do back off the original QoS level would be resumed.
Feedback information and signaling is needed in the next generation
of a DiffServ architecture that delivers its specified classes of
service by a combination of resource provisioning and cooperation
with the subscribers. This would be similar to native TCP/IP
environments, but with integrated DiffServ characteristics. While
resource provisioning is static and does cover the most common and
regular case of QoS support, feedback signaling and adaptation or
dynamic conditioning would deal with the (hopefully) rare event of
insufficient provisioning. Note that the original service
specification would explicitly entail the possibility of a reduction
in the advertised DiffServ bandwidth and the expectation of
subscribers to back off according the to needs of reestablishing a
DiffServ QoS class. More details of this concept is given in [DO01].
The second possible strategy is based on dynamically allocated
resources in the DiffServ domain. According to [RFC2998], this can be
done using RSVP-aware DiffServ routers. However, this approach has
most of the RSVP drawbacks, and per-microflow state information is
kept in the intermediate routers. Furthermore, dynamic provisioning
may be too slow to respond quickly enough to congestion events.
Alternatively, resources in the DiffServ domain can be dynamically
allocated using Aggregated RSVP.
Other approaches related to the bandwidth broker concept are still
very immature and will not be discussed here.
IntServ is designed to accommodate signaling protocols other than
RSVP. In fact, IntServ, RSVP and services classes are all separable.
de Meer, et al. Expires December 2002 [Page 11]
Internet Draft Analysis of Existing QoS Solutions June 2002
IntServ is the specific architecture or model, RSVP the specific
signaling mechanism, and two service classes have been defined
(others were discussed, and could still be invented). Similar
arguments apply to DiffServ: provisioning can be static or dynamic,
signaling can be distributed and in band (RSVP) or out of band and
centralized, or combinations thereof. Conditioning can be static or
dynamic, and most combinations thereof are possible. IntServ and
DiffServ can almost orthogonally combined with each other in either
mode as discussed here.
Reservation State
-----------------
The IntServ model is based on soft state and time out
of reservations. Explicit release of resources is possible
as well.
The Diffserv reservation state depends on whether the resources
are assigned statically or dynamically. In case of static
resource allocation there will be no need for resource reservation
mechanisms, while in case of dynamic resource allocation the
reservation state depends on the dynamic resource reservation
protocol used. Thus the reservation state may be managed
in a soft state manner as is the case of RSVP or it may
be hard state as well.
In IntServ domains reservation states can be dynamically
changed. But it is not certain what happens if an increase
of reservation fails, if that could lead to a disruption. Change
of reservation state in DiffServ clouds is not always possible.
DiffServ network regions may be statically provisioned. A dynamic
change of reservation state may be disruptive in RSVP-aware DiffServ
regions as, for example, admission control and paths may be decoupled
in case only edge routers are RSVP-capable. If interior routers are
also RSVP-capable, more detailed reservation state information
can be signalled and modified explicitly.
A prompt notification is missing in this framework. In the
IntServ model failures or QoS violations are noticed when
refreshment of reservation state fails. QoS violation in the
DiffServ network element has not yet been considered widely,
at least not in RFC2998. This is probably the greatest lack
of signaling element in the whole framework as presented in
RFC2998. signaling is almost exclusively reserved for the
set-up phase. Further operational feedback possibilities are
widely ignored, both implicit or explicit. Best-effort TCP/IP
would not work without feedback and adaptation. Therefore,
de Meer, et al. Expires December 2002 [Page 12]
Internet Draft Analysis of Existing QoS Solutions June 2002
neglecting it in QoS architectures may not be wise.
Scalability
-----------
In [RFC2998] DiffServ network elements are introduced to improve
scalability in core networks. This is true if Diffserv is
statically provisioned. But in case of dynamic provisioning,
signaling and provisioning overhead may reduce scalability again.
Especially, scalability may be affected in case per-flow
traffic classification and marking is performed at the
core routers.
Support for Mobility
--------------------
Intserv does not support mobility and as such it is not designed
to support handovers. In a handover event a new signaling session
needs to be initiated.
Same as Intserv, Diffserv was not designed for mobility support.
While for the dynamic provisioned Diffserv some support can still be
provided, with static Diffserv mobility is not at all possible unless
some overprovisioning of resources is used.
Security Issues
---------------
It has often been mentioned that security protection has implications
are important for signaling messages itself and for the subsequent
data messages. The subsequent paragraphs elaborate summarize these i
ssues briefly.
- Protection of Data Messages
In the context of packet marking with DSCPs there is a danger for
a network to receive packets which are improperly marked without
the required authentication and authorization. This is particularly
true if the task of packet marking is delegated to an untrusted
de Meer, et al. Expires December 2002 [Page 13]
Internet Draft Analysis of Existing QoS Solutions June 2002
end-host. Section 7.2 of [RFC2998] discusses security considerations
for host marking. Possible threats are resource theft and denial of
service attacks. One concern, which is often mentioned, is that the
DSCP is a mutable field and not protect protected by IPSec AH i.e.
the DSCP in the outer packet header is not protected by AH (and no
the entire outer packet header is unprotected in case of IPSec ESP).
In case of tunnel mode the marking in the inner header is protected. It
however heavily depends on the type of processing applied when
encapsulating and decapsulating the packet. Issues related to DiffServ
and Tunnels (including IPSec protected data traffic) are described in
[RFC2983].
Special care must be taken at the edges of a network where the incoming
data traffic is subject to admission control and accounting. It must
be insured that end-hosts are not able to inject data traffic into
the internal network without proper verification.
- Protection of Signaling Messages
If RSVP is used to assist nodes with their DSCP marking by distributing
the code points to end-hosts or to edge devices as described in [RFC299]
then RSVP's security protection with data origin authentication, integrity
and replay protection as provided with the INTEGRITY object is used. Where
RSVP signaling starts and ends has trust and therefore key management
implications. However this issue heavily depends on a particular
architecture.
5. Statically-assigned trunk reservations based on DiffServ
The [RFC2475] defines an architecture for implementing scalable
service differentiation in the Internet, denoted as Differentiated
Services (DiffServ). This architecture achieves scalability by
aggregating traffic classification state which is conveyed by means
of IP-layer packet marking using the DS field [RFC2474]. Packets are
classified and marked to receive a particular per-hop forwarding
behavior on nodes along their path.
A significant problem in deploying an end-to-end per-flow resource
reservation signaling scheme is its scalability. This can be solved
by aggregating (trunking) several individual reservations into a
common reservation trunk. The reservation trunks can either be
statically or dynamically configured.
de Meer, et al. Expires December 2002 [Page 14]
Internet Draft Analysis of Existing QoS Solutions June 2002
When the reservation trunks are statically configured, the resource
management is likely to be quite difficult. This is due to different
mobility requirements (such as handover) and QoS requirements (such
as bandwidth) that the multi-bitrate applications impose on a network
that supports mobile users as it will be difficult to configure the
trunked reservations statically and at the same time utilize the
network efficiently. In order to achieve this signaling would be
required.
In principle, the availability of DiffServ per-hop behaviors along
with mechanisms to statically or dynamically limit the absolute level
of traffic within a traffic class allows the DiffServ network cloud
to act as a network element within the Integrated Services framework.
In other words, an appropriately designed, configured and managed
DiffServ network cloud can act as one component of an overall end-to-
end QoS controlled data path using the Integrated Services framework,
and therefore support the delivery of IntServ QoS services [WROCHA].
The key to providing absolute, quantitative QoS services within a
DiffServ network is to ensure that at each hop in the network the
resources allocated to the PHBs used for these services are
sufficient to handle the arriving traffic. This can be done through a
variety of mechanisms ranging from static provisioning to dynamic
per-hop signaling within the cloud. Two situations are possible:
* With per-cloud provisioning, sufficient resources are
made available in the network so that traffic arriving at
an ingress point can flow to "any" egress point without
violating the PHB resource allocation requirements. In this
case, admission control and traffic management decisions
need not be based on destination information.
* With per-path provisioning, resources are made available
in the network to ensure that the PHB resource allocation
requirements will not be violated if traffic arriving
at an ingress point flows to one (in the unicast case)
specific egress point. This requires that admission control
and resource provisioning mechanisms take into account the
egress point of traffic entering the network, but results
in more efficient resource utilization.
The per-cloud vs per-path decision is independent of decisions about
static vs. dynamic provisioning. It is often assumed that dynamic
provisioning is necessarily per-path, while static provisioning is
de Meer, et al. Expires December 2002 [Page 15]
Internet Draft Analysis of Existing QoS Solutions June 2002
more likely to be per-cloud.
Hence, the existence of upper bounds on delay through the cloud
implies centralized knowledge about the topology of the cloud and
traffic characterization.
These considerations imply that determination of the bound on the
delay through the DiffServ cloud should be performed off-line,
perhaps as part of a traffic management algorithm, based on the
knowledge of the topology, traffic patterns, shaping policies, and
other relevant parameters of the cloud [WROCHA].
However, this turns out to be a rather difficult task. Barring new
results on delay bounds, the amount of traffic requiring end-to-end
Guaranteed service (like) across the DiffServ cloud should be rather
small, potentially leading to severe inefficiencies.
Additionally, to provide a strict delay bound, the utilization factor
of the bandwidth allocated to this traffic has to be
deterministically bounded on all links in the network. This can be
either ensured by signalled admission control (such as using dynamic
resource reservation, e.g., [RMD], [BiaBle]) or by a static
provisioning mechanism. It should be noted that if provisioning is
used, then to ensure deterministic load/service rate ratio on all
links, the network should be strongly overprovisioned to account for
possible inaccuracy of traffic matrix estimates [WROCHA].
de Meer, et al. Expires December 2002 [Page 16]
Internet Draft Analysis of Existing QoS Solutions June 2002
Reservation State
-----------------
With DiffServ, the QoS is signalled in the DS field of the data
packets. RFC2475 does not explicitly reserve resources, thus it
consequently does not explicitly release resources.
There is no specification of feedback mechanisms regarding
success of QoS requests in RFC2475. However, local QoS edge
devices may provide feedback at a higher level.
RFC2475 specifies that the QoS for a given packet is determined
by the Per Hop Behavior assigned to it as a result of its
code point. Thus, since the PHBs are assigned independently,
the choice of code point cannot affect the PHB. However,
if a certain code point becomes overloaded then QoS of the
associated PHB may suffer.
The value of the reservation identifier (the DS code point)
is completely independent of the IP address and flow ID. The
actual mapping of such an identifier is consistent within one
DS domain.
Scalability
-----------
RFC2475 specifies a framework for providing QoS through the use
of packet marking, thus the QoS is implicitly signalled. This
approach scales well in terms of network state, though to
achieve reliable QoS guarantees the network requires careful
provisioning.
The traffic entering a DiffServ domain can be aggregated in
a specific traffic class (i.e., PHB). However, there is no
method for selecting and changing the level of aggregation.
Support for Mobility
--------------------
Diffserv does not have any support for mobility. In case of
statically assigned trunk reservations support for mobility
is a difficult network management problem. Due to handover
requirements and QoS requirements (such as bandwidth) that the
multi-bitrate applications impose on a network that supports
mobile users, it will be difficult to configure the
trunked reservations statically and at the same time utilize
the network efficiently.
de Meer, et al. Expires December 2002 [Page 17]
Internet Draft Analysis of Existing QoS Solutions June 2002
Security Issues
---------------
Regarding the security of DiffServ marking the same considerations
apply as described in Section 3 security issues. In case that no
end-user hosts are involved and DiffServ domains are located in the
core of the network stronger trust assumptions prevent some of the
problems described. Since the scenario described in this Section is
lacking a signaling protocol and only statically provisioned networks are
used other security considerations are not applicable (especially
those with regard to signaling).
6. Dynamic trunk reservations with Aggregated RSVP
The reservation trunks can be dynamically configured by using a
signaling protocol that manages various mechanisms for dynamic
creation of an aggregate reservation, classification of the traffic
to which the aggregate reservation applies, determination of the
bandwidth needed to achieve the requirement, and recovery of the
bandwidth when the sub-reservations are no longer required.
The first router that handles the aggregated reservations could be
called an Aggregator, while the last router in the transit domain
that handles the reservations could be called a Deaggregator.
The Aggregator and Deaggregator functionality is located in the edge
nodes. In particular, an Aggregator is located in an ingress edge
node, while a Deaggregator is located in an egress edge node,
relative to the traffic source.
The aggregation region consists of a set of aggregation-capable
network nodes. The Aggregator can use a policy that can be based on
local configuration and local QoS management architectures to
identify and mark the packets passing into the aggregated region.
For example, the Aggregator may be the base station that aggregates a
set of incoming calls and creates an aggregate reservation across the
edge-to-edge domain up to the Deaggregator. In this situation the
call signaling is used to establish the end-to-end resource
reservations. Based on policy, the Aggregator and Deaggregator will
decide when the Aggregated states will be refreshed or updated.
One example of a protocol that can be used to accomplish QoS dynamic
de Meer, et al. Expires December 2002 [Page 18]
Internet Draft Analysis of Existing QoS Solutions June 2002
provisioning via trunk reservations is the RSVP Aggregation signaling
protocol specified in [RFC3175].
Reservation State
-----------------
RSVP Aggregation reservation state is per-aggregate-flow soft state.
The reservation state management is a combination of the soft state
principle and explicit release. As explained above the reserved
resources will be released if not refreshed in a certain period
of time.
The explicit release of resources is done by means of explicit release
messages that are send by the Aggregator/ Deaggregator respectively.
The amount of initially reserved resources can be modified during the
duration of RSVP session by means of RSVP aggregation refresh messages
and the modify function in traffic admission control.
Scalability
-----------
The number of the RSVP aggregation messages are linearly
proportional to the number of the supported aggregated
flows. Note that the number of aggregated flows is much less
than the number of micro-flows.
The reservation setup by means of RSVP aggregation requires
certain interactions. These interactions are linearly
proportional to the number of the supported aggregated flows.
RSVP installs one reservation state per aggregate. This means
that the number of states increases linearly with the number
of aggregates. However, in a DiffServ-based domain the number
of aggregated RSVP sessions depends on:
* The number of Aggregators/Deaggregators: this depends on the
number of the edge nodes used (assuming that these nodes act
as Aggregators/Deaggregators). For example, in an IP-based
wireless network, the number of the edge nodes can depend on
the number of based stations and controlling gateways. In
cellular networks, the number of controlling gateways is
high, and the number of base stations is in the range of
thousands (see [PaKa01]).
de Meer, et al. Expires December 2002 [Page 19]
Internet Draft Analysis of Existing QoS Solutions June 2002
* The network topology used: when the communication is
performed in a meshed way (that is, all-to-all), it
will imply that many communication paths will have to be
maintained by the network simultaneously.
* The number of DiffServ Code Points (DSCPs) used: more than
one traffic class will be supported within a network.
Therefore, the number of the aggregated RSVP reservation states
within such a network will be significant.
RSVP aggregation protocol is a receiver-initiated protocol designed
for unicast and multicast reservations. As such, the RSVP aggregation
"soft" state maintenance is complex as it needs to support dynamic
membership changes in the multicast group, i.e. reservation state
merging and maintenance. This requires complex processing that will
most probably affect the CPU utilization. However, compared to RSVP,
the CPU utilization will be less affected by the
filtering/classification of the data traffic since this is
accomplished on a per aggregate basis.
Support for Mobility
--------------------
RSVP Aggregation does not support mobility and as such it
is not designed to support handovers. When RSVP Aggregation
is used in the core network then mobility is usually not a
problem. However using aggregation in the access network effects
of roaming mobile nodes may require the re-initiation of new
signaling messages. Hence the placement of Aggregators and
Deaggregators, which is left to the choice of the network operator,
may cause interactions with roaming nodes. The network topology
and other environmental factors may restrict the placement of
these Aggregators/Deaggregators nodes.
Security Issues
---------------
RSVP Aggregation as described in [RFC3175] uses signaling between
two endpoints (typically between the edges of a network) other
than the typical end-to-end host endpoints. Hence there is
very little need to address user authentication (or also
de Meer, et al. Expires December 2002 [Page 20]
Internet Draft Analysis of Existing QoS Solutions June 2002
application identity representation) with the help of the POLICY_DATA
object. Security protection of signaling messages is therefore heavily
based on the INTEGRITY object which is applied in a hop-by-hop mode.
7. Conclusions
This draft provides a brief analysis of existing IP QoS solutions and
accompanying signaling issues.
This analysis is done in terms of reservation state, scalability,
mobility support and security issues in order to point out pending
and open issues of existing IP QoS solutions.
RSVP as given in [RFC2205] is a flexible well-designed protocol that
works well for applications for which it was intended. But, it has
not been widely deployed due to issues such as complex reservation
state management, scalability, etc. Furthermore, RSVP includes more
functionality than what is required in some IP networks, where the
QoS problem is significantly simpler to solve (see [WQOSREQ]). In
these networks, the tradeoff between performance and functionality is
one of the key issues and the majority of the functionality in RSVP
will not be required. This is because of the following reasons:
* Most of the QoS sensitive applications do not use the
multicast capabilities of RSVP. Supporting only unicast and
one-to-many multicast reservations is a reasonable tradeoff,
since they are considerably simpler than many-to-many
multicast reservations. Note that even for the one-to-many
multicast reservations capability, it should be ensured that
this type of reservation will not outweigh the requirement
for simplicity and scalability.
Without the many-to-many reservation support, protocols
do not necessarily have to be receiver-oriented, i.e. these
protocols will be sender-initiated. In this case, there is no
need for PATH messages usage. This reduces the number of
states in the routers (no Path State is required).
Furthermore, no reverse direction (backward) routing is
required. Such protocols perform one pass only during the
setup instead of the two passes and therefore speed up the
reservation initiation. Additionally, the initiation of
bi-directional reservations in combination with many-to-many
reservations is very complex.
de Meer, et al. Expires December 2002 [Page 21]
Internet Draft Analysis of Existing QoS Solutions June 2002
Thus, by removing multicast support, reservation styles, complex
merging and state management RSVP is more lightweight in terms
of implementation complexity, state maintenance and protocol
processing. Sender-initiated reservations are also possible. A
more detailed investigation is provided in [Fu02].
* A single operator edge-to-edge intradomain network does not
require policy handling in the interior routers.
* Path characteristics and flexible traffic parameters and
QoS definitions could be solved by network dimensioning
and edge functionality.
* The huge number of per-microflow states in intermediate
routers might cause severe scalability problems.
The DiffServ architecture [RFC2475] does not specify a full QoS
signaling protocol. It specifies a framework with an implicit QoS
signaling mechanism, which requires out of band Per Hop Behavior set
up.
The IntServ over DiffServ architecture [RFC2998] allows at least two
different possible deployment strategies. The first is based on
statically allocated resources in the DiffServ domain. A main
disadvantage of this approach is that the edge nodes in the customer
network will not be aware of the traffic load in the nodes located
within the DiffServ domain. The second possible strategy is based on
dynamically allocated resources in the DiffServ domain. According to
[RFC2998], this can be done using RSVP-aware DiffServ routers.
However, this approach has most of the drawbacks of RSVP, and per-
microflow state information is kept in the intermediate routers.
With regards to aggregated RSVP [RFC3175], even if the reservation is
based on aggregated traffic, the number of re-negotiations of the
allocated resources due to mobility (when applicable, e.g. access
networks) does not decrease and each re-negotiation of resources has
the same performance requirements as the per-flow reservation
procedure.
Note that the aggregated RSVP solution may use a policy to maintain
the amount of bandwidth required on a given aggregate reservation by
taking account of the sum of the underlying end-to-end reservations,
while endeavoring to change it infrequently. However, such solutions
(policies) are very useful assuming that the cost of the
de Meer, et al. Expires December 2002 [Page 22]
Internet Draft Analysis of Existing QoS Solutions June 2002
overprovisioned bandwidth is not significant, since this implies the
need for a certain "slop factor" in bandwidth needs. In certain
networks, where overprovisioning is not practical due to high costs
of transmission links, a more dynamic QoS provisioning solution is
needed.
Furthermore, the aggregated RSVP scheme is receiver initiated and
cannot support bi-directional reservations.
In the aggregated RSVP scheme the resource reservation states stored
in all the RSVP-aware edge and interior nodes represent aggregated
RSVP sessions or trunks of RSVP sessions. Therefore, the number of
the resource reservation states in the aggregated RSVP scheme
compared to the (per-flow) RSVP scheme is decreased. However, in a
DiffServ-based domain the number of the aggregated RSVP sessions
depends on the network topology, the number of
Aggregators/Deaggregators and the number of DiffServ Code Points
(DSCPs) used. When considering networks with large number of flows,
the number of the aggregated RSVP reservation states within such a
network will be significant.
This analysis points out pending and open QoS signaling issues
related to reservation state management, scalability, support for
mobility and security issues of the main existing IP QoS solutions
([RFC2205], [RFC2998], [RFC2475], [RFC3175]). Given this analysis, we
believe that appropriate standardization should take place to create
the necessary protocols for QoS signaling.
8. References
[BiaBle] G. Bianchi, N. Blefari_Melazzi, "A Migration Path
to provide End-to-End QoS over Stateless
Networks by Means of a Probing-driven Admission
Control", Internet Draft, work in progress,
draft-bianchi-blefari-end-to-end-QoS-xx.txt, 2001.
[Brun02] Brunner, M., "Requirements for QoS Signaling Protocols"
Internet Draft, work in progress,
draft-ietf-nsis-req-01.txt, 2002.
[CSZ92] Clark, D.D., Shenker, S., Zhang, L, "Supporting
Real-Time Applications in an Integrated Services
Packet Network: Architecture and Mechanism",
Proc. ACM SIGCOMM'92, August 1992.
de Meer, et al. Expires December 2002 [Page 23]
Internet Draft Analysis of Existing QoS Solutions June 2002
[DO01] De Meer, H., O'Hanlon, P, ''Segmented Adaptation
of Traffic Aggregates'', 9th Int'l Workshop on
Quality of Service, IWQoS'01, Karlsruhe, 2001.
[Ha02] Tschofenig, H., "RSVP Security Properties",
Internet Draft, work in progress.
draft-tschofenig-rsvp-sec-properties-00.txt, 2002
[PaKa01] Partain, D., Karagiannis, G., Wallentin, P.,
Westberg, L., "Resource Reservation Issues
in Cellular Radio Access Networks",
Internet Draft, work in progress,
draft-westberg-rmd-cellular-issues-xx.txt, 2001.
[PaKa02] Partain, D., Bergsten, A., Greis, M., Karagiannis,
G., Manner, J., Murphy, J., Pan, P., Rexhepi,
V., Westberg, L., Zheng, H., "NSIS QoS signaling
Requirements", Internet Draft, work in progress,
draft-partain-nsis-requirements-xx.txt, 2002.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, A.,
Jamin, S., "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification", IETF RFC
2205, 1997.
[RFC2210] Wroclawski, J., "The use of RSVP with IETF
integrated Services", IETF RFC 2210, 1997.
[WQOSREQ] Westberg, L., Karagiannis, G., Partain, D., "QoS
signaling Requirements for Wireless
Networks", Internet Draft, work in progress,
draft-westberg-nsis-wireless-requirements-xx.txt,
2001.
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., Weiss, W., "An Architecture for Differentiated
Services", IETF RFC 2475, December 1998.
[RFC2476] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang,
"RSVP Operation Over IP Tunnels", RFC 2746, January
de Meer, et al. Expires December 2002 [Page 24]
Internet Draft Analysis of Existing QoS Solutions June 2002
2000.
[RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[RFC2990] G. Huston, "Next Steps for the IP QoS Architecture",
RFC2990, November 2000.
[RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F.,
Zhang, L., Speer, M., Braden, R., Davie, B.,
Wroclawski, J. and Felstaine, E., "A Framework
for Integrated Services Operation Over DiffServ
Networks", RFC 2998, November 2000.
[RFC3175] Baker, F., Iturralde, C. Le Faucher, F., Davie, B.,
"Aggregation of RSVP for IPv4 and IPv6
Reservations", IETF RFC 3175, 2001.
[RMD] Westberg, L., Jacobsson, M., Partain, D.,
Karagiannis, G., Oosthoek, S., Rexhepi, V., Szabo,
R., Wallentin, P., "Resource Management in Diffserv
Framework", Internet draft, work in progress,
draft-westberg-rmd-framework-xx.txt, 2001.
[WROCHA] Wroclawski,J., Charny, A.,: "Integrated Service
Mappings for Differentiated Services
Networks", Internet Draft, work in progress,
draft-ietf-issll-ds-map-01.txt, 2001.
[To02] Thomas, M., "Analysis of Mobile IP and RSVP
Interactions", Internet Draft, work in progress.
draft-thomas-seamoby-rsvp-analysis-00.txt, 2001.
[ChNe98] Chiueh, T., Neogi, A., "Performance Evaluation of An
RSVP-Capable Router," in IEEE Real-Time Application
and Technology Symposium, June 1998.
http://www.ecsl.cs.sunysb.edu/tech_reports.html
[Pa01] Paskalis, S., et al., "RSVP Mobility Proxy", Internet
Draft, work in progress, draft-paskalis-rsvpmp-00.txt,
December 2001.
de Meer, et al. Expires December 2002 [Page 25]
Internet Draft Analysis of Existing QoS Solutions June 2002
9. Acknowledgments
Thanks to Istvan Cselenyi, Pontus Wallentin, Geert Heijenk and
Giussepe Bianchi for reviewing this draft and providing useful input.
10. Editors' Addresses
Hermann De Meer
Department of Electronic & Electrical Engineering
University College London
Torrington Place
London WC1E 7JE
Great Britain
EMail: H.DeMeer@ee.ucl.ac.uk
Piers O'Hanlon
Department of Electronic & Electrical Engineering
University College London
Torrington Place
London WC1E 7JE
Great Britain
EMail: P.OHanlon@cs.ucl.ac.uk
Gabor Feher
Budapest University of Technology and Economics
Department of Telecommunications and Telematics
Magyar tudosok korutja 2.; H-1117 Budapest; Hungary
Phone: +36 1 463 2187
EMail: feher@ttt-atm.ttt.bme.hu
Nicola Blefari-Melazzi
DIEI, University of Perugia
Via G. Duranti 93, 06125 Perugia, ITALY
Tel: +39 075 585 3630
EMail: blefari@diei.unipg.it
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6; 81739 Munchen; Germany
Email: Hannes.Tschofenig@mchp.siemens.de
Georgios Karagiannis
Ericsson EuroLab Netherlands B.V.
Institutenweg 25
de Meer, et al. Expires December 2002 [Page 26]
Internet Draft Analysis of Existing QoS Solutions June 2002
P.O.Box 645
7500 AP Enschede
The Netherlands
EMail: Georgios.Karagiannis@eln.ericsson.se
David Partain
Ericsson Radio Systems AB
P.O. Box 1248
SE-581 12 Linkoping
Sweden
EMail: David.Partain@ericsson.com
Vlora Rexhepi
Ericsson EuroLab Netherlands B.V.
Institutenweg 25
P.O.Box 645
7500 AP Enschede
The Netherlands
EMail: Vlora.Rexhepi@eln.ericsson.se
Lars Westberg
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
EMail: Lars.Westberg@era.ericsson.se
de Meer, et al. Expires December 2002 [Page 27]
Internet Draft Analysis of Existing QoS Solutions June 2002