Internet DRAFT - draft-demeer-nsis-analysis
draft-demeer-nsis-analysis
Internet Draft Analysis of Existing QoS Solutions November 2002
Internet Engineering Task Force H. de Meer
INTERNET-DRAFT Piers O'Hanlon
Expires May 2003 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
November 2002
Analysis of Existing QoS Solutions
draft-demeer-nsis-analysis-03.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 May 2003 [Page 1]
Internet Draft Analysis of Existing QoS Solutions November 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 signalling issues. This analysis is
intended to point out open issues in QoS signalling. Moreover, this
analysis is done in order to understand whether the strict QoS
requirements imposed by future fixed and mobile applications are
satisfied by the existing IP QoS solutions. 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
* Traffic Engineering Tunnels and RSVP
de Meer, et al. Expires May 2003 [Page 2]
Internet Draft Analysis of Existing QoS Solutions November 2002
Table of Contents
1 Introduction ................................................. 4
2 Issues Used in the Analysis .................................. 6
3 End-to-end per-flow resource reservation protocol ............ 6
4 Integrated Services over Differentiated Services ............. 9
5 Statically-assigned trunk reservations based on DiffServ ..... 14
6 Dynamic trunk reservations with Aggregated RSVP .............. 17
7 Traffic Engineering Tunnels and RSVP ......................... 20
8 Conclusions .................................................. 22
9 References ................................................... 25
10 Acknowledgments ............................................. 28
11 Editors' Addresses .......................................... 28
de Meer, et al. Expires May 2003 [Page 3]
Internet Draft Analysis of Existing QoS Solutions November 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.
* Signalling 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 signalling
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 and therefore placing incentives on limiting
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
deterrents to widespread deployment... There appears to be no single
comprehensive service environment that possesses both service
de Meer, et al. Expires May 2003 [Page 4]
Internet Draft Analysis of Existing QoS Solutions November 2002
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. Signalling would similarly
reflect the right level of granularity and could be implicit or
explicit. For example, RSVP [RFC2205], one of most prominent
signalling 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 signalling issues. The analysis is intended to point
out open QoS signalling 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 signalling 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
configured by using a signalling protocol that manages
various mechanisms for dynamic creation of an aggregate
de Meer, et al. Expires May 2003 [Page 5]
Internet Draft Analysis of Existing QoS Solutions November 2002
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
* Security Issues
3. End-to-end per-flow resource reservation protocol
An end-to-end per-flow resource reservation signalling 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
de Meer, et al. Expires May 2003 [Page 6]
Internet Draft Analysis of Existing QoS Solutions November 2002
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 signalling packets will include details of
the session to which they belong.
The end-to-end per-flow resource reservation signalling 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
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.
de Meer, et al. Expires May 2003 [Page 7]
Internet Draft Analysis of Existing QoS Solutions November 2002
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]).
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 signalling session. All of these
messages are sent per-flow, thus the number of messages received by
a signalling communication host increases linearly proportional to the
number of flows, i.e. RSVP signalling 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
--------------------
de Meer, et al. Expires May 2003 [Page 8]
Internet Draft Analysis of Existing QoS Solutions November 2002
RSVP 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 re-initiated.
Issues related to the Mobile IP and RSVP are explained in
detail in [To01], [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
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
de Meer, et al. Expires May 2003 [Page 9]
Internet Draft Analysis of Existing QoS Solutions November 2002
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 signalling) 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
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 signalling 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 signalling 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 signalling 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 signalling 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
de Meer, et al. Expires May 2003 [Page 10]
Internet Draft Analysis of Existing QoS Solutions November 2002
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 signalling protocols other than
RSVP. In fact, IntServ, RSVP and services classes are all separable.
IntServ is the specific architecture or model, RSVP the specific
signalling 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,
signalling 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
de Meer, et al. Expires May 2003 [Page 11]
Internet Draft Analysis of Existing QoS Solutions November 2002
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 signalling element in the whole framework as presented in
RFC2998. Signalling 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,
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,
signalling 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 signalling 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.
de Meer, et al. Expires May 2003 [Page 12]
Internet Draft Analysis of Existing QoS Solutions November 2002
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
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.
de Meer, et al. Expires May 2003 [Page 13]
Internet Draft Analysis of Existing QoS Solutions November 2002
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 signalling 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.
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 signalling 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
de Meer, et al. Expires May 2003 [Page 14]
Internet Draft Analysis of Existing QoS Solutions November 2002
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
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 May 2003 [Page 15]
Internet Draft Analysis of Existing QoS Solutions November 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 May 2003 [Page 16]
Internet Draft Analysis of Existing QoS Solutions November 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
signalling 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 signalling 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.
de Meer, et al. Expires May 2003 [Page 17]
Internet Draft Analysis of Existing QoS Solutions November 2002
One example of a protocol that can be used to accomplish QoS dynamic
provisioning via trunk reservations is the RSVP Aggregation
signalling 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 the aggregated RSVP sessions depends on:
* The number of Aggregators/Deaggregators: this depends on the
number of the edge nodes used. For example, in an IP-based
wireless network, the number of the edge nodes can depend on
the 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 May 2003 [Page 18]
Internet Draft Analysis of Existing QoS Solutions November 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 applied in mobile networks,
in a handover event a new signaling session needs to be re-initiated.
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
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.
de Meer, et al. Expires May 2003 [Page 19]
Internet Draft Analysis of Existing QoS Solutions November 2002
7. Traffic Engineering Tunnels and RSVP
Traffic engineering function enables efficient and reliable network
operations as well as optimal utilization of expensive network
resources in large networks. Multiprotocol Label Switching (MPLS)
[RFC 2702] is an advanced packet forwarding mechanism used for
traffic engineering. MPLS assign labels to packets that determine
the forwarding of the packets, differently from the Layer 3 forwading
which is based on routing tables. This packet forwarding will create
topology driven paths through the network as each MPLS-capable
router, called also Label Switching Router (LSR), forwards the
packets that it receives based on the label. In this way the Label
Switched Paths (LSP) are set between ingress/egress pairs of MPLS-
capable routers. Several flows can be forwarded along the same LSP,
provided that they are assigned the same label at the ingress node of
the LSP. Due to this feature the LSP may be treated as tunnels
[RFC3209].
RSVP-TE [RFC3209] describes the RSVP extensions needed for
establishing LSPs tunnels in MPLS. The LSP tunnels enable a variety
of network optimization policies as they can be routed explicitly in
order to avoid congestion, bottlenecks and network failures. There
can be several LSP tunnels set by means of RSVP-TE between two
endpoints. All the packets, regardless of the traffic flow they
belong to, which are assigned the same label as the LSP by a
particular ingress node will be routed through this tunnel. The
packets with the same label value belong to the same forwarding
equivalence class (FEC) [RFC2702].
The extensions to RSVP are five new objects (LABEL_REQUEST (Path),
LABEL (Resv), EXPLICIT_ROUTE (Path), RECORD_ROUTE (Path,Resv),
SESSION_ATTRIBUTE (Path))added to PATH and RESV messages
respectively. Although RSVP-TE protocol is to be used mainly in
traffic engineering it can be also used in any application using
aggregation based on labels.
Reservation State
-----------------
The RSVP-TE Reservation state is a per LSP tunnel state. As in RSVP,
the reservation state management is a combination of the soft state
principle and explicit release.
Note that the RSVP-TE can be used to setup LSP tunnels without
allocating any resources, that is without resource reservations.
de Meer, et al. Expires May 2003 [Page 20]
Internet Draft Analysis of Existing QoS Solutions November 2002
The LSP tunnels and the resource reservation are maintained by means
of refresh messages sent by the endpoints of the LSP tunnel. The
explicit release of LSP tunnels and resource reservations respectively
is done by means of explicit release messages that are send by the
endpoints.
Scalability
-----------
The number of the RSVP-TE messages is linearly proportional to the
number of the supported LSP tunnels. Note that the number of
supported LSP tunnels is much less than the number of micro-flows.
RSVP-TE installs and maintains one state per label, i.e. per LSP
tunnel. The packet flow classification and filtering will be done
based on this label only, which is much more simple and scalable than
the RSVP itself. However this requires a mechanism based on label
switching such as MPLS.
Support for Mobility
--------------------
RSVP-TE does not support mobility and as such it is not designed to
support handovers. When RSVP-TE is used in the core network then
mobility is usually not a problem. However using RSVP-TE in the
access network effects roaming mobile nodes that may require new
labels and the re-mapping into other LSP tunnels.
Security Issues
---------------
If RSVP-TE is used to distribute MPLS labels within a single
administrative domain then security protection as described in [RFC2747]
can be used. However, [RFC2747] requires that key mangement is done
offline. Within a single administrative domain this might be reasonable
approach. It is furthermore assumed that each node knows its next MPLS
node along the path either due to pre-configuration or because of
supplied route object. The protection offered by [RFC2747] offers data
origin authentication, integrity and reply protection. Confidentiality
protection and other security properties such as (identity confidentiality,
etc.) is not provided but might not required in this context. If the
signaling exchange is limited to a single administrative domain then the
concept of network topology hiding is also not applicable. Handling of
de Meer, et al. Expires May 2003 [Page 21]
Internet Draft Analysis of Existing QoS Solutions November 2002
policies as described in [RFC3182] does not seem to be used. Authorization,
which is typically an important step in RSVP when used for QoS, does not
seem to play an important role if RSVP-TE is only used for label
distribution.
If the label distribution is not limited to a single administrative
domain then additional security mechanisms require considerations. In
such a case it must not be possible for an unauthorization entity to
add, modify or remove LPS. A full range of attacks would be possible
without proper protection.
To allow secure data communication between different MPLS domains
over IP domains IPSec protection of MPLS data packets might be used as
described in [RoCl02]. An interesting approach for applying IPSec
protection to MPLS packets is described in [Sen02]. An accompanying draft
explains a procedure to establish the required security associations
is described in[Sendoi02].
Additional MPLS specific security issues are described in [Beh02].
8. Conclusions
This draft provides a brief analysis of existing IP QoS solutions and
accompanying signalling 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 more 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
de Meer, et al. Expires May 2003 [Page 22]
Internet Draft Analysis of Existing QoS Solutions November 2002
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.
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].
* 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
signalling protocol. It specifies a framework with an implicit QoS
signalling 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
de Meer, et al. Expires May 2003 [Page 23]
Internet Draft Analysis of Existing QoS Solutions November 2002
[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 (handover) 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
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.
RSVP-TE [RFC3209] describes the RSVP extensions needed for
establishing LSPs tunnels in MPLS. The LSP tunnels enable a variety
of network optimization policies as they can be routed explicitly in
order to avoid congestion, bottlenecks and network failures. There
can be several LSP tunnels set by means of RSVP-TE between two
endpoints. All the packets, regardless of the traffic flow they
belong to, which are assigned the same label as the LSP by a
particular ingress node will be routed through this tunnel. The
packet classification and scheduling is done based on this label
de Meer, et al. Expires May 2003 [Page 24]
Internet Draft Analysis of Existing QoS Solutions November 2002
only, which is much more simple and scalable than the RSVP itself.
However this requires a mechanism based on label switching such as
MPLS.
This analysis points out pending and open QoS signalling issues
related to reservation state management, scalability, support for
mobility and security issues of the main existing IP QoS solutions
([RFC2205], [RFC2998], [RFC2475], [RFC3175], [RFC3209]). Given this
analysis, we believe that appropriate standardization should take
place to create the necessary protocols for QoS signalling.
9. 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.
[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,
de Meer, et al. Expires May 2003 [Page 25]
Internet Draft Analysis of Existing QoS Solutions November 2002
V., Westberg, L., Zheng, H., "NSIS QoS Signalling
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
Signalling 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
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
de Meer, et al. Expires May 2003 [Page 26]
Internet Draft Analysis of Existing QoS Solutions November 2002
Reservations", IETF RFC 3175, 2001.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell M.,
McManus, J., "Requirements for Traffic Engineering Over
MPLS", IETF RFC 2702, September 1999.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels",
IETF RFC3209, 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.
[RoCl02] Rosen, E., De Clercq, J., Paridaens, O., T'Joens, Y.,
Sargor, C.: "Use of PE-PE IPsec in RFC2547 VPNs",
Internet draft, work in progress,
draft-ietf-ppvpn-ipsec-2547-02.txt, August 2002.
[Beh02] Behringer, M.: "Analysis of the Security of the MPLS
Architecture", Internet draft, work in progress,
draft-behringer-mpls-security-02.txt, June 2002.
[Sen02] Senevirathne, T.: "Secure MPLS - Encryption and
Authentication of MPLS payloads", Internet draft, work
de Meer, et al. Expires May 2003 [Page 27]
Internet Draft Analysis of Existing QoS Solutions November 2002
in progress, draft-tsenevir-smpls-02.txt, July 2002.
[Sendoi02] Senevirathne, T.: "Secure MPLS Domain of Interpretation for
ISAKMP", Internet draft, work in progress,
draft-tsenevir-smpls-doi-01.txt, July 2002.
10. Acknowledgments
Thanks to Istvan Cselenyi, Pontus Wallentin, Geert Heijenk and
Giussepe Bianchi for reviewing this draft and providing useful input.
11. 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
de Meer, et al. Expires May 2003 [Page 28]
Internet Draft Analysis of Existing QoS Solutions November 2002
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
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 May 2003 [Page 29]
