Internet DRAFT - draft-li-appsawg-virtualized-application-protocol
draft-li-appsawg-virtualized-application-protocol
APPSAWG K. Li
Internet-Draft Huawei Technologies
Intended status: Informational March 12, 2012
Expires: September 13, 2012
Virtualized Application: Problem Statement
draft-li-appsawg-virtualized-application-protocol-01
Abstract
Virtualized Application aims to enable the user device to remotely
consume various applications on the network. This involves having
all the virtualized applications hosted in the network and from there
providing them to the users using cloud computing technologies like
virtualization. This document tries to explain the problems to
achieve the virtualized applications.
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 September 13, 2012.
Copyright Notice
Copyright (c) 2012 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
(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
Li Expires September 13, 2012 [Page 1]
Internet-Draft VAP March 2012
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology and Abbreviation . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Online Application Trials . . . . . . . . . . . . . . . . . 5
3.1.1. Short Description . . . . . . . . . . . . . . . . . . . 5
3.1.2. Market benefits . . . . . . . . . . . . . . . . . . . . 5
3.2. OS-independent application . . . . . . . . . . . . . . . . 5
3.2.1. Short Description . . . . . . . . . . . . . . . . . . . 5
3.2.2. Market benefits . . . . . . . . . . . . . . . . . . . . 6
3.3. Application session suspend resume . . . . . . . . . . . . 6
3.3.1. Short Description . . . . . . . . . . . . . . . . . . . 6
3.3.2. Market benefits . . . . . . . . . . . . . . . . . . . . 6
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . . 6
4.1. Architecture Diagram . . . . . . . . . . . . . . . . . . . 6
4.2. Virtualized Application Client . . . . . . . . . . . . . . 7
4.3. Virtual Machine . . . . . . . . . . . . . . . . . . . . . . 7
5. Possible Standard Opportunities . . . . . . . . . . . . . . . . 8
6. Difference With Virtual Desktop Infrastructure Proposal . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Li Expires September 13, 2012 [Page 2]
Internet-Draft VAP March 2012
1. Introduction
The basic idea of the Virtualized Application is that, the applicaion
is running on the network server, the network server sends screen
streams to the user device, the user can use a client on the device
to view the screen streams. And the client can capture the user's
interaction with the application and send the user interactivity to
the network server. The network server renders user interactivity on
the hosted application. In this way, the user can remotely consume
various applications without installing the applciations on the user
device.
Virtualized Application provides some application consumption models:
o OS-Independent applications: This enables users to use
applications irrespective of the Operating System they are using.
This will increase the application availability for users and vice
versa.
o On-line applications: This allows users to use applications online
instead of downloading them on to their devices. This will allow
users to overcome terminal barriers (e.g memory) and accessing
virtualized applications from any terminal at any time.
o No-loss reconnection: This enables users to reconnect to an
abnormally suspended virtualized application session without
application data being lost.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology and Abbreviation
o OS: Operation System
o VA: Virtual Application
o VAC: Virtual Application Client
o VM: Virtual Machine
Li Expires September 13, 2012 [Page 3]
Internet-Draft VAP March 2012
2. Problem Statement
With the advancement of high profile applications (e.g games) and
various available platforms, the service consumption is becoming
complex and difficult. The number of devices available with
different hardware and software specification is making things worse.
Applications are being developed for a particular platform and with
strict hardware and software requirements. These constraints mostly
proved to be a hurdle for the complete value chain:
o Users can only use applications which are compliant to their
device hardware and software platform specification.
o Content providers have to create multiple versions of the
application depending on which hardware and software platform they
want them to execute on.
o Despite of knowing this inconvenience of their users and partnered
Content Provider, service providers can't do much to help their
subscribers.
In an attempt to solve the problem, it is possible to optimize the
current application usage model by providing a unified platform
(cloud computing platform) which can host various applications,
enabling different content and services, remotely in the cloud and
provide them to the user using virtualization techniques (cloud
computing).
This will aid end-user to use virtualized applications irrespective
of the platform they are using with consistent user experience as
compared to using applications hosted locally on the device. The
user only needs to install Virtualized Application Client on his/her
device. In addition to that, developers don't have to create a
different version (for each mobile OS) of a single application, and
service providers can offer a larger selection of applications and
services to their end-users reducing costs.
Currently, most of existing Virtualized Application systems are based
on proprietary implementation, and targeting different market with
different features. Each of the current implementations provides
bundle of components based on proprietary implementation, it's
difficult to interwork between different vendors. Since virtualized
application technology is believed that it will become a mainstream
application delivery method, so it's important to make the
virtualized application access protocol open and standardized.
Li Expires September 13, 2012 [Page 4]
Internet-Draft VAP March 2012
3. Use Cases
3.1. Online Application Trials
This use case describes how a user can try-out the application
remotely on the server-side without first downloading them on his/her
device.
Note: There might be another use case when a user want to suspend and
resume an application session voluntarily.
3.1.1. Short Description
Alice goes to a SP (App Store) searching for an application related
with racing games. She found one application which cost about $20.
Considering the cost Alice went into dilemma whether to buy that
application or not. She found a button saying "On-line Trial", she
clicked that button and a window popped-up on her mobile device in
which the games got initialized instantly. She tried that game,
played for about 10-15 minutes and decided to go for that game. She
then went for the download/buy process.
3.1.2. Market benefits
Alice doesn't have to first choose, buy, download, install, run, play
the game and then in case she doesn't like it uninstall, probably ask
for refund and then again start from choosing another game. Instead,
she can go for online trial, make up her mind and then buy and
download the game.
3.2. OS-independent application
This use case describe how a user can use any application
irrespective of the device platform he/she is using and the device
platform the application is built for. This is achieved by hosting
applications on the network-side and allowing users to use that
application remotely from their terminal.
3.2.1. Short Description
Alice is having a device with Symbian OS. She goes to an App Store
with an intention to buy an application. She liked an application
but found that the application is for Andriod device only. She was
also provided with an option to use that application from any OS i.e
"Online Subscription". Alice found it feasible to go for this option
and successfully subscribed for the "Online Subscription" for that
application. Now Alice can use this application online as and when
required irrespective of the OS that she is using.
Li Expires September 13, 2012 [Page 5]
Internet-Draft VAP March 2012
3.2.2. Market benefits
User doesn't have to take their device platform in consideration
while choosing a suitable application of their needs. Developers
don't have to create different version (for each mobile OS) of a
single application.
3.3. Application session suspend resume
This use case describes how a user can reconnect to the UVE enabled
services in case of an unexpected connection failure. This also
explains what user can get (or expect) at the reconnection.
3.3.1. Short Description
Alice is using a UVE enabled application. Alice is allowed to save
the application state at any time.
At some point of time after getting disconnected, due to any reason
(e.g bad network), Alice tries to reconnect with the application. At
the reconnection, Alice is provided with an option to reload the
application from one of the saved states. Alice then continues using
the application from that state.
It is possible that Alice did not save the application. In this
case, at reconnection, Alice continues using the application from the
point where she was disconnected.
3.3.2. Market benefits
This will enable service continuity for users.
4. Architecture Overview
4.1. Architecture Diagram
The architecture diagram is shown below.
----------------- --------------------
| | | |
| Virtualized | Virtualized | |
| Application | <--------------> | Virtual Machine |
| Client | Application | |
| | Protocol | |
----------------- --------------------
Li Expires September 13, 2012 [Page 6]
Internet-Draft VAP March 2012
Figure 1: Architecture Diagram
4.2. Virtualized Application Client
Virtualized Application Client is a device side component residing in
the terminals enabling virtualized applications and utilizing
virtualization technology to enable underlying operating system
agnostic applications. It is mainly responsible for:
o Output rendering: On receiving Output Stream form Virtual Machine,
Virtualized Application Client renders Output Stream to the user.
o Interaction provisioning: Virtualized Application Client is also
responsible to transfer interactions commands to the Virtual
Machine, where they get executed on the Virtualized Application
Client.
o Local Resource Provisioning: Virtualized Application Client is
responsible for providing local resource to Virtual Machine as per
the client requirements. Client may use local device APIs to get
the Local Resource data.
4.3. Virtual Machine
Virtual Machine is a server side component emulating different
operating systems and responsible for::
o Application Hosting: The basic responsibility of Virrual Machine
is to host the Virtualized Applications. The Virtualized
Application can be hosted on Virtual Machine dynamically at
runtime or they can be pre-configured.
o Output generation: Virtual Machine is the entity which will
actually interact with Virtualized Application Client in the
Virtualized Application session. One of the main responsibilities
of Virtual Machine is to capture the application display
periodically and creating a single video stream (Output Stream) to
be transferred to Virtualized Application Client. Where, that
will be rendered to the user by Virtualized Application.
o Local Resource Rendering: Virtual Machine is responsible to
provide Local Resource data (received from Virtualized Application
Client) to the Virtualized Application.
o Interaction Execution: Virtual Machine is responsible to execute
interaction commands on the Virtualized Application.
Li Expires September 13, 2012 [Page 7]
Internet-Draft VAP March 2012
5. Possible Standard Opportunities
A standardized protocol is needed, to exchange request/response
between Virtualized Application Client and Virtual Machine. The
message exchanges may include:
o Application Session Request: Client can request an application
session with the Virtual Machine. The parameters may include:
screen coordinate, device capability, mouse action (left click,
right click, scroll down, scroll up), keyboad keys, compass.
o Output Stream Response: Virtual Machine sends application output
streams to the Virtualized Application Client. It can be based on
the stream transmission protocols, for example, RTSP.
o Sesssion Suspend Request/Response: Client can request to suspend
an application session, and Virtual Machine should keep the
application state and send response to Client.
o Session Resume Request/Response: Client can request to rwsume an
application session, and Virtual Machine should keep the
application state and send response to Client.
6. Difference With Virtual Desktop Infrastructure Proposal
Virtualized Desktop Infrastructure [
[I-D.wang-clouds-vdi-problem-statement]] aims to provide capability
for the client to access a remote virtual desktop using
virtualization technologies.
The differences between Virtualized Application and Virtualized
Desktop Infrastructure are:
o VDI focuses on the whole desktop, but virtualized application
focuses on one specific application, instead of the whole desktop.
o VDI requires the server to send the whole desktop stream to the
client, but virtualized application just needs to show the screen
for one specific application to the client.
o VDI requires the client to send the user interactivity to the
desktop to the Virtual Machine, but virtualized application just
needs to send user interactivity related to one specific
application.
o VDI will not use the local resource of the user device, but
Virtualized Application can use the local resource on the user
Li Expires September 13, 2012 [Page 8]
Internet-Draft VAP March 2012
device.
o VDI does not require session suspend/resume, but this is required
by Virtualized Application.
o VDI does not cover OS independent use case, usually the VDI Client
uses the same OS with Virtual Machine. But for Virtualized
Application, one main use case is to support OS-independent use
case, that means, client can use a different OS with Virtual
Machine.
7. IANA Considerations
This memo currently includes no request to IANA.
8. Security Considerations
User should be authenticated and authorized to consume the
Virtualized Applications hosted on the Virtual Machine.
9. Acknowledgements
Thanks to Deepanshu Gautam for the discussion and some initial texts.
10. Normative References
[I-D.wang-clouds-vdi-problem-statement]
Wang, J., Ma, S., and L. Liang, "Virtual Desktop
Infrastructure Problem Statement",
draft-wang-clouds-vdi-problem-statement-00 (work in
progress), January 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Li Expires September 13, 2012 [Page 9]
Internet-Draft VAP March 2012
Author's Address
Kepeng Li
Huawei Technologies
Huawei Base, Bantian, Longgang District
Shenzhen, Guangdong 518129
P. R. China
Phone: +86-755-28974289
Email: likepeng@huawei.com
Li Expires September 13, 2012 [Page 10]
