Internet DRAFT - draft-greis-qos-signaling-requirements
draft-greis-qos-signaling-requirements
Internet Engineering Task Force Marc Greis
INTERNET-DRAFT Haihong Zheng
draft-greis-qos-signaling-requirements-00.txt Nokia Research Center
Jukka Manner
University of Helsinki
Requirements for QoS Signaling
<draft-greis-qos-signaling-requirements-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.
Abstract
This draft proposes a set of requirements for QoS signaling
protocols. These requirements are derived both from past experience
with existing QoS signaling protocols as well as new challenges which
arise for QoS signaling e.g. from mobile, wireless and cellular
networks.
Greis, Zheng, Manner [Page i]
INTERNET-DRAFT Requirements for QoS Signaling November 2001
1. Introduction
Even though the IETF has created a QoS signaling protocol (RSVP [1]),
a widespread deployment of QoS signaling protocols (like RSVP [1]) in
the Internet has not occurred so far, mostly due to perceived and
real shortcomings of this protocol. If a new QoS signaling protocol
is to be created or if an existing one is to be modified to alleviate
this situation, it is necessary to first produce a set of
requirements which cover all potential problem areas.
2. Requirements for a QoS Signaling Protocol
A list of requirements for QoS signaling protocols is presented in
this section. Since IP mobility and next generation wireless networks
create additional challenges for QoS signaling protocols, many of the
requirements below describe these particular challenges.
2.1. Must have small overhead and allow for efficient bandwidth usage
QoS signaling messages must have a small overhead. This is especially
important for wireless links with expensive and limited bandwidth.
This implies that the QoS information needs to be compact (i.e., no
redundant and unnecessary information) and encoded efficiently.
2.2. Must have small overhead and allow for efficient bandwidth usage
The QoS signaling protocol should allow the processing of the QoS
signaling messages to be as simple as possible. This is especially
important on mobile hosts with limited resources and power. This
simplicity requirement may also help to reduce the delay of the QoS
signaling procedure.
Furthermore, the QoS parameters must be understandable, simple, but
also intuitive to the "user" (e.g. end user or API developer) or
communicating partners.
2.3. Must be flexible and extensible
It must be possible to include special parameters for different
access technologies in the QoS signaling protocol. Also, it must be
possible to extend the QoS signaling protocol to adapt to future
access technologies.
Greis, Zheng, Manner [Page 1]
INTERNET-DRAFT Requirements for QoS Signaling November 2001
This implies that the signalling protocol and the information it
carries must be de-coupled from each other.
2.4. Must enable QoS negotiation between the host and the network in an
efficient manner
"QoS negotiation" in this context describes the process of an actual
negotiation which may take place between a host and the network, i.e.
the QoS request from the host would be seen as a proposal, which can
be either accepted, rejected or downgraded by the network, the last
option leaving it up to the host, if it wants to establish the
communication based on the downgraded QoS.
The QoS signaling protocol should allow QoS negotiation between the
end node and the network or the remote endpoint in an efficient way.
The efficiency can be measured by delay, bandwidth required, etc.
Delay can in this context result from the number of round trip times,
the processing time, and the size of the signaling messages.
2.5. Must allow QoS setup for duplex connections and simplex
connections, both in the upstream and downstream direction
For the case where the QoS is only required on the upstream direction
(i.e. the direction from the end host towards the network), the QoS
signaling only needs to trigger QoS establishment in this direction.
For the application where the QoS is only required in the downstream
direction (e.g., streaming application without feedback channel), the
QoS signaling only needs to trigger QoS setup in this direction.
Therefore, the QoS signaling protocol should allow QoS setup for
these simplex connections.
Also, QoS setup for duplex connections is required, where
applications require QoS setup in both directions.
2.6. Must allow explicit QoS release
After call termination, unneeded states related to the QoS signaling
in the network should be released as soon as possible. The QoS
signaling protocol must allow a host to send a QoS release request
explicitly.
Also, in the case where the host is a mobile node, it may be the
responsibility of the network to remove old reservations at the old
access point after handovers. It must be possible to implement such
mechanisms in the network.
Greis, Zheng, Manner [Page 2]
INTERNET-DRAFT Requirements for QoS Signaling November 2001
2.7. Must allow efficient QoS re-establishment after handover
Handover is an essential aspect in wireless networks. After handover,
QoS may need to be completely re-established or partially re-
established due to route change. The re-establishment may be
requested by the mobile node itself or triggered by the access point
that the mobile node attached to. In the first case, the QoS
signaling should allow efficient QoS re-establishment after handover.
Re-establishment of QoS after handover should be as quick as possible
so that the mobile node does not experience service interruption or
QoS degradation. The re-establishement should be localized, and not
require end-to-end signalling, if possible.
2.8. Must enable other network entities to generate QoS request on
behalf of a node
A QoS request is normally generated by the node that requires QoS.
However, in some cases, it is beneficial to send a QoS request by
another network entity (a proxy) on behalf of the node. As an
example, in a wireless network with limited bandwidth, the initial
QoS request may be sent from the node itself, while the following
ones sent after handover or for refresh purposes may be generated by
the access router that keeps the QoS request state for the mobile
node. The QoS signaling protocol must enable such a scenario.
2.9. Must be compatible with different QoS technologies used in the
network
Different QoS technologies, e.g, DiffServ, IntServ, MPLS, may be used
in different or even the same network domains. The QoS signaling
should be compatible with different QoS technologies (both existing
signalling and provisioning mechanisms). More specifically, the QoS
parameters included in the QoS signaling must be common for different
QoS technologies or it must be possible to convert them to the
specific parameters used in different QoS technologies.
2.10. Must allow QoS authorization and policy control
QoS authorization and policy control provide operators with service
control. QoS signaling must include necessary information to be used
for the network to authorize the QoS request and perform policy
control.
Greis, Zheng, Manner [Page 3]
INTERNET-DRAFT Requirements for QoS Signaling November 2001
2.11. Must support common security features
This includes privacy and anonymity support as well as the integrity
of signalling packets.
2.12. Must allow authentication of the QoS request
QoS requests need to be authenticated before QoS authorization is
performed. QoS signaling must be able to carry necessary information
used by the network to authenticate the QoS request.
2.13. Must provide hooks for accounting
QoS signaling protocol should include necessary information for the
network to collect charging data for a specific user.
2.14. Must be independent from different mobility protocols
Although the QoS signaling may be able to take advantage of specific
mobility protocols for optimized operation, it should be designed
independently from mobility protocols in the sense that it can still
perform the same functionality when one or more of these mobility
protocols are not used.
2.15. Minimal changes required in intermediate hosts
This is a generic requirement of any mechanism that is used in
routers, for example. The lighter the implementation, the more likely
it will work efficiently. This is especially true for basic routers.
2.16. The QoS signalling and provisioning mechanisms must be decoupled
from each other
The QoS signalling mechanism should be decoupled from the mechanism
used to provide the requested service (e.g. queueing mechanisms),
which, among other things, allows the use of edge-to-edge mechanisms
for resource control between different domains.
2.17. The access network structure must be invisible to end hosts
The implementation of QoS in the access network network, including
network topology, should not be visible to the end hosts. The QoS
Greis, Zheng, Manner [Page 4]
INTERNET-DRAFT Requirements for QoS Signaling November 2001
interface shall only reflect the "bearer requirements" that a host
can request. Any mechanism or combination of mechanisms can be used
together to provide the overall QoS.
2.18. The signalling must interwork with routing mechanisms
A QoS signalling mechanism should support QoS routing in order to
spread the load of congested network paths on alternate paths.
Furthermore, the signalling mechanism should allow for setting QoS on
multiple paths, for example, for multiple downstream paths.
2.19. Must not expect symmetric routing
The QoS signalling mechanism must not assume symmetric routing for
upstream and downstream directions. IP routing is commonly
asymmetric, and only symmetric by coincidence.
2.20. Scalability must not be compromised
The signalling mechanism must scale with the number of hosts sending
QoS requests for an even greater number of flows. This may include
minimizing the number of resource reservations managed.
2.21. Must interwork with IP tunneling
The QoS signalling and provisioning mechanisms must operate in
networks that make use of IP tunneling, but also IPSec. The
signalling messages need to be visible to the network QoS nodes, but
also the data packets that would need a specific QoS need to be
identified.
2.22. Must support end-to-end, edge-to-edge and end-to-edge signalling
The signalling mechanism must work end-to-end, but also, if needed,
more locally, i.e. end-to-edge as well as edge-to-edge.
The requirement also includes the potential need for signalling
towards "middle-boxes" on the transport layer, e.g. firewalls and
NATs.
Greis, Zheng, Manner [Page 5]
INTERNET-DRAFT Requirements for QoS Signaling November 2001
2.23. Interwork with non-QoS aware network paths
The signalling messages must be transported through non-QoS aware
core networks, for example, the signalling can still trigger QoS
requests on access links on both ends, while the connecting core
network may for example be over-provisioned.
2.24. Must support different types of QoS requests
It must be possible to signal different service types:
o reservations (both shared and dedicated),
o reservationless (relative priority-based, drop precedences),
2.25. Must work with changing IP addresses of (mobile) hosts
Mobile hosts may need to change their CoA while QoS is provisioned
for them. The signalling mechanism must allow to change the
identification information related to provisioned QoS to keep the QoS
allocated to a mobile host's flows, either upstream or downstream.
2.26. Must support both unicast and multicast
Both the support of unicast and multicast connections is desired.
However, the implementation of the multicast features should not
compromise the requirement for simplicity.
2.27. Must deal with IP fragmentation gracefully
The possibility that signaling messages may be fragmented needs to be
taken into account. The signaling protocol must deal with this issue
in a simple and efficient manner.
Acknowledgements
A number of requirements were taken from the following Internet
Drafts (in order of decreasing importance):
1) draft-bradner-nsis-bof-00.txt
Greis, Zheng, Manner [Page 6]
INTERNET-DRAFT Requirements for QoS Signaling November 2001
2) draft-ietf-mobileip-qos-requirements-01.txt
3) draft-westberg-rmd-cellular-issues-00.txt
The authors of this draft would like to acknowledge the requirements
raised in the above mentioned drafts by the authors of the drafts and
by the people contributing requirements in the NSIS BOF held at the
50. IETF meeting.
References
[1] Bradner, S., Mankin, A., "Report of the Next Steps in
Signaling BOF", draft-bradner-nsis-bof-00.txt, Work in
Progress, July 2001
[2] Chaskar, H., "Requirements of a QoS Solution for Mobile IP",
draft-ietf-mobileip-qos-requirements-01.txt, Work in Progress,
August 2001
[3] Partain, D., et al, "Resource Reservation Issues in Cellular
Radio Access Networks", draft-westberg-rmd-cellular-
issues-00.txt, Work in Progress, June 2001
Author's Addresses
Marc Greis
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 374 0629
Email: marc.greis@nokia.com
Haihong Zheng
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894 4232
Email: haihong.zheng@nokia.com
Greis, Zheng, Manner [Page 7]
INTERNET-DRAFT Requirements for QoS Signaling November 2001
Jukka Manner
University of Helsinki
P.O. Box 26, FIN-00014
Helsinki
Finland
Phone: +358 9 191 44210
Email: jukka.manner@cs.helsinki.fi
Greis, Zheng, Manner [Page 8]
