Internet Draft Analysis of Existing QoS Solutions November 2001
Internet Engineering Task Force H. de Meer
INTERNET-DRAFT University College London, UK
Expires May 2002 G. Feher
University of Budapest, Hungary
N. Blefari-Melazzi
University of Perugia, Italy
G. Karagiannis
D. Partain
L. Westberg
Ericsson
November 2001
Analysis of Existing QoS Solutions
draft-demeer-nsis-analysis-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
Copyright Notice
de Meer, et al. Expires May 2002 [Page 1]
Internet Draft Analysis of Existing QoS Solutions November 2001
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This memo gives 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 on
networks 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 protocol
* Integrated Services over Differentiated Services
* Statically assigned trunk reservations based on
Differentiated Services
* Dynamic trunk reservations with Aggregated RSVP
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
de Meer, et al. Expires May 2002 [Page 2]
Internet Draft Analysis of Existing QoS Solutions November 2001
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.
"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
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 goal of this analysis is to understand whether the strict
QoS requirements imposed on networks by future fixed and mobile
applications are satisfied by the existing IP QoS solutions. The main
de Meer, et al. Expires May 2002 [Page 3]
Internet Draft Analysis of Existing QoS Solutions November 2001
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 reservation.
2. 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 communication path, and it can be used by an
application to make known and reserve its QoS requirements to all the
network nodes in this path. This type of protocol is typically
initiated by an application at the beginning of a communication
session. A communication session is typically identified by the
combination of the IP destination address, transport layer protocol
type and the destination port number. The resources reserved by such
a protocol for a certain communication session will be used for all
packets belonging to that particular session. 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
[RFC2210], [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
de Meer, et al. Expires May 2002 [Page 4]
Internet Draft Analysis of Existing QoS Solutions November 2001
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. The RSVP
protocol 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
An overview of the RSVP functionality includes:
* End-to-end reservation with aggregation of path
characteristics such as fixed delay.
* The same type of reservation functionality in all
routers. Only policy handling separates the edge of the
domain from other routers.
* Multicast and unicast reservations with receiver initiated
reservations. RSVP makes reservations for both unicast and
many-to-many multicast applications, adapting dynamically
to changing routes as well as to group membership.
* Shared reservations for multiple flows.
* Support for policy handling to handle multi-operator
situations since more than one operator will be responsible
for RSVP's operation.
* Flexible object definitions. RSVP can transport and maintain
traffic and policy control parameters that are opaque to
RSVP. Each RSVP message may contain up to fourteen classes of
attribute objects. Furthermore, each class of RSVP objects
de Meer, et al. Expires May 2002 [Page 5]
Internet Draft Analysis of Existing QoS Solutions November 2001
may contain multiple types to specify further the format
of the encapsulated data. Moreover, the signalling load
generated by RSVP on the routers is directly proportional
to the flows processed simultaneously by these routers.
Furthermore, processing of the individual flows in the
networking infrastructure may impose a significant processing
burden on the machines, thus hurting throughput. These
issues make it reasonable to question the scalability and
performance in a large network that supports a huge number
of users.
* Support for uni-directional reservations, but not
bi-directional. (In some wireless subnetworks, the initiation
of the reservations is done on a bi-directional basis.)
* Re-scheduling of signaling message in every router. The
re-scheduling of session refresh messages (aggregated and non
aggregated ones) depend on the router's own refresh period
timer. This means, for example, that when a session refresh
message arrives at a router at the beginning of a refresh
period it might have to be re-scheduled for re-sending to
the next hop at the end of the refresh period.
* Signalling initiation of RSVP error indication messages:
Any time that an erroneous situation occurs a router
initiates an RSVP error message.
In case of wireless networks, when a mobile host moves or the
connection moves from one base station to another, it could force the
communication path to change its (source/destination) IP address.
The change of IP address will require that RSVP establish a new RSVP
session through the new path that interconnects the two end points
involved in the RSVP session and release the RSVP session on the old
path. During this time, the end-to-end data path connection is
incomplete (i.e., QoS disruption), and it will negatively affect the
user performance.
RSVP includes much more functionality and complexity than is required
in some IP networks. The QoS problem in such networks is
significantly simpler to solve (see [WQOSREQ]). The tradeoff between
performance and functionality is one of the key issues in such
networks, and the majority of the functionality in RSVP is not
required. This is true for five reasons:
de Meer, et al. Expires May 2002 [Page 6]
Internet Draft Analysis of Existing QoS Solutions November 2001
* 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. In
this case, there is no need for the PATH messages.
This reduces the number of states in the routers.
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.
* Edge-to-edge with one operator 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.
* Initiation or re-scheduling of signalling messages might load
intermediate interior routers severely. There are different
reservation protocol approaches, where it is sufficient
that edge routers and/or signalling end-points initiate
or re-schedule all the signaling messages. In this case,
the intermediate interior routers only forward the messages
and use a dedicated field of the message to signal to other
routers. This approach lightens the load on the intermediate
interior routers.
3. 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
de Meer, et al. Expires May 2002 [Page 7]
Internet Draft Analysis of Existing QoS Solutions November 2001
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 (see Section 4).
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
de Meer, et al. Expires May 2002 [Page 8]
Internet Draft Analysis of Existing QoS Solutions November 2001
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
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 drawbacks described in Section 2, 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. This will be discussed in Section 5.
Other approaches related to the bandwidth broker concept are still
very immature and will not be discussed here.
4. Statically-assigned trunk reservations based on Differentiated
Services
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, no signalling protocol is required for
performing the reservation of network resources but is likely to be a
difficult management problem. However, due to the 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, it will be difficult to configure the
trunked reservations statically and at the same time utilize the
network efficiently.
In particular, and focusing on DiffServ [RFC2475], an important open
point is that such an architecture lacks a standardized admission
control scheme, and does not intrinsically solve the problem of
controlling congestion in the Internet. As previously explained in
Section 3, the edge nodes in the customer network will not be aware
de Meer, et al. Expires May 2002 [Page 9]
Internet Draft Analysis of Existing QoS Solutions November 2001
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]. Upon overload in a given service
class, all flows in that class suffer a potentially harsh degradation
of service. "A Framework for Integrated Services Operation over
Diffserv Networks" [RFC2998] recognizes this problem and points out
that "further refinement of the QoS architecture is required to
integrate DiffServ network services into an end-to-end service
delivery model with the associated task of resource reservation". It
is thus suggested [RFC2990] to define an "admission control function
which can determine whether to admit a service differentiated flow
along the nominated network path".
In the following we expand on this issue, in the framework of the
typical hybrid reference network shown in Figure 1, which includes a
DiffServ region in the middle of a larger network supporting IntServ
end-to-end. Notice that some of the following considerations also
apply to an all DiffServ network. In Figure 1, the source host Tx,
the destination host Rx, the Edge Routers (ER) and the Border Routers
(BR) execute the functions listed in [RFC2998]. In particular, we
assume that both sending and receiving hosts use RSVP to communicate
the quantitative QoS requirements of QoS-aware applications running
on the hosts. Obviously, admission control in the IntServ subnetworks
is signalled using RSVP.
________ ______________ ________
/ \ / \ / \
/ \ / \ / \
|---| | |---| |---| |---| |---| | |---|
|Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx |
|---| | |-- | |---| |---| |---| | |---|
\ / \ / \ /
\________/ \______________/ \________/
IntServ region DiffServ region IntServ region
Figure 1: Sample Network Configuration
Requests for IntServ services must be mapped onto the underlying
capabilities of the DiffServ network region. Aspects of such mapping
include [RFC2998]:
1. selecting an appropriate PHB, or a set of PHBs, for the
de Meer, et al. Expires May 2002 [Page 10]
Internet Draft Analysis of Existing QoS Solutions November 2001
requested service
2. performing appropriate policing (perhaps including
shaping or remarking) at the edges of the DiffServ region
3. exporting IntServ parameters from the DiffServ region
(e.g., for the updating of ADSPECs)
4. performing admission control on the IntServ requests
that takes into account the resource availability in the
DiffServ region.
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].
To this end, point 4 above, i.e., the admission control function is
key.
In fact, QoS aware services require that the amount of arriving
traffic be limited by suitable admission control. Two issues are of
interest [WROCHA]:
* the method used by the DiffServ cloud to determine whether
sufficient resources are available
* the method used by the overall network to query the DiffServ
cloud about this availability
Within the cloud, the admission control "mechanism" is closely
related to resource provisioning. If some form of static resource
provisioning is used, the admission control function can be performed
by any network component that is aware of this allocation, such as a
properly configured boundary router. If resource allocation within
the network cloud is dynamic (e.g., a dynamic "bandwidth broker" or
signalling protocol) then this protocol can also perform the
admission control function by refusing to admit new traffic when it
determines that it cannot allocate appropriate new resources.
The key to providing absolute, quantitative QoS services within a
de Meer, et al. Expires May 2002 [Page 11]
Internet Draft Analysis of Existing QoS Solutions November 2001
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
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. In reality, all four options may be
useful in different circumstances.
In any case, there need to be entities that are able to allow or
refuse service requests, possibly on the basis of resource
utilization. In other words, we also need an admission control
function acting on the DiffServ cloud. We can proceed along two
different routes:
* Define an admission control function that is also able
to operate WITHIN the DiffServ cloud. This could solve our
problem even in the case of isolated or all DiffServ networks
(that is, not part of an end-to-end RSVP loop).
* Export suitable characteristics of the Diffserv cloud toward
the IntServ part so that admission control can be performed
by the latter (that is, by RSVP).
In considering the second of these possibilities, in order to do this
de Meer, et al. Expires May 2002 [Page 12]
Internet Draft Analysis of Existing QoS Solutions November 2001
to provide Guaranteed Service, it would be necessary to export the
"error terms", referred to as C and D in the specification, which
would allow the customer to calculate the bandwidth to request from
the network in order to achieve a particular queuing delay target.
The difficulty in characterizing the parameters C and D is that,
unlike the IntServ model, where the C and D terms are a local
property of the router, in the case of DiffServ these terms depend
not only on the topology of the cloud, but also on the internal
traffic characteristics of potentially all traffic in the cloud
handled with the PHB chosen to support the Guaranteed Service.
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 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]) 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].
In conclusion, providing QoS aware service over a DiffServ cloud
without admission control functions able to operate within the cloud
itself potentially leads to severe inefficiencies. In fact, the
"worst case" provisioning model targeting a particular utilization
bound results in substantially more overprovisioning than the "point-
to-point" provisioning using an estimated traffic matrix, which in
turn is potentially more inefficient than explicit point-to point
bandwidth allocation using signalled admission control.
de Meer, et al. Expires May 2002 [Page 13]
Internet Draft Analysis of Existing QoS Solutions November 2001
This brings us to option 1 above, the definition of an admission
control function within the DiffServ region.
To this end, we cannot use explicit per flow signalling, for obvious
reasons (this would lead to a stateful architecture). Similarly, we
do not want to modify the basic router operation by introducing
packet marking schemes or forcing routers to parse and interpret
higher layer information. What we would like to do is to implicitly
convey the status of inner DiffServ routers to the edges of the cloud
(or to the end points, when the DiffServ net is an isolated one), by
means of scalable, DiffServ compliant procedures, so that suitable
devices can make appropriate admission control decisions without
violating the DiffServ paradigm. A possible way to do this has been
proposed in [RMD] and [BiaBle].
5. 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 2002 [Page 14]
Internet Draft Analysis of Existing QoS Solutions November 2001
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].
With regards to aggregated RSVP, 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 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]).
* 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.
de Meer, et al. Expires May 2002 [Page 15]
Internet Draft Analysis of Existing QoS Solutions November 2001
* 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.
6. Conclusions
This draft gives a brief analysis of existing IP QoS solutions and
accompanying signalling issues.
This analysis is done in order to understand whether the strict QoS
requirements imposed by future fixed and mobile applications on
networks are satisfied by the existing IP QoS solutions. This
analysis points out pending and open QoS signalling issues in the
existing QoS solutions. Given these results, we believe that
appropriate standardization should take place to create the necessary
protocols for QoS signalling.
7. 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.
[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.
[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.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, A.,
de Meer, et al. Expires May 2002 [Page 16]
Internet Draft Analysis of Existing QoS Solutions November 2001
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.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., Weiss, W., "An Architecture for Differentiated
Services", IETF RFC 2475, December 1998.
[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.
de Meer, et al. Expires May 2002 [Page 17]
Internet Draft Analysis of Existing QoS Solutions November 2001
8. Acknowledgments
Thanks to Vlora Rexhepi, Istvan Cselenyi, Pontus Wallentin, Geert
Heijenk and Giussepe Bianchi for reviewing this draft and providing
useful input.
9. 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
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
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
de Meer, et al. Expires May 2002 [Page 18]
Internet Draft Analysis of Existing QoS Solutions November 2001
Lars Westberg
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
EMail: Lars.Westberg@era.ericsson.se
Table of Contents
1 Introduction .................................................... 2
2 End-to-end per-flow resource reservation protocol ............... 4
3 Integrated Services over Differentiated Services ................ 7
4 Statically-assigned trunk reservations based on Differentiated
Services ..................................................... 9
5 Dynamic trunk reservations with Aggregated RSVP ................. 14
6 Conclusions ..................................................... 16
7 References ...................................................... 16
8 Acknowledgments ................................................. 18
9 Editors' Addresses .............................................. 18
de Meer, et al. Expires May 2002 [Page 19]