Internet DRAFT - draft-tsuzaki-netconfig-webapi

draft-tsuzaki-netconfig-webapi







Network Working Group                                         Y. Tsuzaki
Internet-Draft                                          Kyoto University
Intended status: Informational                               R. Atarashi
Expires: March 12, 2016                    IIJ Innovation Institute Inc.
                                                               S. Suzuki
                                                         Keio University
                                                              K. Mitsuya
                                                                K. Okada
                                                        Lepidum Co. Ltd.
                                                      September 09, 2015


        Network configuration Web API for Bandwidth Reservation
                 draft-tsuzaki-netconfig-webapi-01.txt

Abstract

   This draft introduces a framework for a dynamic bandwidth reservation
   via Web API for Web applications.  In this document, we propose Web
   APIs for Web clients to request bandwidth allocation to network
   controllers.  The network controller could be both of SDN compliant
   or Non-SDN compliant one.  In this document, a network specification
   definition language is also proposed.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on March 12, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Tsuzaki, et al.          Expires March 12, 2016                 [Page 1]

Internet-Draft              netconfig-webapi              September 2015


   (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.  Requirement . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  System architecture . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Management server . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Media client  . . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Program Server  . . . . . . . . . . . . . . . . . . . . .   5
     4.4.  Media Server  . . . . . . . . . . . . . . . . . . . . . .   5
     4.5.  System components . . . . . . . . . . . . . . . . . . . .   6
   5.  API . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Service definition language . . . . . . . . . . . . . . .   7
     5.2.  Web API . . . . . . . . . . . . . . . . . . . . . . . . .   9
       5.2.1.  Resource usage report . . . . . . . . . . . . . . . .   9
       5.2.2.  Resource request  . . . . . . . . . . . . . . . . . .  11
       5.2.3.  Keep-alive  . . . . . . . . . . . . . . . . . . . . .  16
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   8.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  16
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   This draft proposes a framework for a dynamic bandwidth reservation
   via Web API for Web applications.  We assume that there are network
   controllers to control the network devices and gather information
   about their control domain.  Those controllers equip Web APIs so that
   Web clients can request bandwidth allocated virtual private paths
   between contents Web servers and the clients.  Network administrators
   describe the service specifications with "service description
   language", and the bandwidth are allocated to the clients according
   to the service specifications.  This draft explains the overview of
   this architecture and how resource reservations are made.






Tsuzaki, et al.          Expires March 12, 2016                 [Page 2]

Internet-Draft              netconfig-webapi              September 2015


2.  Requirement

   o  From the Viewpoint of Network Administrators
      Based on the service specifications configured by the
      administrators, network management controllers automatically
      respond to the client requests via Web APIs.

   o  From the Viewpoint of Clients
      By accessing the Web API for the network resource reservations,
      clients can reserve QoS guaranteed communication bandwidth for Web
      contents downloads.

   o  Use Case
      The network administrators prepare Web APIs for configuring
      network paths and bandwidth reservations.  When a client need to
      download large contents from a Web server, the client send the
      requiring resource information to the network management server
      via Web APIs.  The network management server construct a QoS
      guaranteed communication path for the client based on the
      information received from the client.

3.  Terminology

   o  Service Description Language (SDL): A language by which
      administrators describes network device information.
      Administrators describe SDL and put the descriptions to management
      servers.

   o  Network Description Language (NDL): A language by which
      administrators describes network service information.
      Administrators describe NDL and put the descriptions to management
      servers.

   o  Management server: Servers which control the network devices in a
      domain.  These servers also provide the application interfaces for
      media clients to signal resource requests.  Administrators
      describe the network configurations and policies of networks by
      SDL/NDL and put them to management servers.  Management servers
      are also referred as Network management servers.

   o  Media server: Kind of a web server, which delivers media contents
      to media clients.

   o  Media client: Client application run on a Web Browser, which
      receives and present media contents to an end user.

   o  Service specification: The description of network service
      components described by SDL/NDL.



Tsuzaki, et al.          Expires March 12, 2016                 [Page 3]

Internet-Draft              netconfig-webapi              September 2015


   o  Resource request: Action by which media clients obtain resource
      reserved communication path to media servers.

4.  System architecture

                    +----------------+
                    |   Management   |
         Resource   |     server     |
         Request  +-+---+-------+--+-+
         +------> | WEB API |   |  |
         |        +---------+   |  |  Path
         |                      |  |  Setup
         |                      |  |
         |                 , - \+  +/- ,
         |             , '      \  /     ' ,
         |           ,           \/          ,
    +----+---+   +-------------------------------+   +--------+
    |  Media |               Reserved                |  Media |
    | client |                 Path                  | server |
    +--------+   +-------------------------------+   +--------+
                    ,        SDN/Non-SDN      ,
                     ,        BackBone       ,
                       ,                  , '
                         ' + , _ _ _ ,  '


                       Figure 1: System Architecture

   Figure 1 depicts the system overview of application triggered
   resource reservation architecture.  All the network components except
   for the end clients in the domain (routers, servers) are under the
   control of the management server.  The network management server
   gathers network management information such as status of network
   devices or links in the network, and also commands those devices to
   set up QoS guaranteed communication paths between media servers and
   media clients.

   The scope of this architecture is to define Web interfaces to signal
   resource allocation from Web browser applications to management
   servers.

4.1.  Management server

   Management servers are servers that control network components on the
   networks.  Network administrators describe network device groups and
   network service description language with language called "service
   definition language".  Service definition language is detailed in
   Section 5.1.



Tsuzaki, et al.          Expires March 12, 2016                 [Page 4]

Internet-Draft              netconfig-webapi              September 2015


   Management servers serve Web APIs for clients to make resource
   reservations.  To trigger network resource reservations, media
   clients access these Web APIs on the management servers.  Upon
   receiving requests from media clients, management servers calculate
   appropriate communication paths between media servers and media
   clients.  The intermediate nodes (routers or switches) can be both of
   SDN compliant and Non-SDN compliant devices, but each of those
   devices have to be configurable by the management server via some
   remote configuration methods such as Netconf[RFC6241] or SSH.

4.2.  Media client

   Media client is a client application program run on a Web browser,
   which receives and present media contents to an end user.  Media
   client receives Media Program, which is a list of contents can be
   presented, from a Program Server.  When the user selects contents
   from the presented list of contents, the media client starts playing
   the content.

4.3.  Program Server

   Program Server store and provides a Media Program, which is a list of
   available contents.  We use HTTP to provide a Media Program to a
   media client.

   The content specified in the Media Program consists of the title of
   the content and URL of the content.  We expect content URL point to a
   location of a MPEGDash [MPEGDASH] file.  The Media Program can be
   generated either by statically or dynamically.

   At this moment, we do not define how media client finds a Program
   Server.  We assume this information is already available in media
   client.

4.4.  Media Server

   Media server is a server program which store and provide metadata of
   a program as a MPEGDash format, and the contents of each media
   referenced from the MPEGDash formatted metadata.

   Contents can be split into multiple segments by duration, or prepared
   in multiple bit rates.

   Since the links between Media Program, MPEGDash file and segmented
   contents are described as a URL, all types of contents can store on
   one media server or among multiple media servers.





Tsuzaki, et al.          Expires March 12, 2016                 [Page 5]

Internet-Draft              netconfig-webapi              September 2015


4.5.  System components

   +----------------+        +--------------+
   |Media Client    |        |Program Server|
   +----------------+        +--------------+
   | +------------+ |        | +---------+  |
   | |  Program   +----------> | Program |  |
   | |Information | |        | |   List  |  |
   | |  Manager   +--------+ | +---------+  |
   | +--+---------+ |      | +--------------+
   |    |           |      |
   |    v           |      | +--------------+
   | +------------+ |      | |Media Server  |
   | |  Resource  | |      | +--------------+
   | |  Manager   +----+   | | +----------+ |
   | +--+---------+ |  |   +-> |  Media   | |
   +----|------^----+  +-----> | Contents | |
        |      |             | +----------+ |
        |      +-------+     +--------------+
        |              |
   +----|--------------|--------------------+
   |    |              |  Management Server |
   +----v--------------|--------------------+
   |  +------+       +-+-------+            |
   |  | Web  |       | Client  |            |
   |  | APIs |       | Manager |            |
   |  +------+       +---------+            |
   |        +---------+     ^               |
   |                  v     |               |
   |  +----------+   +------+-----+         |
   |  | Topology +-->| Topology   |         |
   |  | Database |   | Calculator |         |
   |  +----------+   +------------+         |
   +----------------------------------------+

                        Figure 2: System component

   Figure 2 shows a simple component diagram of this architecture.  When
   a media client starts to obtain media contents from media servers,
   the program information manager of the client first get the program
   list from program servers.  The program lists are described in the
   media presentation description (MPD) format of MPEGDash.  The
   resource manager then access to the resource usage request Web API on
   the management server.  When received a request from a client, the
   management server calculate the allocatable bandwidth between the
   media client and the media server via the topology calculator.  Then
   the client manager of the management server responds a resource usage
   report to the media client.  Based on the information in the resource



Tsuzaki, et al.          Expires March 12, 2016                 [Page 6]

Internet-Draft              netconfig-webapi              September 2015


   usage report, the media client trigger resource allocation by
   accessing the resource request Web API on the management server.
   Then the management server allocates bandwidth to the client via the
   topology calculator and send success message back to the client.

5.  API

5.1.  Service definition language

   Network administrators define the service specifications utilizing
   the service specification language, Network Description Language
   (NDL) and Service Description Language (SDL).  NDL is to define the
   group of network components such as router groups.  With SDL,
   administrators can define service specifications on the network.
   Service specifications are the descriptions which define the
   relationship between network devices or network groups that compose
   network services.  Examples of service definitions are network
   configurations such as segment IP address blocks or VLAN id for the
   segment.  An example of NDL/SDL is shown in Figure 3 and Figure 4.

   node {
     ovs1;
     ovs2;
     media1;
     media2;
     pc11;
     pc12;
     pc13;
     pc14;
     pc21;
     pc22;
     pc23;
     pc24;
   }
   location {
     loc1 {
       media1;
       ovs1;
       pc11;
       pc12;
       pc13;
       pc14;
     }
     loc2 {
       media2;
       ovs2;
       pc21;
       pc22;



Tsuzaki, et al.          Expires March 12, 2016                 [Page 7]

Internet-Draft              netconfig-webapi              September 2015


       pc23;
       pc24;
     }
   }
   group {
     group101 {
       media1;
       media2;
       pc11;
       pc12;
       pc13;
       pc14;
       pc21;
       pc22;
       pc23;
       pc24;
       ovs1;
       ovs2;
     }
     group1623 {
       ovs1;
       ovs2;
     }
     group1624 {
       ovs1;
       ovs2;
     }
     group1625 {
       ovs1;
       ovs2;
     }
   }
   link {
     type = layer1;
     edge1 = pc11;
     edge2 = pc12;
   }

                         Figure 3: Example of NDL












Tsuzaki, et al.          Expires March 12, 2016                 [Page 8]

Internet-Draft              netconfig-webapi              September 2015


   networks {
     network group101 {
       address = "192.168.1.0/24";
       vlan = 101;

       device ovs1 {
         type = L2Switch;
         address = "192.168.1.1";
       }

       device ovs2 {
         type = L2Switch;
         address = "192.168.1.2";
       }

       device media1 {
         type = Server;
         address = "192.168.1.30";
       }

       device media2 {
         type = Server;
         address = "102.168.1.31";
       }
     }
   }

                         Figure 4: Example of SDL

   SDL also enables registrations of events on the network and event
   bound actions.  For example, if the traffic from certain source IP
   address exceeds the defined per-flow bandwidth limitation on the
   certain physical link, the traffic can be automatically shaped
   according to the definitions of SDL.  Administrators define resource
   usage limitation using this functionality of SDL.  For example,
   administrators can limit the usage of bandwidth per the domain to
   which user equipments attached.  The bandwidth allocation for each
   user is determined based on these service specifications.

5.2.  Web API

5.2.1.  Resource usage report

   Media servers advertise resource usage of links to media servers.
   The resource usage reports have two types.  One is periodic resource
   usage reports broadcasted from management servers.  Periodic usage
   reports include the uplink bandwidth usage of each server (Figure 5).
   Another resource usage type is solicited usage report which is



Tsuzaki, et al.          Expires March 12, 2016                 [Page 9]

Internet-Draft              netconfig-webapi              September 2015


   delivered to clients through WebAPI on the management servers.  In a
   solicited usage report request (Figure 6), a media client specifies
   the server from which it want to download media contents.  The media
   server which received the solicited usage reports calculates the
   physical link set which connect the client and the server, and report
   available bandwidth the management server afford to allocate to the
   client (Figure 7).  If multiple paths between the client and the
   server exist, the max available bandwidth will be returned to the
   client.  At a solicited resource usage report request, a media client
   opens a web socket to the management server.

   {
     [
       {
         "server": <String>
         "resource": {
           "bandwidth": <Num> // Option
           "latency": <Num> // Option
         }
       },
       ...
     ]
   }

          Figure 5: Unsolicited resource usage report json format

   o  server: server IP address or FQDN in string

   o  resource: available resource of the server

   {

     "from": <String>
     "to": <String>
   }

       Figure 6: Solicited resource usage report request json format

   o  from: from IP address or FQDN in string

   o  to: to IP address or FQDN in string










Tsuzaki, et al.          Expires March 12, 2016                [Page 10]

Internet-Draft              netconfig-webapi              September 2015


   {

     "resource": {
       "bandwidth": <Num> // Option
       "latency": <Num> // Option
     }
   }

      Figure 7: Solicited resource usage report response json format

   o  resource: available resource of the server

5.2.2.  Resource request

   Media clients acquire reserved communication paths by accessing
   resource requests API on the management server.  The resource
   requests have three types, initial resource request, resource
   modification request from clients, and management server trigger
   resource modification request.  We explain these types of resource
   requests in this section.  According to the session_id information in
   the request, the management server associate the web socket object of
   the request source client and the session-id.

   The clients post json format requests on the reservation.  Figure 8
   is the format of the resource request json.

   {
     "session_id": <String>
     "class": <Num>
     "type": <Num>
     "server": <String>
     "resource": {
       "bandwidth": <Num> // Option
       "latency": <Num> // Option
     }
   }

                  Figure 8: Resource request json format

   o  session_id: random created UUID to identify the session

   o  class: user priority class in digit number

   o  type: 0: Initial 1: Modification

   o  server: the server to which the client willing to connect

   o  resource: resource object contains bandwidth and latency



Tsuzaki, et al.          Expires March 12, 2016                [Page 11]

Internet-Draft              netconfig-webapi              September 2015


5.2.2.1.  Initial resource request

   +------+      +------------+      +------+
   |Media |      | Management |      |Media |
   |Client|      |   Server   |      |Server|
   +--+---+      +------------+      +------+
      |                                  |
      |                                  |

      |                 |                |
      |      RRRQ       |                |
      +---------------> |                |
      |                 +                |
      |                                  |
      |               RRRQR              |
      +--------------------------------> |
      |                                  |
      |                 +      RRRQ      |
      |                 | <--------------+
      |                 |                |
      |                 |      RRRS      |
      |                 +--------------> |
      |                 |                |
      |       RRRS      |                |
      | <---------------+                |
      |                 +                |
      |               RRRQS              |
      | <--------------------------------+
      |                                  |
      +                                  +

                Figure 9: Initial resource request sequence

   o  RURR: Resource Usage Report Request

   o  RURA: Resource Usage Report Advertisement

   o  RRRQ: Resource Reservation ReQuest

   o  RRRS: Resource Reservation ReSponse

   o  RRRQR: Resource Reservation ReQuest Request

   o  RRRQS: Resource Reservation ReQuest Response

   A media client initially obtains a contents list on the media server.
   This contents list is described in the media presentation description
   (MPD) format of MPEGDash.  The acquisition of contents list is done



Tsuzaki, et al.          Expires March 12, 2016                [Page 12]

Internet-Draft              netconfig-webapi              September 2015


   by ordinal HTTP GET method.  Then the client request resource usage
   reports to the management server as mentioned in Section 5.2.1.
   Based on information in the resource usage report and contents list,
   the client determines the contents bitrate and sends a resource
   request to the management server based on the determined contents
   bitrate.  The resource request contains a session-id randomly
   generated on clients (e.g.  UUID).  The client simultaneously send a
   resource reservation request request to media server to trigger media
   server to sends a request to the management server.  The RRRQR also
   contains same session-id as resource request.  The management server
   verifies the request from the media server and the media client, and
   sends response to both side if the information from the client and
   the server correspond.  The management server stores the session-id,
   web socket information and allocated resources.  This information is
   used for resource modifications and keep-alive.  After received RRRS
   indicating the resource reservation was done successfully, the media
   server send RRRQS to the media client.  Then the client gets to be
   able to download the media contents with guaranteed quality.

5.2.2.2.  Client trigger resource modification request

   A media client MAY offer resource modification requests when resource
   usage reports say the uplink capacity of the media server from which
   the client downloads the media contents.



























Tsuzaki, et al.          Expires March 12, 2016                [Page 13]

Internet-Draft              netconfig-webapi              September 2015


   +------+      +------------+      +------+
   |Media |      | Management |      |Media |
   |Client|      |   Server   |      |Server|
   +--+---+      +------------+      +------+
      |                                  |
      |      RRRQ       +                |
      +---------------> |                |
      |                 +                |
      |                                  |
      |               RRRQR              |
      +--------------------------------> |
      |                                  |
      |                 +      RRRQ      |
      |                 | <--------------+
      |                 |                |
      |                 |      RRRS      |
      |                 +--------------> |
      |                 |                |
      |       RRRS      |                |
      | <---------------+                |
      |                 +                |
      |               RRRQS              |
      | <--------------------------------+
      |                                  |
      +                                  +

        Figure 10: Resource modification sequence (client trigger)

5.2.2.3.  Management server trigger resource modification request






















Tsuzaki, et al.          Expires March 12, 2016                [Page 14]

Internet-Draft              netconfig-webapi              September 2015


   +------+      +------------+      +------+
   |Media |      | Management |      |Media |
   |Client|      |   Server   |      |Server|
   +--+---+      +------------+      +------+
      |                                  |
      |      RRMRQ      +                |
      | <---------------+                |
      |                 |                |
      |      RRRQ       |                |
      +---------------> |                |
      |                 +                |
      |                                  |
      |               RRRQR              |
      +--------------------------------> |
      |                                  |
      |                 +      RRRQ      |
      |                 | <--------------+
      |                 |                |
      |                 |      RRRS      |
      |                 +--------------> |
      |                 |                |
      |       RRRS      |                |
      | <---------------+                |
      |                 +                |
      |               RRRQS              |
      | <--------------------------------+
      |                                  |
      +                                  +

   Figure 11: Resource modification sequence (management server trigger)

   o  RRMRQ: Resource reservation modification request.

   Management servers MAY trigger resource downgrade/upgrade requests to
   media clients, when the used bandwidth of a certain link saturate or
   become to have room.  This push messaging can be done by Web sockets
   or WebRTC.  As resource reservation modification request contains
   available resource for the received client, the client determines the
   contents bitrate based on the information contained in RRMRQ and pre-
   downloaded contents list information at the initial resource
   reservation.  The following process is similar to the initial
   resource reservation described in Section 5.2.2.1.

5.2.2.4.  Resource cancellation

   When a client does not need the allocated resources, the client can
   explicitly stop using the resource by posting a json described in
   Figure 12.  Upon receiving cancellation message, the management



Tsuzaki, et al.          Expires March 12, 2016                [Page 15]

Internet-Draft              netconfig-webapi              September 2015


   server disassociates session-id from the client websocket, and
   release the resource bound to the session-id.

   {
     "session_id": <String>
   }

                  Figure 12: Resource cancel json format

5.2.3.  Keep-alive

   Management servers MAY keep-alive the clients to keep monitoring the
   usage of the reserved resources.  While the clients can send resource
   free messages explicitly at the end of media streaming, client
   computers tend to disconnect from the networks suddenly or the
   browser applications can be reloaded by user operations.  To avoid
   such kind of wasted resources, management servers send keep-alive
   messages include the session-ids sent from the clients at the initial
   resource reservations.  When received a keep-alive message, the
   client verify the session-id contained in the keep-alive message.  If
   the keep-alive message is not the one the client stores, the client
   ignores the keep-alive messages.  If the server does not receive the
   keep-alive responses from the client for certain configured times,
   the server free the resource bound to the session-id.  By default,
   the keep-alive interval is 300 seconds and the default keep-alive
   timeout count is 3.

6.  Security Considerations

   TBD

7.  IANA Considerations

   TBD

8.  Acknowledgement

   The author would like to thank Yasuo Okabe, Osamu Nakamura and Kaoru
   Maeda for their good contributions to this document.

9.  References

9.1.  Normative References

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, December 2011.





Tsuzaki, et al.          Expires March 12, 2016                [Page 16]

Internet-Draft              netconfig-webapi              September 2015


9.2.  Informative References

   [MPEGDASH]
              "ISO/IEC 23009-1:2014: Dynamic adaptive streaming over
              HTTP (DASH) -- Part 1: Media presentation description and
              segment formats", May 2014,
              <http://standards.iso.org/ittf/PubliclyAvailableStandards/
              index.html>.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)",
              RFC 6241, June 2011.

Authors' Addresses

   Yoshiharu Tsuzaki
   Kyoto University

   Email: tsuzakiyo@net.ist.i.kyoto-u.ac.jp


   Ray Atarashi
   IIJ Innovation Institute Inc.

   Email: ray@iijlab.net


   Shigeya Suzuki
   Keio University

   Email: shigeya@wide.ad.jp


   Koshiro Mitsuya
   Lepidum Co. Ltd.

   Email: mitsuya@lepidum.co.jp


   Kouji Okada
   Lepidum Co. Ltd.

   Email: okd@lepidum.co.jp








Tsuzaki, et al.          Expires March 12, 2016                [Page 17]