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]