Network Working Group R.R. Chodorek Internet Draft AGH Univ. of Science and Technology Intended status: Experimental A. Chodorek Expires: December 22, 2016 Kielce University of Technology June 22, 2016 RSVP Extensions for Dynamic Reservation draft-chodorek-tsvwg-rsvp-dynamic-resv-03 Abstract RSVP reservations are static in nature and typically last for the whole session. The proposed extension to the RSVP allows the RSVP to make elastic adjustments to reservations for the current demand of network resources. The proposed method dynamically changes the RSVP reservations on the basis of knowledge about transmitted traffic. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and 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 22, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Chodorek Expires December 22, 2016 [Page 1] Internet-Draft RSVP Extensions for Dynamic June 2016 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................ 2 2. RSVP Dynamic Reservation Protocol Mechanisms ................ 3 3. RSVP Dynamic Reservation Message Formats .................... 3 3.1. The new Flag definition in the Common Header ........... 4 3.2. The PathChange Messages ................................ 4 3.3. The ResvChange Messages ................................ 4 4. RSVP Dynamic Reservation Objects ............................ 5 4.1. SENDER_TCHSPEC Object .................................. 5 4.2. FLOWCHANGESPEC Class ................................... 8 5. Security Considerations .................................... 11 6. IANA Considerations ........................................ 11 7. References ................................................. 11 7.1. Normative References .................................. 11 7.2. Informative References ................................ 12 1. Introduction The proposed extension to the Resource ReserVation Protocol (RSVP) [RFC2205] enables reservations to be changed dynamically in the event of changes to network resource requirements for the transmitted multimedia stream. The proposed extension, in many cases, allows for the release of some of the network resources, allowing for their utilization by other transmissions. In practice, released resources can be used for the transmission of elastic traffic (e.g. the traffic observed during transmissions carried out using the TCP or other reliable transport protocols). Information about the behavior of the stream that will be transmitted in the near future is often available in the transmitter. It can be derived, for instance, from measurements taken in the output buffer or as a result of traffic predictions [Cho2002]. This information can be used in intermediate nodes for dynamic bandwidth allocation [Cho2010] (as, for example, the prediction-based bandwidth renegotiation module [Cho2003]). Chodorek Expires December 22, 2016 [Page 2] Internet-Draft RSVP Extensions for Dynamic June 2016 The proposed extension to the RSVP is designed to transmit dynamic information about traffic change and traffic requirements to intermediate nodes and end node(s). 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 RFC-2119 [RFC2119]. 2. RSVP Dynamic Reservation Protocol Mechanisms The RSVP session for the multimedia transmission is setup using standard Path and Resv messages exchange [RFC2205]. The Path message creates the nodes data structure that stores the state of the session. The Resv message performs reservations using admission control procedures. If the session is successfully established the session is regularly updated by Path and Resv messages [RFC2205]. The RSVP Extension for Dynamic Reservations uses two new message types: PathChange and ResvChange. The proposed messages don't alter standard Path and Resv messages functionality. During the RSVP session the sender of multimedia can send information about new requirements for network resources. This is accomplished by using PathChange messages. After the reception of the PathChange message the receiver will change the allocation of network resources by sending the ResvChange message. The proposed messages don't influence admission control procedures. They only change current resource allocation. It is also possible to change resource allocation using only PathChange messages. In this case resource allocations will be changed after receiving the PathChange message. To enable this capability in the Common Header a new flag D (sec. 3.1) must be set up. The PathChange or ResvChange messages carry a TIME_VALUES object containing the refresh time R. The time R determines the lifetime of the dynamic change of resource allocation. The time R MUST be less than or equal to refresh time defined by the Resv messages. If this time has expired the proposed RSVP Extension for Dynamic Reservations returns to the settings defined by the Resv messages. 3. RSVP Dynamic Reservation Message Formats The RSVP Extension for Dynamic Reservation uses two new messages types, PathChange and ResvChange. It also proposes a new definition for the usage of the Flag field in the Common Header. Chodorek Expires December 22, 2016 [Page 3] Internet-Draft RSVP Extensions for Dynamic June 2016 3.1. The new Flag definition in the Common Header The PathChange Messages can change resource allocations without using ResvChange Messages. To negotiate and enable this capability a new format of the Flag in the Common Header [RFC2205] has been defined: +-+-+-+-+ | Res |D| +-+-+-+-+ Res (3 bit): The Res (Reserved) field MUST be set to zero D (1 bit): Indicates the capability of the RSVP implementation to change resource allocation in the nodes after receiving a PathChange message: 0 not capable of the new features 1 capable of the new features 3.2. The PathChange Messages The PathChange Messages are sent from sender to receiver(s) like the Path messages. The formats of the PatchChange can be represented based on the Backus-Naur Form (BNF) [RFC5511] as follows: ::= [ ] ::= [ ] [ ] 3.3. The ResvChange Messages The ResvChange Messages are sent from sender to receiver(s) like the Resv messages. The formats of the ResvChange can be represented based on the BNF [RFC5511] as follows: ::= [ ] [ ] [ ]