idnits 2.17.1 draft-tsuzaki-netconfig-webapi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 582: '... A Media Client MAY offer resource mo...' RFC 2119 keyword, line 648: '...nagement servers MAY trigger resource ...' RFC 2119 keyword, line 674: '...nagement servers MAY keep-alive the cl...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 09, 2015) is 3336 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6455' is defined on line 707, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Tsuzaki 3 Internet-Draft Kyoto University 4 Intended status: Informational R. Atarashi 5 Expires: September 10, 2015 IIJ Innovation Institute Inc. 6 S. Suzuki 7 Keio University 8 K. Mitsuya 9 K. Okada 10 Lepidum Co. Ltd. 11 March 09, 2015 13 Network configuration Web API for Bandwidth Reservation 14 draft-tsuzaki-netconfig-webapi-00.txt 16 Abstract 18 This draft introduces a framework for a dynamic bandwidth reservation 19 via Web API for Web applications. In this document, we propose Web 20 APIs for Web clients to request bandwidth allocation to network 21 controllers. The network controller could be both of SDN compliant 22 or Non-SDN compliant one. In this document, a network specification 23 definition language is also proposed. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 10, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirement . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. System architecture . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Management server . . . . . . . . . . . . . . . . . . . . 4 64 4.2. Media client . . . . . . . . . . . . . . . . . . . . . . 5 65 4.3. Program Server . . . . . . . . . . . . . . . . . . . . . 5 66 4.4. Media Server . . . . . . . . . . . . . . . . . . . . . . 5 67 4.5. System components . . . . . . . . . . . . . . . . . . . . 6 68 5. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.1. Service definition language . . . . . . . . . . . . . . . 7 70 5.2. Web API . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5.2.1. Resource usage report . . . . . . . . . . . . . . . . 9 72 5.2.2. Resource request . . . . . . . . . . . . . . . . . . 11 73 5.2.3. Keep-alive . . . . . . . . . . . . . . . . . . . . . 16 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 79 9.2. Informative References . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 This draft proposes a framework for a dynamic bandwidth reservation 85 via Web API for Web applications. We assume that there are network 86 controllers to control the network devices and gather information 87 about their control domain. Those controllers equip Web APIs so that 88 Web clients can request bandwidth allocated virtual private paths 89 between contents Web servers and the clients. Network administrators 90 describe the service specifications with "service description 91 language", and the bandwidth are allocated to the clients according 92 to the service specifications. This draft explains the overview of 93 this architecture and how resource reservations are made. 95 2. Requirement 97 o From the Viewpoint of Network Administrators 98 Based on the service specifications configured by the 99 administrators, network management controllers automatically 100 respond to the client requests via Web APIs. 102 o From the Viewpoint of Clients 103 By accessing the Web API for the network resource reservations, 104 clients can reserve QoS guaranteed communication bandwidth for Web 105 contents downloads. 107 o Use Case 108 The network administrators prepare Web APIs for configuring 109 network paths and bandwidth reservations. When a client need to 110 download large contents from a Web server, the client send the 111 requiring resource information to the network management server 112 via Web APIs. The network management server construct a QoS 113 guaranteed communication path for the client based on the 114 information received from the client. 116 3. Terminology 118 o Management Server: Servers which control the network devices in a 119 domain. These servers also provide the application interfaces for 120 Media Clients to signal resource requests. Administrators 121 describe the network configurations and policies of networks by 122 SDL/NDL and put them to Management Servers. Management servers 123 are also referred as Network Management Servers. 125 o Media server: Kind of a web server, which delivers media contents 126 to Media Clients. 128 o Media client: Client application run on a Web Browser, which 129 receives and present media contents to an end user. 131 o Service specification: the description of network service 132 components described by SDL/NDL 134 o Service Description Language (SDL): A language by which 135 administrators describes network device information. 136 Administrators describe SDL and put the descriptions to Management 137 Servers. 139 o Network Description Language (NDL): A language by which 140 administrators describes network service information. 141 Administrators describe NDL and put the descriptions to Management 142 Servers. 144 o Resource request: action by which Media Clients obtain resource 145 reserved communication path to Media Servers. 147 4. System architecture 149 +----------------+ 150 | Management | 151 Resource | server | 152 Request +-+---+-------+--+-+ 153 +------> | WEB API | | | 154 | +---------+ | | Path 155 | | | Setup 156 | | | 157 | , - \+ +/- , 158 | , ' \ / ' , 159 | , \/ , 160 +----+---+ +-------------------------------+ +--------+ 161 | Media | Reserved | Media | 162 | client | Path | server | 163 +--------+ +-------------------------------+ +--------+ 164 , SDN/Non-SDN , 165 , BackBone , 166 , , ' 167 ' + , _ _ _ , ' 169 Figure 1: System Architecture 171 Figure 1 depicts the system overview of application triggered 172 resource reservation architecture. All the network components except 173 for the end clients in the domain (routers, servers) are under the 174 control of the management server. The network management server 175 gathers network management information such as status of network 176 devices or links in the network, and also command those devices to 177 set up QoS guaranteed communication paths between Media Servers and 178 Media Clients. 180 The scope of this architecture is to define Web interfaces to signal 181 resource allocation from Web browser applications to management 182 servers. 184 4.1. Management server 186 Management servers are servers that control network components on the 187 networks. Network administrators describe network device groups and 188 network service description language with language called "service 189 definition language". Service definition language is detailed in 190 Section 5.1. 192 Management servers serves Web APIs for clients to make resource 193 reservations. To trigger network resource reservations, Media 194 Clients access these Web APIs on the management servers. Upon 195 receiving requests from Media Clients, a management server calculate 196 appropriate communication paths between Media Servers and Media 197 Clients. The intermediate nodes (routers or switches) can be both of 198 SDN compliant and Non-SDN compliant devices, but each of those 199 devices have to be configurable by the management server via some 200 remote configuration methods such as Netconf[RFC6241] or SSH. 202 4.2. Media client 204 Media client is a client application program run on a Web browser, 205 which receives and present media contents to an end user. Media 206 client receives Media Program, which is a list of contents can be 207 presented, from a Program Server. When the user selects a content 208 from the presented list of contents, Media client start playing the 209 content. 211 4.3. Program Server 213 Program Server store and provides a Media Program, which is a list of 214 available contents. We use HTTP to provide a Media Program to a 215 Media Client. 217 The content specified in the Media Program consists of the title of 218 the content and URL of the content. We expect content URL point to a 219 location of a MEPGDash[MPEGDASH] file. The Media Program can be 220 generated either by statically or dynamically. 222 At this moment, we do not define how Media client finds a Program 223 Server. We assume this information is already available in Media 224 client. 226 4.4. Media Server 228 Media server is a server program which store and provide metadata of 229 a program as a MPEGDash format, and the contents of each media 230 referenced from the MPEGDash formatted metadata. 232 Contents can be split into multiple segments by duration, or prepared 233 in multiple bit rates. 235 Since the links between Media Program, MPEGDash file and segmented 236 contents are described as a URL, all types of contents can store on 237 one Media Server or among multiple Media Servers. 239 4.5. System components 241 +----------------+ +--------------+ 242 |Media Client | |Program Server| 243 +----------------+ +--------------+ 244 | +------------+ | | +---------+ | 245 | | Program +----------> | Program | | 246 | |Information | | | | List | | 247 | | Manager +--------+ | +---------+ | 248 | +--+---------+ | | +--------------+ 249 | | | | 250 | v | | +--------------+ 251 | +------------+ | | |Media Server | 252 | | Resource | | | +--------------+ 253 | | Manager +----+ | | +----------+ | 254 | +--+---------+ | | +-> | Media | | 255 +----|------^----+ +-----> | Contents | | 256 | | | +----------+ | 257 | +-------+ +--------------+ 258 | | 259 +----|--------------|--------------------+ 260 | | | Management Server | 261 +----v--------------|--------------------+ 262 | +------+ +-+-------+ | 263 | | Web | | Client | | 264 | | APIs | | Manager | | 265 | +------+ +---------+ | 266 | +---------+ ^ | 267 | v | | 268 | +----------+ +------+-----+ | 269 | | Topology +-->| Topology | | 270 | | Database | | Calculator | | 271 | +----------+ +------------+ | 272 +----------------------------------------+ 274 Figure 2: System component 276 Figure 2 shows a simple component diagram of this architecture. When 277 a Media Client starts to obtain media contents from Media Servers, 278 the program information manager of the client first get the program 279 list from program servers. The program lists are described in the 280 media presentation description(MPD) format of MPEGDash. The resource 281 manager then access to the resource usage request Web API on the 282 management server. When received a request from a client, the 283 management server calculate the allocatable bandwidth between the 284 Media Client and the Media Server via the topology calculator. Then 285 the client manager of the management server respond a resource usage 286 report to the Media Client. Based on the information in the resource 287 usage report, the Media Client trigger resource allocation by 288 accessing the resource request Web API on the management server. 289 Then the management server allocate bandwidth to the client via the 290 topology calculator and send success message back to the client. 292 5. API 294 5.1. Service definition language 296 Network administrators define the service specifications utilizing 297 the service specification language, Network Description Language(NDL) 298 and Service Description Language(SDL). NDL is to define the group of 299 network components such as router groups. With SDL, administrators 300 can define service specifications on the network. Service 301 specifications are the descriptions which define the relationship 302 between network devices or network groups that compose network 303 services. Examples of service definitions are network configurations 304 such as segment IP address blocks or VLAN id for the segment. An 305 example of NDL/SDL is shown in Figure 3 and Figure 4 307 node { 308 ovs1; 309 ovs2; 310 media1; 311 media2; 312 pc11; 313 pc12; 314 pc13; 315 pc14; 316 pc21; 317 pc22; 318 pc23; 319 pc24; 320 } 321 location { 322 loc1 { 323 media1; 324 ovs1; 325 pc11; 326 pc12; 327 pc13; 328 pc14; 329 } 330 loc2 { 331 media2; 332 ovs2; 333 pc21; 334 pc22; 335 pc23; 336 pc24; 337 } 338 } 339 group { 340 group101 { 341 media1; 342 media2; 343 pc11; 344 pc12; 345 pc13; 346 pc14; 347 pc21; 348 pc22; 349 pc23; 350 pc24; 351 ovs1; 352 ovs2; 353 } 354 group1623 { 355 ovs1; 356 ovs2; 357 } 358 group1624 { 359 ovs1; 360 ovs2; 361 } 362 group1625 { 363 ovs1; 364 ovs2; 365 } 366 } 367 link { 368 type = layer1; 369 edge1 = pc11; 370 edge2 = pc12; 371 } 373 Figure 3: Example of NDL 375 networks { 376 network group101 { 377 address = "192.168.1.0/24"; 378 vlan = 101; 380 device ovs1 { 381 type = L2Switch; 382 address = "192.168.1.1"; 383 } 385 device ovs2 { 386 type = L2Switch; 387 address = "192.168.1.2"; 388 } 390 device media1 { 391 type = Server; 392 address = "192.168.1.30"; 393 } 395 device media2 { 396 type = Server; 397 address = "102.168.1.31"; 398 } 399 } 400 } 402 Figure 4: Example of SDL 404 SDL also enables registrations of events on the network and event 405 bound actions. For example, if the traffics from certain source IP 406 address exceeds the defined per-flow bandwidth limitation on the 407 certain physical link, the traffic can be automatically shaped 408 according to the definitions of SDL. Administrators define resource 409 usage limitation using this functionality of SDL. For example, 410 administrators can limit the usage of bandwidth per the domain to 411 which user equipments attached. The bandwidth allocation for each 412 user is determined based on these service specifications. 414 5.2. Web API 416 5.2.1. Resource usage report 418 Media servers advertise resource usage of links to Media Servers. 419 The resource usage reports have two types. One is periodic resource 420 usage reports broadcasted from management servers. Periodic usage 421 reports include the uplink bandwidth usage of each servers(Figure 5). 422 Another resource usage type is solicited usage report which is 423 delivered to clients through WebAPI on the management servers. In a 424 solicited usage report request(Figure 6), a Media Client specify the 425 server from which it want to download media contents. The Media 426 Server which received the solicited usage reports calculates the 427 physical link set which connect the client and the server, and report 428 available bandwidth the management server afford to allocate to the 429 client(Figure 7). If multiple paths between the client and the 430 server exist, the max available bandwidth will be returned to the 431 client. At a solicited resource usage report request, a Media Client 432 opens a web socket to the management server. 434 { 435 [ 436 { 437 "server": 438 "resource": { 439 "bandwidth": // Option 440 "latency": // Option 441 } 442 }, 443 ... 444 ] 445 } 447 Figure 5: Unsolicited resource usage report json format 449 o server: server IP address or FQDN in string 451 o resource: available resource of the server 453 { 455 "from": 456 "to": 457 } 459 Figure 6: Solicited resource usage report request json format 461 o from: from IP address or FQDN in string 463 o to: to IP address or FQDN in string 464 { 466 "resource": { 467 "bandwidth": // Option 468 "latency": // Option 469 } 470 } 472 Figure 7: Solicited resource usage report response json format 474 o resource: available resource of the server 476 5.2.2. Resource request 478 Media clients acquire reserved communication paths by accessing 479 resource requests API on the management server. The resource 480 requests have three types, initial resource request, resource 481 modification request from clients and management server trigger 482 resource modification request. We explain these types of resource 483 requests in this section. According to the session_id information in 484 the request, management server associate the web socket object of the 485 request source client and the session-id. 487 The clients post json format requests on the reservation. Figure 8 488 is the format of the resource request json. 490 { 491 "session_id": 492 "class": 493 "type": 494 "server": 495 "resource": { 496 "bandwidth": // Option 497 "latency": // Option 498 } 499 } 501 Figure 8: Resource request json format 503 o session_id: random created UUID to identify the session 505 o class: user priority class in digit number 507 o type: 0: Initial 1: Modification 509 o server: the server to which the client willing to connect 511 o resource: resource object contains bandwidth and latency 513 5.2.2.1. Initial resource request 515 +------+ +------------+ +------+ 516 |Media | | Management | |Media | 517 |Client| | Server | |Server| 518 +--+---+ +------------+ +------+ 519 | | 520 | | 522 | | | 523 | RRRQ | | 524 +---------------> | | 525 | + | 526 | | 527 | RRRQR | 528 +--------------------------------> | 529 | | 530 | + RRRQ | 531 | | <--------------+ 532 | | | 533 | | RRRS | 534 | +--------------> | 535 | | | 536 | RRRS | | 537 | <---------------+ | 538 | + | 539 | RRRQS | 540 | <--------------------------------+ 541 | | 542 + + 544 Figure 9: Initial resource request sequence 546 o RURR: Resource Usage Report Request 548 o RURA: Resource Usage Report Advertisement 550 o RRRQ: Resource Reservation ReQuest 552 o RRRS: Resource Reservation ReSponse 554 o RRRQR: Resource Reservation ReQuest Request 556 o RRRQS: Resource Reservation ReQuest Response 558 A Media Client initially obtains a contents list on the Media Server. 559 This contents list is described in the media presentation description 560 (MPD) format of MpegDash. The acquisition of contents list is done 561 by ordinal HTTP GET method. Then the client request resource usage 562 reports to the management server as mentioned in Section 5.2.1. 563 Based on information in the resource usage report and contents list, 564 the client determine the contents bitrate and send a resource request 565 to the management server based on the determined contents bitrate. 566 The resource request contains a session-id randomly generated on 567 clients(ex) UUID). The client simultaneously send a resource 568 reservation request request to Media Server to trigger Media Server 569 to send a request to the management server. The RRRQR also contains 570 same session-id as resource request. The management server verify 571 the request from the Media Server and the Media Client, and send 572 response to both side if the information from the client and the 573 server correspond. The management server stores the session-id, web 574 socket information and allocated resources. These information are 575 used for resource modifications and keep-alive. After received RRRS 576 indicating the resource reservation was done successfully, the Media 577 Server send RRRQS to the Media Client. Then the client get to be 578 able to download the media contents with guaranteed quality. 580 5.2.2.2. Client trigger resource modification request 582 A Media Client MAY offer resource modification requests when resource 583 usage reports say the uplink capacity of the Media Server from which 584 the client downloads the media contents. 586 +------+ +------------+ +------+ 587 |Media | | Management | |Media | 588 |Client| | Server | |Server| 589 +--+---+ +------------+ +------+ 590 | | 591 | RRRQ + | 592 +---------------> | | 593 | + | 594 | | 595 | RRRQR | 596 +--------------------------------> | 597 | | 598 | + RRRQ | 599 | | <--------------+ 600 | | | 601 | | RRRS | 602 | +--------------> | 603 | | | 604 | RRRS | | 605 | <---------------+ | 606 | + | 607 | RRRQS | 608 | <--------------------------------+ 609 | | 610 + + 612 Figure 10: Resource modification sequence (client trigger) 614 5.2.2.3. Management server trigger resource modification request 615 +------+ +------------+ +------+ 616 |Media | | Management | |Media | 617 |Client| | Server | |Server| 618 +--+---+ +------------+ +------+ 619 | | 620 | RRMRQ + | 621 | <---------------+ | 622 | | | 623 | RRRQ | | 624 +---------------> | | 625 | + | 626 | | 627 | RRRQR | 628 +--------------------------------> | 629 | | 630 | + RRRQ | 631 | | <--------------+ 632 | | | 633 | | RRRS | 634 | +--------------> | 635 | | | 636 | RRRS | | 637 | <---------------+ | 638 | + | 639 | RRRQS | 640 | <--------------------------------+ 641 | | 642 + + 644 Figure 11: Resource modification sequence (management server trigger) 646 RRMRQ: Resource reservation modification request. 648 Management servers MAY trigger resource downgrade/upgrade requests to 649 Media Clients, when the used bandwidth of a certain link saturate or 650 become to have room. This push messaging can be done by Web sockets 651 or WebRTC. As resource reservation modification request contains 652 available resource for the received client, client determine the 653 contents bitrate based on the information contained in RRMRQ and pre- 654 downloaded contents list information at the initial resource 655 reservation. The following process is similar to the initial 656 resource reservation described in Section 5.2.2.1. 658 5.2.2.4. Resource cancellation 660 When a client do not need the allocated resources, the client can 661 explicitly stop using the resource by posting a json described in 662 Figure 12. Upon receiving cancellation message, the management 663 server disassociate session-id from the client websocket, and release 664 the resource bound to the session-id. 666 { 667 "session_id": 668 } 670 Figure 12: Resource cancel json format 672 5.2.3. Keep-alive 674 Management servers MAY keep-alive the clients to keep monitoring the 675 usage of the reserved resources. While the clients can send resource 676 free messages explicitly at the end of media streaming, client 677 computers tend to disconnect from the networks suddenly or the 678 browser applications can be reloaded by user operations. To avoid 679 such kind of wasted resources, management servers send keep-alive 680 messages include the session-ids sent from the clients at the initial 681 resource reservations. When received a keep-alive message, the 682 client verify the session-id contained in the keep-alive message. If 683 the keep-alive message is not the one the client stores, the client 684 ignore the keep-alive messages. If the server do not receive the 685 keep-alive responses from the client for certain configured times, 686 the server free the resource bound to the session-id. By default, 687 the keep-alive interval is 300 seconds and the default keep-alive 688 timeout count is 3. 690 6. Security Considerations 692 TBD 694 7. IANA Considerations 696 TBD 698 8. Acknowledgement 700 The author would like to thank Yasuo Okabe, Osamu Nakamura and Kaoru 701 Maeda for their good contributions to this document. 703 9. References 705 9.1. Normative References 707 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 708 6455, December 2011. 710 9.2. Informative References 712 [MPEGDASH] 713 "ISO/IEC 23009-1:2014: Dynamic adaptive streaming over 714 HTTP (DASH) -- Part 1: Media presentation description and 715 segment formats", May 2014, 716 . 719 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 720 Bierman, "Network Configuration Protocol (NETCONF)", RFC 721 6241, June 2011. 723 Authors' Addresses 725 Yoshiharu Tsuzaki 726 Kyoto University 728 Email: tsuzakiyo@net.ist.i.kyoto-u.ac.jp 730 Ray Atarashi 731 IIJ Innovation Institute Inc. 733 Email: ray@iijlab.net 735 Shigeya Suzuki 736 Keio University 738 Email: shigeya@wide.ad.jp 740 Koshiro Mitsuya 741 Lepidum Co. Ltd. 743 Email: mitsuya@lepidum.co.jp 745 Kouji Okada 746 Lepidum Co. Ltd. 748 Email: okd@lepidum.co.jp