Internet DRAFT - draft-chodorek-tsvwg-rsvp-dynamic-resv
draft-chodorek-tsvwg-rsvp-dynamic-resv
Network Working Group R.R. Chodorek
Internet Draft AGH Univ. of Science and Technology
Intended status: Experimental A. Chodorek
Expires: November 13, 2018 Kielce University of Technology
May 13, 2018
RSVP Extensions for Dynamic Reservation
draft-chodorek-tsvwg-rsvp-dynamic-resv-06
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 November 13, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Chodorek Expires November 13, 2018 [Page 1]
Internet-Draft RSVP Extensions for Dynamic May 2018
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 ................................................. 12
7.1. Normative References ................................... 12
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 November 13, 2018 [Page 2]
Internet-Draft RSVP Extensions for Dynamic May 2018
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 November 13, 2018 [Page 3]
Internet-Draft RSVP Extensions for Dynamic May 2018
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 November 13, 2018 [Page 4]
Internet-Draft RSVP Extensions for Dynamic May 2018
<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 November 13, 2018 [Page 5]
Internet-Draft RSVP Extensions for Dynamic May 2018
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 |L|I|S|E|F|
+-+-+-+-+-+-+-+-+
Res (3 bit):
Chodorek Expires November 13, 2018 [Page 6]
Internet-Draft RSVP Extensions for Dynamic May 2018
The Res (Reserved) field MUST be set to zero
L (1 bit):
Large amount of data
0 No large amount of data
1 Large amount of data
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)
Chodorek Expires November 13, 2018 [Page 7]
Internet-Draft RSVP Extensions for Dynamic May 2018
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:
+-------------+-------------+-------------+-------------+
| 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| exponent | significand_field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note(1): infinity stream is defined:
as FFFFFFFF hex value if F == 0
as exponent = FF and significand_field = 0 if F == 1
Note(2): sign bit is always zero (positive number).
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:
Chodorek Expires November 13, 2018 [Page 8]
Internet-Draft RSVP Extensions for Dynamic May 2018
FLOWCHANGESPEC class = To be allocated by IANA
Type 1 FLOWCHANGESPEC object: Class = TBD, C-Type = 1
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):
Chodorek Expires November 13, 2018 [Page 9]
Internet-Draft RSVP Extensions for Dynamic May 2018
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
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
Chodorek Expires November 13, 2018 [Page 10]
Internet-Draft RSVP Extensions for Dynamic May 2018
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.
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.
Chodorek Expires November 13, 2018 [Page 11]
Internet-Draft RSVP Extensions for Dynamic May 2018
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>.
[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.
Chodorek Expires November 13, 2018 [Page 12]
Internet-Draft RSVP Extensions for Dynamic May 2018
Authors' Addresses
Robert R. Chodorek
AGH Univ. of Science and Technology
Al. Mickiewicza 30
30-059 Krakow
Poland
Email: chodorek@agh.edu.pl
Agnieszka Chodorek
Kielce University of Technology
Al. Tysiaclecia Panstwa Polskiego 7
25-314 Kielce
Poland
Email: a.chodorek@tu.kielce.pl
Chodorek Expires November 13, 2018 [Page 13]
