Internet Draft Analysis of Existing QoS Solutions May 2002
Internet Engineering Task Force H. de Meer
INTERNET-DRAFT Piers O'Hanlon
Expires November 2002 University College London, UK
G. Feher
University of Budapest, Hungary
N. Blefari-Melazzi
University of Perugia, Italy
G. Karagiannis
D. Partain
V. Rexhepi
L. Westberg
Ericsson
May 2002
Analysis of Existing QoS Solutions
draft-demeer-nsis-analysis-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
de Meer, et al. Expires November 2002 [Page 1]
Internet Draft Analysis of Existing QoS Solutions May 2002
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
de Meer, et al. Expires November 2002 [Page 2]
Internet Draft Analysis of Existing QoS Solutions May 2002
Table of Contents
1 Introduction ................................................. 4
2 Criteria used in the analysis ................................ 6
3 End-to-end per-flow resource reservation protocol ............ 6
3.1 Analysis based on requirements in [Brun02] ................. 7
3.2 Analysis based on open issues in [Brun02] .................. 14
3.3 Analysis based on requirements in [PaKa02] ................. 15
4 Integrated Services over Differentiated Services ............. 16
4.1 Analysis based on requirements in [Brun02] ................. 18
4.2 Analysis based on open issues in [Brun02] .................. 25
4.3 Analysis based on requirements in [PaKa02] ................. 26
5 Statically-assigned trunk reservations based on DiffServ ..... 28
5.1 Analysis based on requirements in [Brun02] ................. 30
5.2 Analysis based on open issues in [Brun02] .................. 36
5.3 Analysis based on the requirements in [PaKa02] ............. 37
6 Dynamic trunk reservations with Aggregated RSVP .............. 38
6.1 Analysis based on the requirements in [Brun02] ............. 39
6.2 Analysis based on open issues in [Brun02] .................. 45
6.3 Analysis based on requirements in [PaKa02] ................. 47
7 Conclusions .................................................. 48
8 References ................................................... 51
9 Acknowledgments .............................................. 53
10 Editors' Addresses .......................................... 53
de Meer, et al. Expires November 2002 [Page 3]
Internet Draft Analysis of Existing QoS Solutions May 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.
"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
de Meer, et al. Expires November 2002 [Page 4]
Internet Draft Analysis of Existing QoS Solutions May 2002
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
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.
de Meer, et al. Expires November 2002 [Page 5]
Internet Draft Analysis of Existing QoS Solutions May 2002
2. Criteria used in the analysis
This section lists the criteria that are used for analyzing the
existing QoS solutions explained in this draft. These criteria are:
* The requirements in "Requirements for QoS Signalling
Protocols" [Brun02].
* Several open issues included in [Brun02].
* Several requirements included in "NSIS QoS Signalling
Requirements" [PaKa02]
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 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
[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
de Meer, et al. Expires November 2002 [Page 6]
Internet Draft Analysis of Existing QoS Solutions May 2002
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
3.1. Analysis based on requirements in [Brun02]
This section describes the analysis of RSVP (described in [RFC2205])
using the criteria that are based on the requirements in [Brun02].
The number enclosed between the brackets is the section number in
[Brun02] where the requirement is described. For the complete
description of these requirements, refer to [Brun02].
[5.1.1] - Applicability for different QoS technologies:
RSVP was developed to be used in the Integrated Services
architecture, although it can be used with other QoS technologies
as well. However, even though the information exchanged over the
signalling protocol is detailed enough and useful for various QoS
technologies, there is still a need for mapping of this
information into understandable format for other QoS technologies,
e.g. mapping of IntServ type of services to DiffServ type of
services.
[5.1.2] - Resource availability information on request:
RSVP does not have functionality that makes it possible to query
for available resources without performing a reservation of the
resource.
[5.1.3] - Modularity:
RSVP is a flexible protocol in the sense that it defines a
flexible set of objects. However, RSVP does not support
modularity as it does not allow for more lightweight
implementations, if fewer features are needed in certain parts of
the network.
de Meer, et al. Expires November 2002 [Page 7]
Internet Draft Analysis of Existing QoS Solutions May 2002
[5.1.4] - Decoupling of protocol and information it is carrying:
RSVP does not support this requirement. The signalling protocol(s)
is not separated from the QoS control information it is
transporting.
[5.1.5] - Reuse of existing QoS provisioning:
From the RSVP perspective, this requirements is irrelevant as the
motivation for it is not to 're-invent the wheel' but to reuse
existing QoS functions and protocols for QoS provisioning within a
domain/subdomain unchanged, to which RSVP belongs as well.
[5.1.7] - Independence of signalling and provisioning paradigm:
RSVP provides independence of signalling and provisioning
mechanisms.
[5.2.1] - Free placement of QoS Initiator and QoS Controllers
functions:
RSVP is designed as a protocol that is initiated and terminated by
end hosts. This means that the QoS Initiator and QoS Controllers
reside at the end hosts, and they cannot be placed freely in the
communication path. However, extensions to RSVP (e.g., RSVP
proxy, RSVP-TE, IntServ over DiffServ) have made it possible to
apply the protocol in scenarios other than end-to-end signalling
scenarios, such as edge-to-edge, (e.g., just within one providers
domain), user-to-network (from end system into the network,
ending, e.g., at the entry to the network and vice versa),
network-to-network (e.g., between providers).
[5.2.2] - No constraint of the QoS signalling and QoS Controllers to
be in the data path:
RSVP does not fulfill this requirement as the signalling is bound
to the data path.
[5.2.3] - Concealment of topology and technology information:
RSVP supports this requirements as it can be forwarded
transparently through the network.
[5.3.1] - Explicit release of resources:
de Meer, et al. Expires November 2002 [Page 8]
Internet Draft Analysis of Existing QoS Solutions May 2002
RSVP supports explicit release of resources by means of RESV
TEARDOWN message.
[5.3.2] - Possibility for automatic release of resources:
After failure, RSVP partially supports this feature since the
reservation state management is a combination of the soft state
principle and explicit release. The reserved resources will be
released if not refreshed in a certain period of time. This means
that in case of a failure there will be no refresh messages sent
and as a result the resources will be released. However,
automatic release of the resources is not supported in RSVP. PATH
TEARDOWN can only be sent by the sender end host and the RESV
TEARDOWN message can only be sent by the receiver end-host.
[5.3.3] - Possibility for automatic re-setup of resources after
recovery:
RSVP does not support this requirement.
[5.3.4] - Prompt notification of QoS violation in case of error or
failure to QoS Initiator and QoS Controllers:
RSVP supports this requirement by means of error messages, i.e.
PATH Error and RESV Error and also Error Object.
[5.3.5] - Feedback about success of request for QoS guarantees:
In RSVP, the success of resource request is reported by a
successful admission control function. However, there is no
further information given related to it.
[5.4.1] - The signalling protocol and QoS control information should
be application independent:
RSVP itself is application independent, but the applications that
use RSVP to signal their requirements to network elements have to
be RSVP-aware.
[5.5.1] - Mutability information on parameters:
RSVP supports this requirement by means of ADSPEC object in the
PATH message.
[5.5.2] - Possibility to add and remove local domain information:
de Meer, et al. Expires November 2002 [Page 9]
Internet Draft Analysis of Existing QoS Solutions May 2002
RSVP is a flat protocol with the same functionality in every node
in the communication path. As such it does not support this
requirement.
[5.5.3] - Independence of reservation identifier:
RSVP does not support this requirement as the reservation is
identified by means of the flow identifier.
[5.5.4] - Seamless modification of already reserved QoS:
RSVP supports this requirement by means of refresh messages and
the modify function in traffic admission control.
[5.5.5] - Signalling must support quantitative, qualitative, and
relative QoS specifications:
This requirement is supported by RSVP as it enables signalling for
IntServ services, i.e. Guaranteed and Controlled service.
[5.6.1] - Scalability in the number of messages received by a
signalling communication partner (QoS initiator and controller):
There are seven types of messages defined in RSVP that are 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 partner
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.
[5.6.2] - Scalability in number of hand-offs:
RSVP does not support hand-offs, therefore nothing can be said
related to this requirement.
[5.6.3] - Scalability in the number of interactions for setting up a
reservation:
The reservation setup by means of RSVP requires two interactions:
- PATH message sent from the sender to the receiver
- RESV message sent from the receiver to the receiver
This needs to be done for each flow. As in the previous
requirement this will scale well in those type of networks where
de Meer, et al. Expires November 2002 [Page 10]
Internet Draft Analysis of Existing QoS Solutions May 2002
the number of flows is modest, but it may introduce scalability
problems in network with a large number of flows.
[5.6.4] - Scalability in the number of states per entity (QoS
initiators and QoS controllers):
RSVP installs one reservation state per flow. This means that 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.
[5.6.5] - Scalability in CPU use (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.
[5.6.6] - Low latency in setup:
The reservation setup in RSVP is dependent on the RTT of
signalling messages. However, this RTT in any case will be shorter
than of common IP packets as the RSVP signalling messages are sent
with the IP router alert option set that enables faster processing
in the routers.
[5.6.7] - Allow for low bandwidth consumption for signalling
protocol:
Not applicable.
[5.6.8] - Ability to constrain load on devices:
RSVP does not support this requirement.
[5.7.1] - Aggregation capability, including the capability to select
and change the level of aggregation:
RSVP does not support this requirement.
de Meer, et al. Expires November 2002 [Page 11]
Internet Draft Analysis of Existing QoS Solutions May 2002
[5.7.2] - Flexibility in the placement of the QoS initiator:
RSVP does not support this requirement.
[5.7.3] - Flexibility in the initiation of re-negotiation (QoS change
requests):
RSVP supports this requirement by means of refresh messages and
modify admission control functions.
[5.7.4] - Uni / bi-directional reservation:
RSVP does support uni-directional reservation, but it does not
support bi-directional reservations.
[5.8.1] - The QoS protocol must provide strong authentication:
RSVP supports this requirement by means of the Integrity object
[RFC2747].
[5.8.2] - The QoS protocol must provide means to authorize resource
requests:
RSVP supports this requirement by means of the Policy object.
[5.8.3] - The QoS signalling messages must provide integrity
protection:
RSVP supports this requirement by means of the Integrity object.
[5.8.4] - The QoS signalling messages must be replay protected:
RSVP supports this requirement by means of Path State Base (PSB)
and Reservation State Base (RSB).
[5.8.5] - The QoS signalling protocol must allow for hop-by-hop
security:
RSVP supports this requirement by means of the Integrity object
[RFC2747].
[5.8.6] - The QoS protocol should allow identity confidentiality and
location privacy:
RSVP supports this requirement by means of the Integrity object.
de Meer, et al. Expires November 2002 [Page 12]
Internet Draft Analysis of Existing QoS Solutions May 2002
[5.8.7] - The QoS protocol should prevent denial-of-service attacks
against signalling entities:
RSVP supports this requirement by means of the Integrity object.
[5.8.8] - The QoS protocol should support confidentiality of
signalling messages:
RSVP supports this requirement by means of the Integrity object.
[5.8.9] - The QoS protocol should provide hooks to interact with
protocols that allow the negotiation of authentication and key
management protocols:
RSVP supports this requirement by means of the Integrity object.
[5.8.10] - The QoS protocol should provide means to interact with key
management protocols:
RSVP supports this requirement partially as the key management is
actually used in the Integrity object.
[5.10.1] - Interworking with IP tunneling:
RSVP supports RSVP tunneling [RFC2746].
[5.10.2] - The solution should not constrain either to IPv4 or IPv6:
RSVP supports this requirement.
[5.10.3] - Independence from charging model:
RSVP supports this requirement.
[5.10.4] - The QoS protocol should provide hooks for AAA protocols:
RSVP does not support this requirement.
[5.11.1] - Ability to assign transport quality to signalling
messages:
RSVP supports this requirement by means of IP router alert option,
because given this and RSVP protocol number, the RSVP signalling
messages are processed faster in the routers. This enables certain
transport quality.
de Meer, et al. Expires November 2002 [Page 13]
Internet Draft Analysis of Existing QoS Solutions May 2002
3.2. Analysis based on open issues in [Brun02]
This section describes the analysis of RSVP (described in [RFC2205])
using the criteria that are based on the open issues in [Brun02].
The number in brackets is the number of the open issue used in
[Brun02], where the issue is described. For the description of these
open issues, refer to [Brun02].
[2] - Open issue 2: Sender/receiver initiation, Sender initiated a
MUST, receiver initiated a MAY:
RSVP is a receiver-initiated protocol, thus it does not support
this requirement.
[8] - Open issue 8: Bi-directional data path setup with one QoS
request:
RSVP does not support bi-directional data path setup with a single
QoS request. It can only support bi-directional requests as a
combination of two single uni-directional requests.
[33] - Open issue 33: Highest possible network utilization:
RSVP provides high network utilization up to the point where the
scalability of the network is not affected.
[36] - Open issue 36: Independence of reservation identifier:
RSVP does not support this requirement (see above).
[53] - Open issue 53: this open issue is a requirement described in
Section 5.1.16. of [PaKa02] - Error handling and redundancy
considerations:
RSVP supports this requirement by means of the error signalling
messages.
[55] - Open issue 55: this open issue is a requirement described in
Section 5.2.2. of [PaKa02] - Allow local QoS information exchange
between two border nodes:
RSVP is an end-to-end protocol and as such does not support any
information exchange between the border nodes.
de Meer, et al. Expires November 2002 [Page 14]
Internet Draft Analysis of Existing QoS Solutions May 2002
[59] - Open issue 59: this open issue is a requirement described in
Section 5.3.4. of [PaKa02] - "Ability to deal with severe
congestion":
RSVP supports this requirement.
[60] - Open issue 60: this open issue is a requirement described in
Section 5.4.3. of [PaKa02] - "Allow efficient QoS re-establishment
after handover":
RSVP does not support mobility. As such it does not allow
efficient QoS re-establishment after handover as in these cases it
needs to re-initiate a new signalling session.
3.3. Analysis based on requirements in [PaKa02]
This section describes the analysis of RSVP (described in [RFC2205])
using the criteria that are based on the requirements described in
[PaKa02].
The number enclosed between the brackets is the section number in
[PaKa02] where the requirement is described. For the complete
description of these requirements, refer to [PaKa02].
[5.2.3] - Allow generation of local QoS signalling messages:
RSVP does not support generation of local QoS signalling messages.
[5.3.1.1] - Modular:
RSVP is not modular.
[5.3.1.2] - Simple:
RSVP is very flexible, and can be applicable in many and different
scenarios. This increases its complexity.
[5.3.1.3] - Minimal Impact on Performance:
Due to its complexity RSVP impacts the performance of the interior
nodes.
[5.3.2] - Ability to deal with mobility (handover):
de Meer, et al. Expires November 2002 [Page 15]
Internet Draft Analysis of Existing QoS Solutions May 2002
RSVP cannot efficiently support this requirement.
[5.3.3] - On-demand, dynamic signalling for efficient network
utilization:
RSVP provides on-demand and dynamic signalling.
[5.3.4] - Ability to deal with severe congestion:
RSVP is able to support severe congestion solutions.
[5.3.5] - Optimize for unicast transport:
RSVP is not optimized for unicast reservations.
[5.3.6] - Ability to transparently traverse an interior node:
This requirement can be supported by RSVP when traversing non-RSVP
aware nodes.
[5.3.7] - Use of a simple QoS parameter:
RSVP uses more than one QoS parameters (TSPEC, RSPEC, ADSPEC).
4. Integrated Services over Differentiated Services
The IntServ over DiffServ architecture addresses the problem of
providing end-to-end QoS using the IntServ model over heterogeneous
networks. In this scenario, DiffServ is one of these networks
providing edge-to-edge QoS.
The IntServ over DiffServ architecture allows at least two different
possible deployment strategies. The first is based on statically
allocated resources in the DiffServ domain. In this strategy, the
DiffServ domain is statically provisioned. Furthermore, with this
strategy the devices in the DiffServ network region are not RSVP (or
any other dynamic 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
de Meer, et al. Expires November 2002 [Page 16]
Internet Draft Analysis of Existing QoS Solutions May 2002
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
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
de Meer, et al. Expires November 2002 [Page 17]
Internet Draft Analysis of Existing QoS Solutions May 2002
allocated using Aggregated RSVP.
Other approaches related to the bandwidth broker concept are still
very immature and will not be discussed here.
4.1. Analysis based on requirements in [Brun02]
This section describes the analysis of the IntServ over DiffServ
protocol described in [RFC2998] using the criteria that are based on
the requirements in [Brun02].
The number enclosed between the brackets is the section number in
[Brun02] where the requirement is described. For the complete
description of these requirements, refer to [Brun02].
[5.1.1] - Applicability for different QoS technologies:
IntServ architecture provides a means for end-to-end QoS over
heterogeneous networks. In particular, a network element that
supports DiffServ can be seen as network element of a specific
type in the total end-to-end path.
[5.1.2] - Resource availability information on request:
RSVP as the signalling protocol can be used to capture resource
availability information for the IntServ capable network segments.
In cases where the DiffServ domain is also RSVP aware, this
information would also be available for DiffServ subnets. RSVP is
seen as a method for dynamic provisioning and for providing
feedback information on resource availability. However, RSVP by
itself does not support this requirement as it does not check the
resource availability without actual resource reservation.
[5.1.3] - Modularity:
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.
de Meer, et al. Expires November 2002 [Page 18]
Internet Draft Analysis of Existing QoS Solutions May 2002
IntServ and DiffServ can almost orthogonally combined with each
other in either mode as discussed here.
[5.1.4] - Decoupling of protocol and information it is carrying:
RSVP can be used as a more general signalling vehicle and applied
in other contexts and convey information other than what is needed
for Controlled Load and Guaranteed Services. In particular, RSVP
can be used to perform bandwidth (or more general profile-based)
reservations in DiffServ domains, that is, for behavior
aggregates.
[5.1.5] - Reuse of existing QoS provisioning:
Overprovisioning, static or dynamic provisioning, all apply
equally well. Important for provisioning is mapping on the
underlying link technology. Note, one type of "link" could be
DiffServ within an end-to-end IntServ path. But other link
technologies have to be taken into account for provisioning as
well, eg. 802.1, 802.11, etc. (see RFC 2815).
[5.1.7] - Independence of signalling and provisioning paradigm:
This does not seem to be true as signalling has widely been used
for provisioning in DiffServ (and of course in IntServ) This is
probably often the case if BW resources other than best-effort
type are involved.
[5.2.1] - Free placement of QoS Initiator and QoS Controllers
functions:
QoS controllers are the network elements, e.g., the routers and
links. QoS initiators are the applications on the attached hosts.
But network elements can be more complex entities such as whole
sub-networks. In [RFC2998] it does not seem to be anticipated to
have complete freedom in placement of initiators and controllers.
Some flexibility may be availble, however: edge vs. border, vs.
node, for example.
[5.2.2] - No constraint of the QoS signalling and QoS Controllers to
be in the data path:
In the IntServ domain QoS signalling and control are performed in
the data path while in DiffServ domains possible segments within
the end-to-end path allow both forms: signalling and control in-
de Meer, et al. Expires November 2002 [Page 19]
Internet Draft Analysis of Existing QoS Solutions May 2002
band or out-of-band or a combination of both.
[5.2.3] - Concealment of topology and technology information:
This does not seem to be generally the case, in particular in the
mapping process.
[5.3.1] - Explicit release of resources:
The IntServ model is based on soft state and time out of
reservations. Explicit release is possible, however, in some
DiffServ networks with an implementation of dynamic SLAs (dynamic
conditioners such as in the Adaptive Segmented Adaptation
framework).
[5.3.2] - Possibility for automatic release of resources after
failure:
IntServ supports automatic release of resources after failure or
any other event making the reservation obsolete. If the
reservation state is not refreshed repeatedly it will expire
automatically. IntServ is fail safe in that respect. This is not
true for DiffServ network elements.
[5.3.3] - Possibility for automatic re-setup of resources after
recovery:
An automatic recovery has not been incorporated.
[5.3.4] - Prompt notification of QoS violation in case of error /
failure to QoS Initiator and QoS Controllers:
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.
[5.3.5] - Feedback about success of request for QoS guarantees:
de Meer, et al. Expires November 2002 [Page 20]
Internet Draft Analysis of Existing QoS Solutions May 2002
This is provided in IntServ, widely realized in dynamically
provisioned DiffServ with RSVP as the signalling mechanism.
[5.4.1] - The signalling protocol and QoS control information should
be application independent:
Similar to RSVP.
[5.5.1] - Mutability information on parameters:
This does not seem to hold for the framework as discussed in
RFC2998.
[5.5.2] - Possibility to add and remove local domain information:
This is certainly the case for DiffServ network elements. Maybe it
can be extended however. Extensions are possible in terms of
additional control information that can be exploited by signalling
such as RSVP. In particular, for specific link types, congestion
avoidance strategies, etc. However, that seems to be lacking in
RFC2998. It could, however, easily be extended, it seems. IntServ
also allows some local domain info to be manipulated.
[5.5.3] - Independence of reservation identifier:
This can be accomplished only within the DiffServ domain but not
end-to-end.
[5.5.4] - Seamless modification of already reserved QoS:
In IntServ domains reservation states can be dynamically changed.
It should be seamless. But it is not certain what happens if an
increase of reservation fails, if that could lead to a disruption.
Change of reservation state in DiffServ clouds is not always
possible. DiffServ network regions may be statically provisioned.
A dynamic change of reservation state may be disruptive in RSVP-
aware DiffServ regions as, for example, admission control and
paths may be decoupled in case only edge routers are RSVP-capable.
If interior routers are also RSVP-capable, more detailed
reservation state information can be signalled and modified
explicitly.
[5.5.5] - Signalling must support quantitative, qualitative, and
relative QoS specifications:
de Meer, et al. Expires November 2002 [Page 21]
Internet Draft Analysis of Existing QoS Solutions May 2002
IntServ and RSVP support quantitative (guarantee), qualitative
(controlled load) and relative (best effort) services. In
DiffServ, EF and various AF classes fulfill these requirements.
With appropriate mappings (guarantee over EF) end-to-end services
can be generated.
[5.6.1] - Scalability in the number of messages received by a
signalling communication partner (QoS initiator and controller):
DiffServ network elements are introduced to improve scalability in
core networks. Open issues are signalling and provisioning
overhead that could reduce scalability again if applied
dynamically.
[5.6.2] - Scalability in number of hand-offs:
Not applicable.
[5.6.3] - Scalability in the number of interactions for setting up a
reservation:
Same arguments as in [5.6.1].
[5.6.4] - Scalability in the number of state per entity (QoS
initiators and QoS controllers):
Same arguments as in [5.6.1].
[5.6.5] - Scalability in CPU use (end terminal and intermediate
nodes):
Question of where to perform traffic classification and marking.
Most efficiently done at the edges and end hosts.
[5.6.6] - Low latency in setup:
Static provisioning and admission control helps in DiffServ.
IntServ is relatively slow (including RSVP).
[5.6.7] - Allow for low bandwidth consumption for signalling
protocol:
Out-of-band signalling would be most suitable here.
[5.6.8] - Ability to constrain load on devices:
de Meer, et al. Expires November 2002 [Page 22]
Internet Draft Analysis of Existing QoS Solutions May 2002
Conditioning in many forms is a prerequisite.
[5.7.1] - Aggregation capability, including the capability to select
and change the level of aggregation:
Clearly supported in RFC2998 framework as BA, aggregated RSVP or
flow-based RSVP are all included mechanisms.
[5.7.2] - Flexibility in the placement of the QoS initiator:
Not supported.
[5.7.3] - Flexibility in the initiation of re-negotiation QoS change
requests):
It is included in the framework: IntServ allows re-signalling at
any time. Possible in DiffServ with dynamic signalling and
provisioning mechanisms based on RSVP.
[5.7.4] - Uni / bi-directional reservation:
Only unidirectional reservations are supported.
[5.8.1] - The QoS protocol must provide strong authentication:
Security received only limited consideration. However, RSVP
security is considered in [RFC2747] and applies fully here.
Furthermore, host marking issues and self-protection of network
elements are discussed in DiffServ networks. Each DS domain
controls access and modification of packets whilst entering and
traversing its network. The DS field is not protected by IPsec
Authentication Header, as it is an excluded field. IntServ is more
concerned only with contract fulfillment and policing accordingly.
[5.8.2] - The QoS protocol must provide means to authorize resource
requests:
See explanation [5.8.1].
[5.8.3] - The QoS signalling messages must provide integrity
protection:
See explanation [5.8.1].
de Meer, et al. Expires November 2002 [Page 23]
Internet Draft Analysis of Existing QoS Solutions May 2002
[5.8.4] - The QoS signalling messages must be replay protected:
See explanation [5.8.1].
[5.8.5] - The QoS signalling protocol must allow for hop-by-hop
security:
See explanation [5.8.1].
[5.8.6] - The QoS protocol should allow identity confidentiality and
location privacy:
See explanation [5.8.1].
[5.8.7] - The QoS protocol should prevent denial-of-service attacks
against signalling entities:
See explanation [5.8.1].
[5.8.8] - The QoS protocol should support confidentiality of
signalling messages:
See explanation [5.8.1].
[5.8.9] - The QoS protocol should provide hooks to interact with
protocols that allow the negotiation of authentication and key
management protocols:
Not specified.
[5.8.10] - The QoS protocol should provide means to interact with key
management protocols:
Not specified.
[5.10.1] - Interworking with IP tunneling:
IP tunneling is an inherent concept in the framework. In
particular, RSVP may possibly be tunneled through DiffServ
elements. Could apply at any link, but not necessarily.
[5.10.2] - The solution should not constrain either to IPv4 or IPv6:
This requirement is supported by [RFC2998].
de Meer, et al. Expires November 2002 [Page 24]
Internet Draft Analysis of Existing QoS Solutions May 2002
[5.10.3] - Independence from charging model:
Not specified.
[5.10.4] - The QoS protocol should provide hooks for AAA protocols:
Not specified.
[5.11.1] - Ability to assign transport quality to signalling
messages:
Not applicable within the DiffServ domain.
4.2. Analysis based on open issues in [Brun02]
This section describes the analysis of the IntServ over DiffServ
protocol described in [RFC2998] using the criteria that are based on
the open issues in [Brun02].
The number in brackets is the number of the open issue used in
[Brun02], where the issue is described. For the description of these
open issues, refer to [Brun02].
[2] - Open issue 2: Sender/receiver initiation Sender initiated a
MUST, receiver initiated a MAY:
This requirement cannot be supported by [RFC2998].
[8] - Open issue 8: Bi-directional data path setup with one QoS
request:
This requirement is not supported by [RFC2998].
[33] - Open issue 33: Highest possible network utilization:
This requirement cannot be supported within the DiffServ domain.
[36] - Open issue 36: Independence of reservation identifier:
It can only be applied within the DiffServ domain, but it cannot
be supported end-to-end.
[53] - Open issue 53: this open issue is a requirement described in
Section 5.1.16. of [PaKa02] - Error handling and redundancy
de Meer, et al. Expires November 2002 [Page 25]
Internet Draft Analysis of Existing QoS Solutions May 2002
considerations:
This requirement cannot be supported within the DiffServ domain.
[55] - Open issue 55: this open issue is a requirement described in
Section 5.2.2. of [PaKa02] - Allow local QoS information exchange
between two border nodes:
The two border nodes are able to exchange information between the
border nodes, but this information is not local.
[59] - Open issue 59: this open issue is a requirement described in
Section 5.3.4. of [PaKa02] - "Ability to deal with severe
congestion":
This requirement cannot be supported within the DiffServ domain.
[60] - Open issue 60: this open issue is a requirement described in
Section 5.4.3. of [PaKa02] - "Allow efficient QoS re-establishment
after handover":
Not applicable.
4.3. Analysis based on requirements in [PaKa02]
This section describes the analysis of the IntServ over DiffServ
protocol described in [RFC2998] using the criteria that are based on
the requirements in [PaKa02].
The number enclosed between the brackets is the section number in
[PaKa02] where the requirement is described. For the complete
description of these requirements, refer to [PaKa02].
[5.2.3] - Allow generation of local QoS signalling messages:
This is partly fulfilled for DiffServ network elements: borders
and edges can interchange roles.
[5.3.1.1] - Modular:
Modular within the DiffServ domain.
[5.3.1.2] - Simple:
de Meer, et al. Expires November 2002 [Page 26]
Internet Draft Analysis of Existing QoS Solutions May 2002
Simplicity is of equal concern as efficiency. But there is a
tradeoff: signalling vs. bandwidth, for example (static vs.
dynamic)
[5.3.1.3] - Minimal Impact on Performance:
It is always considered, at least implicitly.
[5.3.2] - Ability to deal with mobility (handover):
Not applicable.
[5.3.3] - On-demand, dynamic signalling for efficient network
utilization:
Inside the DiffServ domain this requirement is not supported (or
is partially supported).
[5.3.4] - Ability to deal with severe congestion:
This scenario is mostly missing in RFC2998. Dynamic signalling
has been limited to set-up functions: provisioning or resource
reservations and feedback in that situation, but not during
operation and possible interactions with users or subscriber.s
[5.3.5] - Optimize for unicast transport:
Multicast is of major concern. IntServ (RSVP) naturally supports
multicast and group communication. That is why receiver-based
resource reservations are of importance. In DiffServ, however, so
far unicast is the only form of communication that is supported.
It is an open research issue to provide heterogeneity support in
DiffServ for multicast. Some effort has been spent in RFC2998
looking into this issue.
[5.3.6] - Ability to transparently traverse an interior node:
[RFC2998] supports this requirement.
[5.3.7] - Use of a simple QoS parameter:
The simpler the better, but this is only implicitly discussed in
RFC2998.
de Meer, et al. Expires November 2002 [Page 27]
Internet Draft Analysis of Existing QoS Solutions May 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, 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 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
violating the PHB resource allocation requirements. In this
de Meer, et al. Expires November 2002 [Page 28]
Internet Draft Analysis of Existing QoS Solutions May 2002
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 November 2002 [Page 29]
Internet Draft Analysis of Existing QoS Solutions May 2002
5.1. Analysis based on requirements in [Brun02]
This section describes the analysis of the DiffServ architecture
described in [RFC2475] using the requirements in [Brun02].
The number enclosed between the brackets is the section number in
[Brun02] where the requirement is described. For the complete
description of these requirements, refer to [Brun02].
[5.1.1] - Applicability for different QoS technologies:
RFC2475 is being utilized by a number of QoS technologies. It is
designed as flexible framework and is suited to deployment in a
variety of approaches to QoS.
[5.1.2] - Resource availability information on request:
RFC2475 does not provide explicit APIs or functionality to make
resource information available. However, higher level controller
entities may provide such information but this is not in the
explicit scope of RFC2475.
[5.1.3] - Modularity:
RFC2475 provides the basic QoS mechanisms, but does not specify
how QoS is specified, thus the modularity issue is more relevant
to higher level QoS controlling entities.
[5.1.4] - Decoupling of protocol and information it is carrying:
Not applicable.
[5.1.5] - Reuse of existing QoS provisioning:
RFC2475 in itself does not specify the mapping to underlying QOS
mechanisms. However, the ISSLL working group specified mappings
to a limited number of underlying technologies.
[5.1.7] - Independence of signalling and provisioning paradigm:
The differentiated services architecture is based on a simple
model where traffic entering a network is classified and possibly
conditioned at the boundaries of the network, and assigned to
different behavior aggregates. RFC2475 specifies the architecture
of the DiffServ deployment in terms of DiffServ domains. This
de Meer, et al. Expires November 2002 [Page 30]
Internet Draft Analysis of Existing QoS Solutions May 2002
specification does not limit the variety of deployable signalling
and provisioning paradigms.
[5.2.1] - Free placement of QoS Initiator and QoS Controllers
functions:
Not applicable.
[5.2.2] - No constraint of the QoS signalling and QoS Controllers to
be in the data path:
With DiffServ, the QoS is signalled in the DS field of the data
packets, thus the signalling is tied to the data path. However
independent QoS controllers are possible outside the data path.
[5.2.3] - Concealment of topology and technology information:
RFC2475 does not provide features for topology discovery.
[5.3.1] - Explicit release of resources:
RFC2475 does not explicitly reserve resources, thus it
consequently does not explicitly release resources.
[5.3.2] - Possibility for automatic release of resources after
failure:
Not applicable.
[5.3.3] - Possibility for automatic re-setup of resources after
recovery:
Not applicable.
[5.3.4] - Prompt notification of QoS violation in case of error /
failure to QoS Initiator and QoS Controllers:
Although not in scope of RFC2475, a mechanism to provide
notification of QoS failure would be seen as an important facility
provided by higher level QoS controller subsystem.
[5.3.5] - Feedback about success of request for QoS guarantees:
There is no specification of feedback mechanisms regarding success
of QoS requests in RFC2475. However, local QoS edge devices may
de Meer, et al. Expires November 2002 [Page 31]
Internet Draft Analysis of Existing QoS Solutions May 2002
provide feedback at a higher level.
[5.4.1] - The signalling protocol and QoS control information should
be application independent:
RFC2475 does not specify any application dependent mechanisms as
it operates at the IP level.
[5.5.1] - Mutability information on parameters:
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.
[5.5.2] - Possibility to add and remove local domain information:
Not applicable.
[5.5.3] - Independence of reservation identifier:
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.
[5.5.4] - Seamless modification of already reserved QoS:
Since RFC2475 relies upon out-of-band creation of the PHB in a
domain, the QoS modification would be seamless. However, the setup
of PHB parameters is out scope of RFC2475.
[5.5.5] - signalling must support quantitative, qualitative, and
relative QoS specifications:
Not applicable.
[5.6.1] - Scalability in the number of messages received by a
signalling communication partner (QoS initiator and controller):
RFC2475 signals QoS implicitly and thus does not have a signalling
overhead.
[5.6.2] - Scalability in number of hand-offs:
de Meer, et al. Expires November 2002 [Page 32]
Internet Draft Analysis of Existing QoS Solutions May 2002
Not applicable
[5.6.3] - Scalability in the number of interactions for setting up a
reservation:
Not applicable
[5.6.4] - Scalability in the number of state per entity (QoS
initiators and QoS controllers):
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.
[5.6.5] - Scalability in CPU use (end terminal and intermediate
nodes):
Not applicable.
[5.6.6] - Low latency in setup:
Not applicable.
[5.6.7] - Allow for low bandwidth consumption for signalling
protocol:
Not applicable.
[5.6.8] - Ability to constrain load on devices:
Not applicable.
[5.7.1] - Aggregation capability, including the capability to select
and change the level of aggregation:
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.
[5.7.2] - Flexibility in the placement of the QoS initiator:
Not applicable.
de Meer, et al. Expires November 2002 [Page 33]
Internet Draft Analysis of Existing QoS Solutions May 2002
[5.7.3] - Flexibility in the initiation of re-negotiation (QoS change
requests):
Not applicable.
[5.7.4] - Uni / bi-directional reservation:
Not applicable.
[5.8.1] - The QoS protocol must provide strong authentication:
There is no authentication for the DS field. There is no way to
prevent tampering or determine if the DS field has been tampered
with. It is assumed that each DS domain controls access and
modification of packets whilst entering and traversing its
network. The DS field is not protected by IPsec Authentication
Header, as it is an excluded field.
[5.8.2] - The QoS protocol must provide means to authorize resource
requests:
Not applicable.
[5.8.3] - The QoS signalling messages must provide integrity
protection:
Not applicable.
[5.8.4] - The QoS signalling messages must be replay protected:
Not applicable.
[5.8.5] - The QoS signalling protocol must allow for hop-by-hop
security:
Not applicable.
[5.8.6] - The QoS protocol should allow identity confidentiality and
location privacy:
Not applicable.
[5.8.7] - The QoS protocol should prevent denial-of-service attacks
against signalling entities:
de Meer, et al. Expires November 2002 [Page 34]
Internet Draft Analysis of Existing QoS Solutions May 2002
Not applicable.
[5.8.8] - The QoS protocol should support confidentiality of
signalling messages:
Not applicable.
[5.8.9] - The QoS protocol should provide hooks to interact with
protocols that allow the negotiation of authentication and key
management protocols:
Not applicable.
[5.8.10] - The QoS protocol should provide means to interact with key
management protocols:
Not applicable
[5.10.1] - Interworking with IP tunneling:
RFC2475 defines the DS field in the TOS octet of the IP header,
and the traffic class octet in IPv6. These fields are excluded
from IPsec Authentication Header which means that IPsec does not
provide authentication or protection of these fields.
[5.10.2] - The solution should not constrain either to IPv4 or IPv6:
The DS field for IPv4 and IPv6 is defined in RFC2474.
[5.10.3] - Independence from charging model:
RFC2475 does not specify any charging model, thus it is completely
independent on this issue.
[5.10.4] - The QoS protocol should provide hooks for AAA protocols:
RFC2475 does not explicitly define AAA hooks, though it is not
excluded.
[5.11.1] - Ability to assign transport quality to signalling
messages:
Not applicable
de Meer, et al. Expires November 2002 [Page 35]
Internet Draft Analysis of Existing QoS Solutions May 2002
5.2. Analysis based on open issues in [Brun02]
This section describes the analysis of the DiffServ architecture
described in [RFC2475] using the criteria that are based on the open
issues in [Brun02].
The number in brackets is the number of the open issue used in
[Brun02], where the issue is described. For the description of these
open issues, refer to [Brun02].
[2] - Open issue 2: Sender/receiver initiation, Sender initiated a
MUST, receiver initiated a MAY:
Not applicable.
[8] - Open issue 8: Bi-directional data path setup with one QoS
request:
Not applicable.
[33] - Open issue 33: Highest possible network utilization:
In DiffServ architecture over-provisioning has to be used,
therefore it is expected that this requirement cannot be fulfilled
by the DiffServ architecture.
[36] - Open issue 36: Independence of reservation identifier:
Not applicable.
[53] - Open issue 53: this open issue is a requirement described in
Section 5.1.16 of [PaKa02] - Error handling and redundancy
considerations:
This requirement cannot be fulfilled by the DiffServ architecture.
[55] - Open issue 55: this open issue is a requirement described in
Section 5.2.2. of [PaKa02] - Allow local QoS information exchange
between two border nodes:
The DiffServ architecture is not possible to exchange local QoS
information.
[59] - Open issue 59: this open issue is a requirement described in
Section 5.3.4. of [PaKa02] - "Ability to deal with severe
de Meer, et al. Expires November 2002 [Page 36]
Internet Draft Analysis of Existing QoS Solutions May 2002
congestion":
The DiffServ architecture it is not able to support this
requirement.
[60] - Open issue 60: this open issue is a requirement described in
Section 5.4.3. of [PaKa02] - "Allow efficient QoS re-establishment
after handover":
Not applicable.
5.3. Analysis based on the requirements in [PaKa02]
This section describes the analysis of the DiffServ architecture
described in [RFC2475] using requirements in [PaKa02] (see Section
2).
[5.2.3] - Allow generation of local QoS signalling messages:
Not applicable.
[5.3.1.1] - Modular:
The DiffServ architecture is modular since the complexity is moved
at the edges of the domain and the functionality in the interior
nodes is quite simple.
[5.3.1.2] - Simple:
The DiffServ architecture is simple.
[5.3.1.3] - Minimal Impact on Performance:
The DiffServ architecture does not use any dynamical protocol
therefore, the performance of an interior node is not affected.
[5.3.2] - Ability to deal with mobility (handover):
It is not able to support this requirement.
[5.3.3] - On-demand, dynamic signalling for efficient network
utilization:
It is not able to support this requirement.
de Meer, et al. Expires November 2002 [Page 37]
Internet Draft Analysis of Existing QoS Solutions May 2002
[5.3.4] - Ability to deal with severe congestion:
It is not able to support this requirement.
[5.3.5] - Optimize for unicast transport:
Not applicable.
[5.3.6] - Ability to transparently traverse an interior node:
Not applicable.
[5.3.7] - Use of a simple QoS parameter:
Not applicable.
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 November 2002 [Page 38]
Internet Draft Analysis of Existing QoS Solutions May 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].
6.1. Analysis based on the requirements in [Brun02]
This section describes the analysis of the RSVP aggregation protocol
described in [RFC3175] using the requirements in [Brun02].
[5.1.1] - Applicability for different QoS technologies:
The RSVP aggregation protocol [RFC3175] is optimized for the
Differentiated Services (DiffServ) QoS technology.
[5.1.2] - Resource availability information on request:
This requirement cannot be supported by [RFC3175]
[5.1.3] - Modularity:
RSVP aggregation [RFC3175] can aggregate multiple end to end
micro-flows but this aggregation is not accomplished in a modular
way.
[5.1.4] - Decoupling of protocol and information it is carrying:
This requirement is supported by [RFC3175]. The objects that
include QoS information are standardized, but the information
included in these objects can be dynamically modified.
[5.1.5] - Reuse of existing QoS provisioning:
This requirement cannot be supported by [RFC3175]
[5.1.7] - Independence of signalling and provisioning paradigm:
This requirement cannot be satisfied by [RFC3175] since the QoS
signalling carries information that is specific for the QoS
paradigm used in each router (that supports this protocol)
[5.2.1] - Free placement of QoS Initiator and QoS Controllers
functions:
This requirement cannot be supported by [RFC3175] due to the fact
de Meer, et al. Expires November 2002 [Page 39]
Internet Draft Analysis of Existing QoS Solutions May 2002
that the aggregation domain has to be determined and consequently
the placement of the aggregator and deaggregator will be on the
user data path.
[5.2.2] - No constraint of the QoS signalling and QoS Controllers to
be in the data path:
This requirement cannot be supported by [RFC3175] due to the fact
that the aggregator/deaggregator must be located on the user data
path.
[5.2.3] - Concealment of topology and technology information:
This requirement is supported by [RFC3175].
[5.3.1] - Explicit release of resources:
This requirement is supported by [RFC3175].
[5.3.2] - Possibility for automatic release of resources after
failure:
This requirement can be supported by [RFC3175]
[5.3.3] - Possibility for automatic re-setup of resources after
recovery:
This requirement cannot be supported by [RFC3175]. Only the
aggregator or deaggregator can initiate the initiation or the
refresh of the resources after recovery.
[5.3.4] - Prompt notification of QoS violation in case of error /
failure to QoS Initiator and QoS Controllers:
This can be accomplished by using the PATHerror or RESVerror
messages.
[5.3.5] - Feedback about success of request for QoS guarantees:
This feature is supported by [RFC3175]
[5.4.1] - The signalling protocol and QoS control information should
be application independent:
RSVP aggregation protocol by itself is application independent.
de Meer, et al. Expires November 2002 [Page 40]
Internet Draft Analysis of Existing QoS Solutions May 2002
However, the applications that use RSVP aggregation to signal
their requirements to network elements have to be RSVP
aggregation-aware.
[5.5.1] - Mutability information on parameters:
The RSVP aggregation protocol supports this requirement by means
of ADSPEC object in the PATHaggr message.
[5.5.2] - Possibility to add and remove local domain information:
The RSVP aggregation protocol is able to add and remove local
domain information (between the aggregator and deaggregator).
[5.5.3] - Independence of reservation identifier:
The RSVP aggregation protocol does not support this requirement as
the reservation is identified by means of the aggregated flow
identifier.
[5.5.4] - Seamless modification of already reserved QoS:
RSVP aggregation protocol supports this requirement by means of
the modify function in traffic admission control.
[5.5.5] - Signalling must support quantitative, qualitative, and
relative QoS specifications:
This requirement is supported by RSVP aggregation protocol as it
enables signalling for IntServ services, i.e. Guaranteed and
Controlled service.
[5.6.1] - Scalability in the number of messages received by a
signalling communication partner (QoS initiator and controller):
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.
[5.6.2] - Scalability in number of hand-offs:
RSVP aggregation protocol does not support hand-offs, therefore
nothing can be said related to this requirement.
de Meer, et al. Expires November 2002 [Page 41]
Internet Draft Analysis of Existing QoS Solutions May 2002
[5.6.3] - Scalability in the number of interactions for setting up a
reservation:
The reservation setup by means of RSVP aggregation requires
certain interactions. These interactions are linearly proportional
to the number of the supported aggregated flows.
[5.6.4] - Scalability in the number of state per entity (QoS
initiators and QoS controllers):
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]).
* 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.
[5.6.5] - Scalability in CPU use (end terminal and intermediate
nodes):
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
de Meer, et al. Expires November 2002 [Page 42]
Internet Draft Analysis of Existing QoS Solutions May 2002
this is accomplished on a per aggregate basis.
[5.6.6] - Low latency in setup:
The reservation setup in RSVP aggregation is dependent on the
distance between aggregator and deaggregator and on the end to end
RTT of (the end to end) RSVP signalling messages. However, this
RTT in any case will be shorter than of common IP packets as the
RSVP signalling messages are sent with the IP router alert option
set that enables faster processing in the routers.
[5.6.7] - Allow for low bandwidth consumption for signalling
protocol:
Not applicable
[5.6.8] - Ability to constrain load on devices:
The RSVP aggregation protocol supports this requirement by
aggregating many flows into few aggregated flows.
[5.7.1] - Aggregation capability, including the capability to select
and change the level of aggregation:
The RSVP aggregation protocol supports this requirement.
[5.7.2] - Flexibility in the placement of the QoS initiator:
The RSVP aggregation protocol does not support this requirement.
[5.7.3] - Flexibility in the initiation of re-negotiation (QoS change
requests):
The RSVP aggregation protocol supports this requirement by means
of refresh messages and modify admission control functions.
[5.7.4] - Uni / bi-directional reservation:
The RSVP aggregation protocol supports uni-directional
reservation, but it does not support bi-directional reservations.
[5.8.1] - The QoS protocol must provide strong authentication:
The RSVP aggregation protocol supports this requirement by means
de Meer, et al. Expires November 2002 [Page 43]
Internet Draft Analysis of Existing QoS Solutions May 2002
of the Integrity object [RFC2747].
[5.8.2] - The QoS protocol must provide means to authorize resource
requests:
The RSVP aggregation protocol supports this requirement by means
of the Policy object.
[5.8.3] - The QoS signalling messages must provide integrity
protection:
The RSVP aggregation protocol supports this requirement by means
of the Integrity object [RFC2747].
[5.8.4] - The QoS signalling messages must be replay protected:
The RSVP aggregation protocol supports this requirement by means
of Path State Base (PSB) and Reservation State Base (RSB).
[5.8.5] - The QoS signalling protocol must allow for hop-by-hop
security:
The RSVP aggregation protocol supports this requirement by means
of the Integrity object [RFC2747].
[5.8.6] - The QoS protocol should allow identity confidentiality and
location privacy:
The RSVP aggregation protocol supports this requirement by means
of the Integrity object.
[5.8.7] - The QoS protocol should prevent denial-of-service attacks
against signalling entities:
The RSVP aggregation protocol supports this requirement by means
of the Integrity object.
[5.8.8] - The QoS protocol should support confidentiality of
signalling messages:
The RSVP aggregation protocol supports this requirement by means
of the Integrity object.
[5.8.9] - The QoS protocol should provide hooks to interact with
de Meer, et al. Expires November 2002 [Page 44]
Internet Draft Analysis of Existing QoS Solutions May 2002
protocols that allow the negotiation of authentication and key
management protocols:
The RSVP aggregation protocol supports this requirement by means
of the Integrity object.
[5.8.10] - The QoS protocol should provide means to interact with key
management protocols:
The RSVP aggregation protocol supports this requirement partially
as the key management is actually used in the Integrity object.
[5.10.1] - Interworking with IP tunneling:
The RSVP aggregation protocol does not specify how RSVP
aggregation tunneling should be performed.
[5.10.2] - The solution should not constrain either to IPv4 or IPv6:
The RSVP aggregation protocol supports this requirement.
[5.10.3] - Independence from charging model:
The RSVP aggregation protocol supports this requirement.
[5.10.4] - The QoS protocol should provide hooks for AAA protocols:
The RSVP aggregation protocol does not support this requirement.
[5.11.1] - Ability to assign transport quality to signalling
messages:
The RSVP aggregation protocol supports this requirement by means
of RSVP-E2E-IGNORE protocol number, the RSVP signalling messages
are processed faster in the routers. This enables certain
transport quality.
6.2. Analysis based on open issues in [Brun02]
This section describes the analysis of the RSVP aggregation protocol
described in [RFC3175] using the open issues in [Brun02].
The number in brackets is the number of the open issue used in
[Brun02], where the issue is described. For the description of these
de Meer, et al. Expires November 2002 [Page 45]
Internet Draft Analysis of Existing QoS Solutions May 2002
open issues, refer to [Brun02].
[2] - Open issue 2: Sender/receiver initiation, Sender initiated a
MUST, receiver initiated a MAY:
The RSVP aggregation protocol is a receiver-initiated protocol,
thus it does not support this requirement.
[8] - Open issue 8: Bi-directional data path setup with one QoS
request:
RSVP aggregation protocol does not support bi-directional data
path setup with a single QoS request. It may support bi-
directional request only as a combination of two single uni-
directional requests.
[33] - Open issue 33: Highest possible network utilization:
The RSVP aggregation protocol provides high network utilization up
to the point where the scalability of the network is not affected.
[36] - Open issue 36: Independence of reservation identifier:
The RSVP aggregation protocol does not support this requirement
(see above).
[53] - Open issue 53: this open issue is a requirement described in
Section 5.1.16 of [PaKa02] - Error handling and redundancy
considerations:
The RSVP aggregation protocol supports this requirement by means
of the error signalling messages.
[55] - Open issue 55: this open issue is a requirement described in
Section 5.2.2. of [PaKa02] - Allow local QoS information exchange
between two border nodes:
The RSVP aggregation protocol supports this requirement, since
local QoS information can be exchanged between the aggregator and
deaggregator.
[59] - Open issue 59: this open issue is a requirement described in
Section 5.3.4. of [PaKa02] - "Ability to deal with severe
congestion":
de Meer, et al. Expires November 2002 [Page 46]
Internet Draft Analysis of Existing QoS Solutions May 2002
The RSVP aggregation protocol supports this requirement.
[60] - Open issue 60: this open issue is a requirement described in
Section 5.4.3. of [PaKa02] - "Allow efficient QoS re-establishment
after handover":
The RSVP aggregation protocol does not support mobility. As such
it does not allow efficient QoS re-establishment after handover as
in these cases it needs to re-initiate a new signalling session.
6.3. Analysis based on requirements in [PaKa02]
This section describes the analysis of the aggregated RSVP protocol
described in [RFC3175] using the requirements in [PaKa02].
The number enclosed between the brackets is the section number in
[PaKa02] where the requirement is described. For the complete
description of these requirements, refer to [PaKa02].
[5.2.3] - Allow generation of local QoS signalling messages:
The RSVP aggregation protocol can support aggregated RSVP messages
that can be seen as local QoS messages.
[5.3.1.1] - Modular:
RSVP aggregation [RFC3175] can aggregate multiple end to end
micro-flows but this aggregation is not accomplished in a modular
way.
[5.3.1.2] - Simple:
The RSVP aggregation protocol, like RSVP, is very flexible and can
be applicable in many different scenarios. This increases its
complexity.
[5.3.1.3] - Minimal Impact on Performance:
Due to its complexity the RSVP aggregation protocol impacts the
performance of the interior nodes.
[5.3.2] - Ability to deal with mobility (handover):
The RSVP aggregation protocol cannot support efficiently this
de Meer, et al. Expires November 2002 [Page 47]
Internet Draft Analysis of Existing QoS Solutions May 2002
requirement.
[5.3.3] - On-demand, dynamic signalling for efficient network
utilization:
The RSVP aggregation protocol provides on-demand and dynamic
signalling.
[5.3.4] - Ability to deal with severe congestion:
The RSVP aggregation protocol, like RSVP, is able to support
severe congestion solutions.
[5.3.5] - Optimize for unicast transport:
The RSVP aggregation protocol is not optimized for unicast
reservations.
[5.3.6] - Ability to transparently traverse an interior node:
This requirement cannot be supported by the RSVP aggregation
protocol.
[5.3.7] - Use of a simple QoS parameter:
RSVP aggregation uses more than one QoS parameters (TSPEC, RSPEC,
ADSPEC).
7. Conclusions
This draft provides 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.
RSVP [RFC2205] 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 November 2002 [Page 48]
Internet Draft Analysis of Existing QoS Solutions May 2002
* 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 signalling 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.
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.
de Meer, et al. Expires November 2002 [Page 49]
Internet Draft Analysis of Existing QoS Solutions May 2002
The IntServ over DiffServ architecture [RFC2998] allows at least two
different possible deployment strategies. The first is based on
statically allocated resources in the DiffServ domain. A main
disadvantage of this approach is that the edge nodes in the customer
network will not be aware of the traffic load in the nodes located
within the DiffServ domain. The second possible strategy is based on
dynamically allocated resources in the DiffServ domain. According to
[RFC2998], this can be done using RSVP-aware DiffServ routers.
However, this approach has most of the drawbacks of RSVP, and per-
microflow state information is kept in the intermediate routers.
With regards to aggregated RSVP [RFC3175], even if the reservation is
based on aggregated traffic, the number of re-negotiations of the
allocated resources due to mobility (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
de Meer, et al. Expires November 2002 [Page 50]
Internet Draft Analysis of Existing QoS Solutions May 2002
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.
* 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.
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.
8. References
[BiaBle] G. Bianchi, N. Blefari_Melazzi, "A Migration Path
to provide End-to-End QoS over Stateless
Networks by Means of a Probing-driven Admission
Control", Internet Draft, work in progress,
draft-bianchi-blefari-end-to-end-QoS-xx.txt, 2001.
[Brun02] Brunner, M., "Requirements for QoS Signaling Protocols"
Internet Draft, work in progress,
draft-ietf-nsis-req-01.txt, 2002.
[CSZ92] Clark, D.D., Shenker, S., Zhang, L, "Supporting
Real-Time Applications in an Integrated Services
Packet Network: Architecture and Mechanism",
Proc. ACM SIGCOMM'92, August 1992.
[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.
de Meer, et al. Expires November 2002 [Page 51]
Internet Draft Analysis of Existing QoS Solutions May 2002
[PaKa02] Partain, D., Bergsten, A., Greis, M., Karagiannis,
G., Manner, J., Murphy, J., Pan, P., Rexhepi,
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.
de Meer, et al. Expires November 2002 [Page 52]
Internet Draft Analysis of Existing QoS Solutions May 2002
[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.
9. Acknowledgments
Thanks to Istvan Cselenyi, Pontus Wallentin, Geert Heijenk and
Giussepe Bianchi for reviewing this draft and providing useful input.
10. Editors' Addresses
Hermann De Meer
Department of Electronic & Electrical Engineering
University College London
Torrington Place
London WC1E 7JE
Great Britain
EMail: H.DeMeer@ee.ucl.ac.uk
Piers O'Hanlon
Department of Electronic & Electrical Engineering
University College London
Torrington Place
London WC1E 7JE
Great Britain
EMail: P.OHanlon@cs.ucl.ac.uk
Gabor Feher
Budapest University of Technology and Economics
Department of Telecommunications and Telematics
Magyar tudosok korutja 2.; H-1117 Budapest; Hungary
Phone: +36 1 463 2187
de Meer, et al. Expires November 2002 [Page 53]
Internet Draft Analysis of Existing QoS Solutions May 2002
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
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 November 2002 [Page 54]