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": "resource": { "bandwidth": // Option "latency": // 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": "to": } 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": // Option "latency": // 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": "class": "type": "server": "resource": { "bandwidth": // Option "latency": // 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": } 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, . [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]