RSVP Extensions for Dynamic Reservation
draft-chodorek-tsvwg-rsvp-dynamic-resv-03
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Authors | Robert R. Chodorek , Agnieszka Chodorek | ||
Last updated | 2016-06-22 | ||
RFC stream | (None) | ||
Formats | |||
Additional resources | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-chodorek-tsvwg-rsvp-dynamic-resv-03
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: <PathChange Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> <sender change descriptor> <sender change descriptor> ::= <SENDER_TEMPLATE> <SENDER_TCHSPEC> [ <SENDER_TSPEC> ] [ <ADSPEC> ] 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: <ResvChange Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <RESV_CONFIRM> ] [ <SCOPE> ] <STYLE> <flow change descriptor list> Chodorek Expires December 22, 2016 [Page 4] Internet-Draft RSVP Extensions for Dynamic June 2016 <flow change descriptor list> ::= <empty> | <flow change descriptor list> <flow change descriptor> WF Style: <flow change descriptor list> ::= <WF flow change descriptor> <WF flow change descriptor> ::= <FLOWCHANGESPEC> [ <FLOWSPEC> ] FF style: <flow change descriptor list> ::= <FLOWCHANGESPEC> <FILTER_SPEC> | <flow change descriptor list> <FF flow descriptor> <FF flow change descriptor> ::= [ <FLOWCHANGESPEC> ] [ <FLOWSPEC> ] <FILTER_SPEC> SE style: <flow change descriptor list> ::= <SE flow change descriptor> <SE flow change descriptor> ::= <FLOWCHANGESPEC> [ <FLOWSPEC> ] <filter spec list> 4. RSVP Dynamic Reservation Objects The RSVP Extension for Dynamic Reservation uses two new objects, namely a SENDER_TCHSPEC and a FLOWCHANGESPEC. 4.1. SENDER_TCHSPEC Object The SENDER_TCHSPEC object is used to convey information about future values of traffic flow. The SENDER_TCHSPEC object has the following format: SENDER_TCHSPEC class = To be allocated by IANA Type 1 SENDER_TCHSPEC object: Class = TBD, C-Type = 1 Chodorek Expires December 22, 2016 [Page 5] Internet-Draft RSVP Extensions for Dynamic June 2016 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | Flags |TCH rec. type| No. of TCH records (K) | +-------------+-------------+-------------+-------------+ | | . . . TCH record [1] . . . | | +-------------+-------------+-------------+-------------+ | | . . . TCH record [2] . . . | | +-------------+-------------+-------------+-------------+ | . | . . . | . | +-------------+-------------+-------------+-------------+ | | . . . TCH record [K] . . . | | +-------------+-------------+-------------+-------------+ Figure 1 The SENDER_TCHSPEC type 1 object. The SENDER_TCHSPEC type 1 object (Fig. 1) consists of one or more TCH records describing traffic followed by obligatory for RSVP objects, namely a 32-bit word header (including fields: Length, Class-Num and C-Type) and a 32-bit SENDER_TCHSPEC type 1 object specific header. Flags (8 bit): Determine the format of TCH records and action properties of the PathChange message, and has the following format: +-+-+-+-+-+-+-+-+ | Res |I|S|E|F| +-+-+-+-+-+-+-+-+ Res (4 bit): Chodorek Expires December 22, 2016 [Page 6] Internet-Draft RSVP Extensions for Dynamic June 2016 The Res (Reserved) field MUST be set to zero I (1 bit): Indicates action in the node after receiving the PathChange message: 0 no change to resource allocation, only refresh states in the node 1 change resource allocation and refresh states in the node S (1 bit): stream traffic indication 0 No stream 1 Stream E (1 bit): elastic traffic indication 0 No elastic 1 Elastic Note: If S == 1, E MUST be set to 0 and If E == 1, S MUST be set to 0. F (1 bit): Format of the selected field (defined for each TCH variant) in TCH records: 0 Positive integer value 1 Floating-point value TCH rec. type (8 bit): variant of TCH record: 0 - reserved 1 - variant 1 of TCH 2-254 - reserved for future variants 255 - reserved No. of TCH records (K) The No. of TCH records (K) field specifies how many TCH records are present in this SENDER_TCHSPEC object. Each TCH record variant 1 has the following internal format: Chodorek Expires December 22, 2016 [Page 7] Internet-Draft RSVP Extensions for Dynamic June 2016 +-------------+-------------+-------------+-------------+ | Next Data | +-------------+-------------+-------------+-------------+ | Next Time | +-------------+-------------+-------------+-------------+ Figure 2 The TCH record variant 1. Next Data (32 bit): size (in bytes) of data sent in the near future. If Flag F is not set (F == 0): Next Data = Next Data If Flag F is set (F == 1), Next Data represents a floating- point value as follows (representation is used in accordance with IEEE 754 single precision [IEEE754]): 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 1 2 3 4 5 6 7 8 9 A B C D E F +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| exp | mant | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Data = (mant) << (exp+8) Note(1): infinity stream is defined: as FFFFFFFF hex value if F == 0 as exp=FF and mant=0 if F == 1 Next Time (32 bit): Time (in milliseconds) the counting of data that were included in the field Next Data. 4.2. FLOWCHANGESPEC Class The FLOWCHANGESPEC object is used to convey information for current resource allocation. The FLOWCHANGESPEC object has the following format: FLOWCHANGESPEC class = To be allocated by IANA Type 1 FLOWCHANGESPEC object: Class = TBD, C-Type = 1 Chodorek Expires December 22, 2016 [Page 8] Internet-Draft RSVP Extensions for Dynamic June 2016 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | Flags |TCHR rec type| Reserved | +-------------+-------------+-------------+-------------+ | | . . . TCHR record . . . | | +-------------+-------------+-------------+-------------+ Figure 3 The FLOWCHANGESPEC type 1 object. The FLOWCHANGESPEC type 1 object (Fig. 3) consists of TCHR record describing traffic followed by the obligatory for RSVP objects including a 32-bit word header (including fields: Length, Class-Num and C-Type) and a 32-bit FLOWCHANGESPEC type 1 object specific header. Flags (8 bit): Determines the format of the TCH records and the action properties of the ResvChange message, and has the following format: +-+-+-+-+-+-+-+-+ | Res |S|E|F| +-+-+-+-+-+-+-+-+ Res (5 bit): The Res (Reserved) field MUST be set to zero S (1 bit): stream traffic indication 0 No stream 1 Stream E (1 bit): elastic traffic indication 0 No elastic 1 Elastic Chodorek Expires December 22, 2016 [Page 9] Internet-Draft RSVP Extensions for Dynamic June 2016 Note: If S == 1, E MUST be set to 0 and If E == 1, S MUST be set to 0. F (1 bit): Format of the selected field (defined for each TCH variant) in TCH records: 0 Positive integer value 1 Floating-point value TCHR rec. type (8 bit): variant of TCHR record: 0 - reserved 1 - variant 1 of TCHR 2-254 - reserved for future variants 255 - reserved Reserved (8 bit): Reserved) field MUST be set to zero. TCHR record variant 1 has the following internal format: +-------------+-------------+-------------+-------------+ | Next Data | +-------------+-------------+-------------+-------------+ | Next Time | +-------------+-------------+-------------+-------------+ | Token Bucket Rate [r] | +-------------+-------------+-------------+-------------+ | Token Bucket Size [b] | +-------------+-------------+-------------+-------------+ Figure 4 The TCHR record variant 1. Next Data (32 bit): size (in bytes) of data sent in the near future. If Flag F is not set (F == 0): Next Data = Next Data If Flag F is set (F == 1), Next Data represents a floating- point value as follows (representation is used in accordance with IEEE 754 single precision [IEEE754]): Chodorek Expires December 22, 2016 [Page 10] Internet-Draft RSVP Extensions for Dynamic June 2016 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 1 2 3 4 5 6 7 8 9 A B C D E F +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| exp | mant | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Data = (mant) << (exp+8) Note(1): infinity stream is defined: as FFFFFFFF hex value if F == 0 as exp=FF and mant=0 if F == 1 Next Time (32 bit): Time (in milliseconds) the counting of data that were included in the field Next Data. Token Bucket Rate [r] (32 bit): First parameter to the token bucket specification average of token rate [r] - 32-bit IEEE single precision floating point number Token Bucket Size [b] (32 bit): Second parameter to the token bucket specification bucket depth [b] - 32-bit IEEE single precision floating point number 5. Security Considerations Security considerations to be provided. 6. IANA Considerations A message type must be assigned by IANA for the PathChange and ResvChange messages. A Class Number (C-Num) must be assigned by IANA for the Type 1 SENDER_TCHSPEC object and Type 1 FLOWCHANGESPEC object. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. Chodorek Expires December 22, 2016 [Page 11] Internet-Draft RSVP Extensions for Dynamic June 2016 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997, <http://www.rfc-editor.org/info/rfc2205>. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009, <http://www.rfc- editor.org/info/rfc5511>. [IEEE754] Institute of Electrical and Electronics Engineers, "Standard for Floating-Point Arithmetic", IEEE Standard 754, August 2008. 7.2. Informative References [Cho2002] Chodorek, A., "A fast and efficient model of an MPEG-4 video traffic based on phase space linearised decomposition", Proc. of 14th European Simulation Symposium ESS'2002, pp. 44-55, 2002, <http://www.scs- europe.net/services/ess2002/PDF/elec-4.pdf>. [Cho2003] Chodorek, A., "Prediction-based dynamic QoS assurance for multicast multimedia delivery", High-Speed Networks and Multimedia Communications: 6th IEEE International Conference HSNMC 2003, Estoril, Portugal, July 23-25, 2003, Proceedings. Vol. 6. Springer, pp. 128-135, 10.1007/978-3- 540-45076-4_13, 2003. [Cho2010] Chodorek, R., and Chodorek, A., "An Analysis of QoS Provisioning for High Definition Video Distribution in Heterogeneous Network", Proc. of 14th International Symposium on Consumer Electronics (ISCE 2010), pp. 326-331, 2010. Authors' Addresses Robert R. Chodorek AGH Univ. of Science and Technology Al. Mickiewicza 30 30-059 Krakow Poland Email: chodorek@agh.edu.pl Chodorek Expires December 22, 2016 [Page 12] Internet-Draft RSVP Extensions for Dynamic June 2016 Agnieszka Chodorek Kielce University of Technology Al. Tysiaclecia Panstwa Polskiego 7 25-314 Kielce Poland Email: a.chodorek@tu.kielce.pl Chodorek Expires December 22, 2016 [Page 13]