idnits 2.17.1 draft-chodorek-tsvwg-rsvp-dynamic-resv-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 13, 2018) is 2168 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 236 -- Looks like a reference, but probably isn't: '2' on line 242 == Missing Reference: 'K' is mentioned on line 252, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R.R. Chodorek 2 Internet Draft AGH Univ. of Science and Technology 3 Intended status: Experimental A. Chodorek 4 Expires: November 13, 2018 Kielce University of Technology 5 May 13, 2018 7 RSVP Extensions for Dynamic Reservation 8 draft-chodorek-tsvwg-rsvp-dynamic-resv-06 10 Abstract 12 RSVP reservations are static in nature and typically last for the 13 whole session. The proposed extension to the RSVP allows the RSVP to 14 make elastic adjustments to reservations for the current demand of 15 network resources. The proposed method dynamically changes the RSVP 16 reservations on the basis of knowledge about transmitted traffic. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on November 13, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction ................................................ 2 59 2. RSVP Dynamic Reservation Protocol Mechanisms ................. 3 60 3. RSVP Dynamic Reservation Message Formats ..................... 3 61 3.1. The new Flag definition in the Common Header ............ 4 62 3.2. The PathChange Messages ................................. 4 63 3.3. The ResvChange Messages ................................. 4 64 4. RSVP Dynamic Reservation Objects ............................. 5 65 4.1. SENDER_TCHSPEC Object ................................... 5 66 4.2. FLOWCHANGESPEC Class .................................... 8 67 5. Security Considerations ..................................... 11 68 6. IANA Considerations ........................................ 11 69 7. References ................................................. 12 70 7.1. Normative References ................................... 12 71 7.2. Informative References ................................. 12 73 1. Introduction 75 The proposed extension to the Resource ReserVation Protocol (RSVP) 76 [RFC2205] enables reservations to be changed dynamically in the event 77 of changes to network resource requirements for the transmitted 78 multimedia stream. The proposed extension, in many cases, allows for 79 the release of some of the network resources, allowing for their 80 utilization by other transmissions. In practice, released resources 81 can be used for the transmission of elastic traffic (e.g. the traffic 82 observed during transmissions carried out using the TCP or other 83 reliable transport protocols). 85 Information about the behavior of the stream that will be transmitted 86 in the near future is often available in the transmitter. It can be 87 derived, for instance, from measurements taken in the output buffer 88 or as a result of traffic predictions [Cho2002]. This information can 89 be used in intermediate nodes for dynamic bandwidth allocation 90 [Cho2010] (as, for example, the prediction-based bandwidth 91 renegotiation module [Cho2003]). 93 The proposed extension to the RSVP is designed to transmit dynamic 94 information about traffic change and traffic requirements to 95 intermediate nodes and end node(s). 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC-2119 [RFC2119]. 101 2. RSVP Dynamic Reservation Protocol Mechanisms 103 The RSVP session for the multimedia transmission is setup using 104 standard Path and Resv messages exchange [RFC2205]. The Path message 105 creates the nodes data structure that stores the state of the 106 session. The Resv message performs reservations using admission 107 control procedures. If the session is successfully established the 108 session is regularly updated by Path and Resv messages [RFC2205]. 110 The RSVP Extension for Dynamic Reservations uses two new message 111 types: PathChange and ResvChange. The proposed messages don't alter 112 standard Path and Resv messages functionality. During the RSVP 113 session the sender of multimedia can send information about new 114 requirements for network resources. This is accomplished by using 115 PathChange messages. After the reception of the PathChange message 116 the receiver will change the allocation of network resources by 117 sending the ResvChange message. The proposed messages don't influence 118 admission control procedures. They only change current resource 119 allocation. 121 It is also possible to change resource allocation using only 122 PathChange messages. In this case resource allocations will be 123 changed after receiving the PathChange message. To enable this 124 capability in the Common Header a new flag D (sec. 3.1) must be set 125 up. 127 The PathChange or ResvChange messages carry a TIME_VALUES object 128 containing the refresh time R. The time R determines the lifetime of 129 the dynamic change of resource allocation. The time R MUST be less 130 than or equal to refresh time defined by the Resv messages. If this 131 time has expired the proposed RSVP Extension for Dynamic Reservations 132 returns to the settings defined by the Resv messages. 134 3. RSVP Dynamic Reservation Message Formats 136 The RSVP Extension for Dynamic Reservation uses two new messages 137 types, PathChange and ResvChange. It also proposes a new definition 138 for the usage of the Flag field in the Common Header. 140 3.1. The new Flag definition in the Common Header 142 The PathChange Messages can change resource allocations without using 143 ResvChange Messages. To negotiate and enable this capability a new 144 format of the Flag in the Common Header [RFC2205] has been defined: 146 +-+-+-+-+ 147 | Res |D| 148 +-+-+-+-+ 150 Res (3 bit): 152 The Res (Reserved) field MUST be set to zero 154 D (1 bit): 156 Indicates the capability of the RSVP implementation to change 157 resource allocation in the nodes after receiving a PathChange 158 message: 159 0 not capable of the new features 160 1 capable of the new features 162 3.2. The PathChange Messages 164 The PathChange Messages are sent from sender to receiver(s) like the 165 Path messages. The formats of the PatchChange can be represented 166 based on the Backus-Naur Form (BNF) [RFC5511] as follows: 168 ::= [ ] 169 170 171 173 ::= 174 [ ] [ ] 176 3.3. The ResvChange Messages 178 The ResvChange Messages are sent from sender to receiver(s) like the 179 Resv messages. The formats of the ResvChange can be represented based 180 on the BNF [RFC5511] as follows: 182 ::= [ ] 183 184 185 [ ] [ ] 186