Internet DRAFT - draft-hetzer-adv-res
draft-hetzer-adv-res
D. Hetzer
Internet Draft T-Systems
Expires: December 22, 2005 June 20, 2005
Internet service for Resource Reservation in Advance
draft-hetzer-adv-res-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on December 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Internet service aimed at advance resource reservation for QoS based
applications using QoS managers interacting with IntServ/RSVP and
Differentiated Service architectures is proposed.
Different issues such as resource reservation, timing of
requests and dependency of reservations are considered in the advance
resource reservation interface. Abstract interface describing the
advance resource reservation requests is specified.
Mechanisms for advance resource reservation are discussed.
Hetzer Expires December 10, 2005 [Page 1]
INTERNET-DRAFT Service for resource reservation in advance June 2005
Optimisation strategies based on resource reservation in advance are
overviewed.
Table of Contents
1. Introduction .................................................... 2
2. Terminology used in this document ............................... 3
3. Issues for Resource reservation in advance ...................... 4
4. Mechanisms for Resource Reservation in advance .................. 5
4.1 Specification of advance resource reservation request .......... 5
4.2 Operational considerations for resource reservation in advance.. 6
5. Optimisation strategies for resource reservation in advance ..... 6
6. Conclusions ..................................................... 7
References ........................................................... 8
Author's Address ..................................................... 9
1. Introduction
With the deployment and integration of different kinds of QoS
based Internet applications, such as VoIP, multimedia, streaming,
Grid, real time, mission critical, and embedded systems,
there is an increasing demand for efficient strategies
aimed at optimisation of the resource scheduling for the applications
considering user requirements.
Especially, in the area of management of broadband Internet
infrastructures including mobile and satellite communication,
optimisation of bandwidth allocation for different kind of applications
and users at access networks is important challenge in order to keep
the QoS parameter stable and provide efficient usage of scare
resources [9].
Currently, the main standardisation effort in IETF on QoS provisioning
and resource reservation for QoS based applications is based on
IntServ/RSVP (Integrated Service/Resource Reservation Protocol)
[1], [2], [4] and Differentiated Services (DiffServ)[3] mechanisms.
Applications using these protocols for resource allocation could
require dynamically resources using immediate resource reservation
requests. Immediate resource reservation requests specify resource
reservations starting directly after accepting the request by the system.
Resource allocation in advance is another kind of reservation-based
communication services, which is used, when certain users are willing
to allocate resources in advance in order to overcome the blocking
probability of a communication network.
Advance reservations for QoS based applications were proposed in the
research and practical experiments for applications, which want to pay
more in order to be sure to get resources in the time intervals and QoS
levels, which they need [7], [8], [9], [14].
Hetzer Expires December 10, 2005 [Page 2]
INTERNET-DRAFT Service for resource reservation in advance June 2005
Especially, concepts based on alternative resource reservations [13] are
attractive as policies for the network provider, users and applications.
Advance reservation is important for QoS based applications, which know
in advance their timing, dependency and resource specific requirements.
For the network provider, they increase the flexibility and the potential
for optimising of resources for different users and applications. For the
user, advance reservations provide efficient mechanisms for QoS guarantee.
Specifying resource requests in advance could support the optimised
resource usage based on application of suitable scheduling strategies.
Currently, the advance reservation is integrated in some experimental
systems, such as IconoNet [11] for optimised routing and resource
reservation, GARA aimed at optimisation of resources for Grid
applications [12] and the experimental advance resource reservation
interface on top of RSVP [9]. In these systems, appropriate optimisation
technologies and scheduling algorithms based on advance resource requests
are used prior to reservation in order to obtain optimal scheduling.
Other work [5] considers resource scheduling in advance adaptable to QoS
and resource requirements of operational traffic.
Advance reservation as Internet service is still not standardised.
This document proposes an interface for such a service aimed to optimise
QoS and resources in Internet by reducing the blocking probability.
2. Terminology used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [10].
Terms describing resource reservations in IntServ/RSVP architecture
are defined in [1], [2], [4] and in DiffServ are specified in [3].
Following specific terms are used in this document:
Resource request
Specification for resource reservation
Immediate reservation request
Resource request which specify reservation starting immediately.
Advance reservation request
The resource requests specifies reservations ahead of time in order to
support resource planning and scheduling in future.
Blocking probability
The probability to reject reservation requests.
Hetzer Expires December 10, 2005 [Page 3]
INTERNET-DRAFT Service for resource reservation in advance June 2005
3. Issues for resource reservation in advance
There are different issues, which could be considered in the advance
resource reservation specifications and their parameterisation.
Resource reservation in advance could be characterised with options,
defining parameters for resource renegotiations, time, priority, cost,
adaptation, duration and dependency of reserved resources.
Options for renegotiation of resources are aimed to specify requests
with alternative bandwidth requirements or requests with changing
bandwidths.
The options defining changing bandwidths could describe possible
increment sizes, when additional resources are required in order
to multiplex operational traffic with the issued advance resource
reservation request.
In scenarios for multiplexing of resource reservations, additional
bandwidth could be specified for increase of the initially required
resources, which is used to minimise the signalling overhead for new
requests by aggregating advance and immediate reservations.
Time constraints, used to specify reservations, depend on the kind of
application and user requirements.
Usually, the fixed start time for advance allocation is assumed [13],
which let small possibility for optimisation.
There are also scenarios, in which some users could
consider flexible times for resource allocation.
Reservations, which could be allocated based on time intervals are for
instance considered for Grid applications [15].
Interval oriented reservations defined by flexible start and end time.
allows flexibility on allocation in specific interval(s), in order to
optimise costs and provide better resource utilisation and QoS
provision in Internet.
The priority issue could be considered in advance resource reservation
requests for bandwidth allocation of mission critical and real-time
applications.
Another point is the dependent reservation for distributed multimedia
applications, embedded systems and mission critical applications,
which require usage of resources in co-ordinated manner to provide QoS
guarantee for distributed applications.
In the case of Grid applications [18], dependent resource reservation
could be aimed at the time restricted allocation of resources for
each of the Grid sub-task submitted by users in order to optimise
the QoS of the composed Grid application.
Hetzer Expires December 10, 2005 [Page 4]
INTERNET-DRAFT Service for resource reservation in advance June 2005
4. Mechanisms for resource reservation in advance
4.1. Specification of advance resource reservation request
Specification of abstract resource reservation request in advance is
proposed. It could be mapped to specific protocol mechanisms and
socket interface for advance reservation as discussed in section 4.2.
The abstract resource reservation request R is defined as a tuple
R := (conn, d, b, incr, cost, dep, T)
where
conn represents a sequence of source and destination node (cs,cd)
d is the duration of the request,
b is a function describing the alternative bandwidth reservations,
which could be requested by the call,
incr (optionally) is the bandwidth increment function,
cost (optionally) describes the priority of the request,
dep (optionally) is a dependency function specifying dependent
reservations of applications,
T denoting timing constraints.
Based on selection of appropriate parameter values using this interface,
optimisation considering specific criteria (such as QoS of best effort
traffic) is possible.
In this specification, a bandwidth function b is defined by the set
b = {b1,àbi,à. bm} of alternative bandwidth requests bi , 0 <= i <= m,
for advance reservation. Alternative bandwidths express different QoS
levels for the application and are used for optimisation considering
the network and application criteria.
The requested bandwidth b could be incremented by the additional
bandwidth incr based on the formula b + k*incr, where 0 <= k <= n .
Parameter incr specifies change of requested bandwidth during the
resource usage. Incr depends on application and could be used for
multiplexing in operational networks. Positive and negative values
of incr are aimed to define increasing or decreasing amount of
resources concerning the resource reservation request R.
The increments are set dependent on multiplexing strategies for
reducing of the signalling overhead for resource reservation requests.
Hetzer Expires December 10, 2005 [Page 5]
INTERNET-DRAFT Service for resource reservation in advance June 2005
Cost is a parameter, defined with 0 <= cost <= 1, describing the relative
priority of resource reservation request, which is useful when there
are more requests than available resources.
A dependency function dep related to request R is defined by the set
dep = {R1,àRi,à.Rn} , describing resource requests R1, àRià Rn,
which must be finished, before R starts.
The time constraint T is given by the sequence T= (start, end),
which could be defined to specify allocations in a given interval
(start, end), with given deadline (end) or fixed start time (start).
On this way, a wide range of applications including real-time and
embedded, but also VoIP and video, could be supported.
4.2 Operational considerations for resource reservation in advance
The abstract resource reservation interface could be integrated
in advance resource reservation architecture based on a resource
manager interacting with IntServ/RSVP and DiffServ QoS provisioning
technologies (figure 1).
The advance resource reservation set-up protocol includes mechanisms for
- requesting of resources according to the abstract resource reservation
options
- acknowledgement of resource reservation requests based on the abstract
resource reservation requests.
+---------------------------------------------------------+
| Application |
| Abstract resource reservation in advance as Socket API |
+---------------------------------------------------------+
| ^
advance | |acknowledgement
request | |
| |
v |
+------------------------------------------------+
| QoS Manager |
| advance resource reservation |
+------------------------------------------------+
^
|
v
+--------------------------------+
| QoS provisioning technologies |
| |
| IntServ/RSVP DiffServ |
+--------------------------------+
Figure 1: Architecture for resource reservation in advance
Hetzer Expires December 10, 2005 [Page 6]
INTERNET-DRAFT Service for resource reservation in advance June 2005
The interface to the abstract resource reservation requests could be
implemented based on extensions of the socket interface.
A socket is an abstraction that represents an endpoint of communication.
Most applications that consciously use TCP and UDP do so by creating a
socket of the appropriate type and then performing a series of
operations on that socket.
The socket interface for IPv6 is described in [16], [17].
5. Optimisation strategies based on resource reservation in advance
The proposed advance resource reservation interface and service could
be integrated based on different policies for management and
optimisation of the QoS and resource usage in Internet.
From operational point of view, it is not efficient enough to
optimise bandwidth allocation in advance without to consider the
dynamics of the remaining operational network traffic in Internet
and the QoS experienced by this traffic.
[5] describes an architecture for adaptable QoS oriented bandwidth
planning using the proposed advance resource reservation interface.
Its aim is to learn automatically optimal policies for resource
allocation in advance of QoS based applications, considering QoS
feedback (delay, packet loss) of remaining operational traffic.
The optimisation of resource allocation in advance considers possible
allocation intervals for QoS based application specified by resource
requests, as well as QoS parameter thresholds and patterns of traffic.
The architecture includes user interfaces, optimisation and learning
algorithms, and integrated data base for derived bandwidth schedules,
resource usage and QoS monitoring data (i.e. patterns describing QoS
behaviour) of the traffic, which should be considered to adapt and
optimise the advance reservation allocations.
Different optimisation strategies could be used based on advance
resource reservation interfaces.
They are aimed to support:
o Proactive bandwidth planning based on predictions of QoS
parameter behaviour patterns and adaptation of the advance
resource reservation to these patterns
o Reactive bandwidth planning aimed to consider the dynamic
of QoS parameters (events, congestion and anomalies) in
operational networks and to change operationally the
advance resource reservation schedules.
For the implementation of the optimisations, scheduling algorithms
interacting with reinforcement learning strategies for optimal
allocation decisions are used.
Hetzer Expires December 10, 2005 [Page 7]
INTERNET-DRAFT Service for resource reservation in advance June 2005
The final aim is to adapt the reservation strategies in advance
considering the needs of the remaining operational traffic, for
which no resources in advance are reserved.
This allows in overloaded scenarios ("rush hour" in operational networks)
to suspend the reservation for advance requests if it is possible
(i.e. allocations allows reservations in given intervals) and to allocate
it at other time considering the specifications.
7. Conclusions
The Internet service for advance resource reservation of QoS based
applications was specified in this draft considering different
kinds of application traffic (VoIP, Grid, embedded) and user requirements.
The Draft is first step of informational description of such service.
Further work is aimed to enhance the IPv6 basic socket interface [16]
and API [17] based on the abstract specification of advance requests and
mechanisms for advance resource reservation as proposed in this Draft.
References
[1] R. Braden Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, ôResource
ReSerVation Protocol (RSVP) {Version 1 Functional Specicationö,
IETF Request for Comments 2205, September 1997
[2] A. Mankin, Ed., F. Baker, B. Braden, S. Bradner, M. OæDell, A.
Romanow, A. Weinrib, L. Zhang. ôResource ReSerVation Protocol
(RSVP) -- Version 1, Applicability Statement Some Guidelines on
Deploymentö, September 1997
[3] S. Blake et al., ôAn Architecture for Differentiated Servicesö,
RFC 2475, December 1998
[4] R. Braden et al., ôIntegrated Services in the Internet Architecture:
An Overviewö, RFC 1633, June 1994
[5] D. Hetzer, Reinforcement learning for adaptable bandwidth planning,
Information Technology and Cybernetics Conference , CITSA 2005,
Orlando, July, 2005
[6] D. Hetzer, I.Miloucheva, P.A. Guitierres, Performance Management
for Efficient QoS Provision and Resource Utilisation in Broadband
Internet Infrastructure, Broadband Society Workshop, ICETE 2004,
Setubal, Portugal, August 2004
Hetzer Expires December 10, 2005 [Page 8]
INTERNET-DRAFT Service for resource reservation in advance June 2005
[7] W. Reinhardt, ôAdvance resource Reservation and its Impact on
Reservation Protocolsö, in Proceedings of Broadband Island 95,
Dublin, Ireland, September 1995
[8] L. C. Wolf and R. Steinmetz, ôConcepts for Resource Reservation in
Advanceö, in Special Issue of Journal of Multimedia Tools and
Applications, The State of the Art in Multimedia Computing,
May 1997
[9] A. Schill, S. K’hn, F. Breiter, ôDesign and Evaluation of an
Advance Reservation Protocol on top of RSVPö, in Broadband, 1998
[10] S.Bradner,"Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[11] C. Frei, B. Faltings, G. Melissagris, P.Pu, ôIconoNET: a Tool for
Automated Bandwidth Allocation Planningö, in IEEE/IFIP Network
Operations and Management Symposium (NOMS), Hawaii, April 2000
[12] I. Foster, A. Roy, V. Sander, ôA Quality of Service Architecture
that Combines Resource Reservation and Application Adaptationö,
in Proceedings of the Eight International Workshop on Quality of
Service (IWQOS 2000), page 181û188, June 2000
[13] T. Erlebach, ôCall Admission Control for Advance Reservation
Requests with Alternativesö, Eidgen÷ssische Technische Hochschule
Z’rich, Swiss Federal Institute of Technology Zurich, TIK-Report Nr.
142, July 2002
[14] L. Yuan, C. Tham, A.Ananada, ôA Probing Approach for effective
distributed resource reservationö, in QoSIP, 2003
[15] A. Roy, V. Sander, ôAdvance Reservation APIö, Scheduling Working
Group, Scheduling Working Document: 9.2, Draft for First Global
Grid Forum, 3. March 2001
[16] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493,
February 2003
[17] Stevens, W. and M. Thomas, "Advanced socket API for IPv6", RFC 2292,
February 1998
Author's Addresse
Dirk Hetzer
T-Systems
Goslauer Ufer 38 Phone: +49-30-3497-3116
Berlin, Germany email: hetzer@t-systems.com
Hetzer Expires December 10, 2005 [Page 9]
INTERNET-DRAFT Service for resource reservation in advance June 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hetzer Expires December 10, 2005 [Page 10]
