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]