idnits 2.17.1 draft-li-appsawg-virtualized-application-protocol-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 12, 2012) is 4400 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.wang-clouds-vdi-problem-statement' is defined on line 383, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 APPSAWG K. Li 3 Internet-Draft Huawei Technologies 4 Intended status: Informational March 12, 2012 5 Expires: September 13, 2012 7 Virtualized Application: Problem Statement 8 draft-li-appsawg-virtualized-application-protocol-01 10 Abstract 12 Virtualized Application aims to enable the user device to remotely 13 consume various applications on the network. This involves having 14 all the virtualized applications hosted in the network and from there 15 providing them to the users using cloud computing technologies like 16 virtualization. This document tries to explain the problems to 17 achieve the virtualized applications. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 13, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 55 1.2. Terminology and Abbreviation . . . . . . . . . . . . . . . 3 56 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Online Application Trials . . . . . . . . . . . . . . . . . 5 59 3.1.1. Short Description . . . . . . . . . . . . . . . . . . . 5 60 3.1.2. Market benefits . . . . . . . . . . . . . . . . . . . . 5 61 3.2. OS-independent application . . . . . . . . . . . . . . . . 5 62 3.2.1. Short Description . . . . . . . . . . . . . . . . . . . 5 63 3.2.2. Market benefits . . . . . . . . . . . . . . . . . . . . 6 64 3.3. Application session suspend resume . . . . . . . . . . . . 6 65 3.3.1. Short Description . . . . . . . . . . . . . . . . . . . 6 66 3.3.2. Market benefits . . . . . . . . . . . . . . . . . . . . 6 67 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Architecture Diagram . . . . . . . . . . . . . . . . . . . 6 69 4.2. Virtualized Application Client . . . . . . . . . . . . . . 7 70 4.3. Virtual Machine . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Possible Standard Opportunities . . . . . . . . . . . . . . . . 8 72 6. Difference With Virtual Desktop Infrastructure Proposal . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 76 10. Normative References . . . . . . . . . . . . . . . . . . . . . 9 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 The basic idea of the Virtualized Application is that, the applicaion 82 is running on the network server, the network server sends screen 83 streams to the user device, the user can use a client on the device 84 to view the screen streams. And the client can capture the user's 85 interaction with the application and send the user interactivity to 86 the network server. The network server renders user interactivity on 87 the hosted application. In this way, the user can remotely consume 88 various applications without installing the applciations on the user 89 device. 91 Virtualized Application provides some application consumption models: 93 o OS-Independent applications: This enables users to use 94 applications irrespective of the Operating System they are using. 95 This will increase the application availability for users and vice 96 versa. 98 o On-line applications: This allows users to use applications online 99 instead of downloading them on to their devices. This will allow 100 users to overcome terminal barriers (e.g memory) and accessing 101 virtualized applications from any terminal at any time. 103 o No-loss reconnection: This enables users to reconnect to an 104 abnormally suspended virtualized application session without 105 application data being lost. 107 1.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 1.2. Terminology and Abbreviation 115 o OS: Operation System 117 o VA: Virtual Application 119 o VAC: Virtual Application Client 121 o VM: Virtual Machine 123 2. Problem Statement 125 With the advancement of high profile applications (e.g games) and 126 various available platforms, the service consumption is becoming 127 complex and difficult. The number of devices available with 128 different hardware and software specification is making things worse. 129 Applications are being developed for a particular platform and with 130 strict hardware and software requirements. These constraints mostly 131 proved to be a hurdle for the complete value chain: 133 o Users can only use applications which are compliant to their 134 device hardware and software platform specification. 136 o Content providers have to create multiple versions of the 137 application depending on which hardware and software platform they 138 want them to execute on. 140 o Despite of knowing this inconvenience of their users and partnered 141 Content Provider, service providers can't do much to help their 142 subscribers. 144 In an attempt to solve the problem, it is possible to optimize the 145 current application usage model by providing a unified platform 146 (cloud computing platform) which can host various applications, 147 enabling different content and services, remotely in the cloud and 148 provide them to the user using virtualization techniques (cloud 149 computing). 151 This will aid end-user to use virtualized applications irrespective 152 of the platform they are using with consistent user experience as 153 compared to using applications hosted locally on the device. The 154 user only needs to install Virtualized Application Client on his/her 155 device. In addition to that, developers don't have to create a 156 different version (for each mobile OS) of a single application, and 157 service providers can offer a larger selection of applications and 158 services to their end-users reducing costs. 160 Currently, most of existing Virtualized Application systems are based 161 on proprietary implementation, and targeting different market with 162 different features. Each of the current implementations provides 163 bundle of components based on proprietary implementation, it's 164 difficult to interwork between different vendors. Since virtualized 165 application technology is believed that it will become a mainstream 166 application delivery method, so it's important to make the 167 virtualized application access protocol open and standardized. 169 3. Use Cases 171 3.1. Online Application Trials 173 This use case describes how a user can try-out the application 174 remotely on the server-side without first downloading them on his/her 175 device. 177 Note: There might be another use case when a user want to suspend and 178 resume an application session voluntarily. 180 3.1.1. Short Description 182 Alice goes to a SP (App Store) searching for an application related 183 with racing games. She found one application which cost about $20. 184 Considering the cost Alice went into dilemma whether to buy that 185 application or not. She found a button saying "On-line Trial", she 186 clicked that button and a window popped-up on her mobile device in 187 which the games got initialized instantly. She tried that game, 188 played for about 10-15 minutes and decided to go for that game. She 189 then went for the download/buy process. 191 3.1.2. Market benefits 193 Alice doesn't have to first choose, buy, download, install, run, play 194 the game and then in case she doesn't like it uninstall, probably ask 195 for refund and then again start from choosing another game. Instead, 196 she can go for online trial, make up her mind and then buy and 197 download the game. 199 3.2. OS-independent application 201 This use case describe how a user can use any application 202 irrespective of the device platform he/she is using and the device 203 platform the application is built for. This is achieved by hosting 204 applications on the network-side and allowing users to use that 205 application remotely from their terminal. 207 3.2.1. Short Description 209 Alice is having a device with Symbian OS. She goes to an App Store 210 with an intention to buy an application. She liked an application 211 but found that the application is for Andriod device only. She was 212 also provided with an option to use that application from any OS i.e 213 "Online Subscription". Alice found it feasible to go for this option 214 and successfully subscribed for the "Online Subscription" for that 215 application. Now Alice can use this application online as and when 216 required irrespective of the OS that she is using. 218 3.2.2. Market benefits 220 User doesn't have to take their device platform in consideration 221 while choosing a suitable application of their needs. Developers 222 don't have to create different version (for each mobile OS) of a 223 single application. 225 3.3. Application session suspend resume 227 This use case describes how a user can reconnect to the UVE enabled 228 services in case of an unexpected connection failure. This also 229 explains what user can get (or expect) at the reconnection. 231 3.3.1. Short Description 233 Alice is using a UVE enabled application. Alice is allowed to save 234 the application state at any time. 236 At some point of time after getting disconnected, due to any reason 237 (e.g bad network), Alice tries to reconnect with the application. At 238 the reconnection, Alice is provided with an option to reload the 239 application from one of the saved states. Alice then continues using 240 the application from that state. 242 It is possible that Alice did not save the application. In this 243 case, at reconnection, Alice continues using the application from the 244 point where she was disconnected. 246 3.3.2. Market benefits 248 This will enable service continuity for users. 250 4. Architecture Overview 252 4.1. Architecture Diagram 254 The architecture diagram is shown below. 256 ----------------- -------------------- 257 | | | | 258 | Virtualized | Virtualized | | 259 | Application | <--------------> | Virtual Machine | 260 | Client | Application | | 261 | | Protocol | | 262 ----------------- -------------------- 263 Figure 1: Architecture Diagram 265 4.2. Virtualized Application Client 267 Virtualized Application Client is a device side component residing in 268 the terminals enabling virtualized applications and utilizing 269 virtualization technology to enable underlying operating system 270 agnostic applications. It is mainly responsible for: 272 o Output rendering: On receiving Output Stream form Virtual Machine, 273 Virtualized Application Client renders Output Stream to the user. 275 o Interaction provisioning: Virtualized Application Client is also 276 responsible to transfer interactions commands to the Virtual 277 Machine, where they get executed on the Virtualized Application 278 Client. 280 o Local Resource Provisioning: Virtualized Application Client is 281 responsible for providing local resource to Virtual Machine as per 282 the client requirements. Client may use local device APIs to get 283 the Local Resource data. 285 4.3. Virtual Machine 287 Virtual Machine is a server side component emulating different 288 operating systems and responsible for:: 290 o Application Hosting: The basic responsibility of Virrual Machine 291 is to host the Virtualized Applications. The Virtualized 292 Application can be hosted on Virtual Machine dynamically at 293 runtime or they can be pre-configured. 295 o Output generation: Virtual Machine is the entity which will 296 actually interact with Virtualized Application Client in the 297 Virtualized Application session. One of the main responsibilities 298 of Virtual Machine is to capture the application display 299 periodically and creating a single video stream (Output Stream) to 300 be transferred to Virtualized Application Client. Where, that 301 will be rendered to the user by Virtualized Application. 303 o Local Resource Rendering: Virtual Machine is responsible to 304 provide Local Resource data (received from Virtualized Application 305 Client) to the Virtualized Application. 307 o Interaction Execution: Virtual Machine is responsible to execute 308 interaction commands on the Virtualized Application. 310 5. Possible Standard Opportunities 312 A standardized protocol is needed, to exchange request/response 313 between Virtualized Application Client and Virtual Machine. The 314 message exchanges may include: 316 o Application Session Request: Client can request an application 317 session with the Virtual Machine. The parameters may include: 318 screen coordinate, device capability, mouse action (left click, 319 right click, scroll down, scroll up), keyboad keys, compass. 321 o Output Stream Response: Virtual Machine sends application output 322 streams to the Virtualized Application Client. It can be based on 323 the stream transmission protocols, for example, RTSP. 325 o Sesssion Suspend Request/Response: Client can request to suspend 326 an application session, and Virtual Machine should keep the 327 application state and send response to Client. 329 o Session Resume Request/Response: Client can request to rwsume an 330 application session, and Virtual Machine should keep the 331 application state and send response to Client. 333 6. Difference With Virtual Desktop Infrastructure Proposal 335 Virtualized Desktop Infrastructure [ 336 [I-D.wang-clouds-vdi-problem-statement]] aims to provide capability 337 for the client to access a remote virtual desktop using 338 virtualization technologies. 340 The differences between Virtualized Application and Virtualized 341 Desktop Infrastructure are: 343 o VDI focuses on the whole desktop, but virtualized application 344 focuses on one specific application, instead of the whole desktop. 346 o VDI requires the server to send the whole desktop stream to the 347 client, but virtualized application just needs to show the screen 348 for one specific application to the client. 350 o VDI requires the client to send the user interactivity to the 351 desktop to the Virtual Machine, but virtualized application just 352 needs to send user interactivity related to one specific 353 application. 355 o VDI will not use the local resource of the user device, but 356 Virtualized Application can use the local resource on the user 357 device. 359 o VDI does not require session suspend/resume, but this is required 360 by Virtualized Application. 362 o VDI does not cover OS independent use case, usually the VDI Client 363 uses the same OS with Virtual Machine. But for Virtualized 364 Application, one main use case is to support OS-independent use 365 case, that means, client can use a different OS with Virtual 366 Machine. 368 7. IANA Considerations 370 This memo currently includes no request to IANA. 372 8. Security Considerations 374 User should be authenticated and authorized to consume the 375 Virtualized Applications hosted on the Virtual Machine. 377 9. Acknowledgements 379 Thanks to Deepanshu Gautam for the discussion and some initial texts. 381 10. Normative References 383 [I-D.wang-clouds-vdi-problem-statement] 384 Wang, J., Ma, S., and L. Liang, "Virtual Desktop 385 Infrastructure Problem Statement", 386 draft-wang-clouds-vdi-problem-statement-00 (work in 387 progress), January 2011. 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, March 1997. 392 Author's Address 394 Kepeng Li 395 Huawei Technologies 396 Huawei Base, Bantian, Longgang District 397 Shenzhen, Guangdong 518129 398 P. R. China 400 Phone: +86-755-28974289 401 Email: likepeng@huawei.com