Applications Area Working Group S. Ma, Ed.
Internet-Draft L. Liang
Intended status: Informational J. Wang
Expires: November 14, 2011 ZTE Corporation
May 13, 2011
Survey of Virtual Desktop Infrastructure System
draft-ma-appsawg-vdi-survey-00
Abstract
This document presents a survey of VDI (Virtual Desktop
Infrastructure) system. Current popular VDI solutions are focused
on, such as Microsoft RDS, Citrix XenDesktop, Redhat enterprise
virtualization for desktops and VMware View. By analyzing the
architecture and protocol flows of these solutions, the common
features of VDI architecture and protocol are summarized.
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 November 14, 2011.
Copyright Notice
Copyright (c) 2011 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
Ma, et al. Expires November 14, 2011 [Page 1]
Internet-Draft survey of VDI System May 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology and Abbreviation . . . . . . . . . . . . . . . 4
2. Survey of VDI System . . . . . . . . . . . . . . . . . . . . . 5
2.1. Citrix XenDesktop . . . . . . . . . . . . . . . . . . . . 6
2.2. Microsoft RDS . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Redhat Enterprise Virtualization for Desktops . . . . . . 11
2.4. VMware View . . . . . . . . . . . . . . . . . . . . . . . 12
3. VDI Related Protocols . . . . . . . . . . . . . . . . . . . . 14
3.1. T.120 . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14
3.1.2. T.120 protocol suite . . . . . . . . . . . . . . . . . 14
3.1.2.1. Basic architecture . . . . . . . . . . . . . . . . 14
3.2. RDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 16
3.2.2. RDP protocol stack . . . . . . . . . . . . . . . . . . 16
3.2.2.1. Basic architecture . . . . . . . . . . . . . . . . 17
3.2.2.2. Bandwidth saving . . . . . . . . . . . . . . . . . 19
3.2.2.3. User experience improvement . . . . . . . . . . . 20
3.3. SPICE . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 21
3.3.2. SPICE Protocol . . . . . . . . . . . . . . . . . . . . 21
3.3.2.1. Basic architecture . . . . . . . . . . . . . . . . 21
3.3.2.2. Bandwidth saving . . . . . . . . . . . . . . . . . 23
3.3.2.3. User experience improvement . . . . . . . . . . . 23
3.4. ICA . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 24
3.4.2. ICA Protocol . . . . . . . . . . . . . . . . . . . . . 24
3.4.2.1. Basic architecture . . . . . . . . . . . . . . . . 24
3.4.2.2. Bandwidth saving and User experience
improvement . . . . . . . . . . . . . . . . . . . 24
3.5. RFB . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5.1. RFB Protocol . . . . . . . . . . . . . . . . . . . . . 25
3.5.1.1. Basic architecture . . . . . . . . . . . . . . . . 25
3.5.1.2. Bandwidth saving and User experience
improvement . . . . . . . . . . . . . . . . . . . 26
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Normative References . . . . . . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . . 30
Ma, et al. Expires November 14, 2011 [Page 2]
Internet-Draft survey of VDI System May 2011
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Ma, et al. Expires November 14, 2011 [Page 3]
Internet-Draft survey of VDI System May 2011
1. Introduction
Virtual desktop infrastructure (VDI) is the practice of hosting a
desktop operating system within a virtual machine (VM) running on a
centralized server. VDI provides services for users to access their
desktops remotely and users can choose PC, tablet computer or mobile
phone as the client device. The OS (Operating System) and
applications of the desktop are running on virtual machines which are
deployed in Data Center. All desktops are managed under a central
management system.
The benefits of VDI include reduction of IT cost and improvement of
security. Centralized desktop management makes IT maintenance tasks
more effective, for example backup and upgrade can be done on Data
Center side. Since enterprise's data is kept in Data Center, it will
not be lost even when client devices are broken. Users can access
the data but can't copy it out of the datacenter, so the data
security is guaranteed.
The mainstream VDI products include Microsoft's RDS, Citrix's
XenDesktop, Redhat's Enterprise Virtualization for Desktops and
VMware's VMware View. The architecture, features and VDI protocols
of these products are analyzed in this document.
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 Device redirection: In VDI system, remote desktop must provide the
same user experience as local desktop, so the physical interfaces
of client device, such as USB, audio/video interface and serial/
parallel ports should be accessed by Guest OS on remote desktop.
So client device's interfaces must be redirected to remote virtual
machine.
o GCC: Generic Conference Control
o GPU: Graphic Processor Unit
o Guest OS: An OS runs on top of a virtual machine manager.
o HDX: High-Definition user eXperience
Ma, et al. Expires November 14, 2011 [Page 4]
Internet-Draft survey of VDI System May 2011
o ICA: Independent Computing Architecture
o MCS: Multipoint Communication Service
o OS: Operation System
o PDU: Protocol Data Unit
o RD: Remote Desktop
o RDP: Remote Desktop Protocol
o RDS: Remote Desktop Service
o Resource pool: Resource pool is based on a large quantity of
physical server. The computing and storage resources of the
servers are managed as a whole, and it is a logical resource pool
to users. Users need not to know which server the resource is on
when he use it. Resource pool can improve resource's utilization
and scalability, and resource will be managed more effectively.
o RFB: Remote Framebuffer
o SPICE: Simple Protocol for Independent Computing Environment
o TPKT: ISO transport services on top of the TCP
o VDA: Virtual Desktop Agent, which acts as the bridge between
virtual machine and VDI client, such as accepting VDI connection,
taking input from VDI client, transferring graphics output of
virtual machine to VDI client and etc.
o VDI: Virtual Desktop Infrastructure
o VM: Virtual machine is a logical machine. Several virtual
machines can share one physical machine's resource. The virtual
CPU, memory and storage are allocated from physical resource by
virtualization layer software, and they can be scheduled under
certain policy.
o VMM: Virtual Machine Manager
2. Survey of VDI System
Remote terminal technology was brought into market very early, such
as X-WINDOW, Microsoft's Terminal Services and RealVNC's VNC. Early
products are used for server sharing, remote collaboration, and
Ma, et al. Expires November 14, 2011 [Page 5]
Internet-Draft survey of VDI System May 2011
remote control. The messages transferred between server and client
contain screen images and the keyboard/mouse events. VDI inherits
from the remote terminal technology, with exception that the desktops
are not running on physical servers, but in virtual machines.
Virtual machines can be allocated on demand, so VDI is more flexible
and has higher resource utilization. VDI also adopts variety of
technologies to improve user experience, such as enhanced desktop
display quality, supporting for USB/audio/video device redirection
and etc.
2.1. Citrix XenDesktop
XenDesktop is Citrix's VDI solution. For Guest OS in XenDesktop, it
could only be Microsoft's Windows. For Client device, it could
support different platforms, like Windows, Linux and Mac OS.
Virtualization platform can be Citrix's XenServer, or 3rd party's
products, such as Microsoft Hyper-V and VMware ESX. The protocol
between client and server is ICA (Independent Computing
Architecture).
The architecture of XenDesktop is shown in Figure 1:
+-----------+
| Desktop |
| Delivery |
| Controller|
/+-----+-----+
/ |
+----------+ +----------+/ +-----+-----+ +--------------+
| Desktop |--| Access |---| +-------+ | | Application |
| Receiver | | Gateway | | |Virtual| |---| Delivery |
+----------+ +----------+ | |Desktop| | | Controller |
| | +-------+ | +--------------+
+-----+-----+ | XenServer | +--------------+
| Active | | Resource |---| Provisioning |
| Directory | | Pool | | Server |
+-----------+ +-----------+ +--------------+
Figure 1 XenDesktop architecture
The key components of XenDesktop:
1. Desktop Receiver: The client-side software, which is running on
client devices, connects to remote desktop through ICA protocol.
2. Access Gateway: Responsible for external user authentication.
Before the external user accesses the desktop, he must connect to
Ma, et al. Expires November 14, 2011 [Page 6]
Internet-Draft survey of VDI System May 2011
the Access Gateway and pass the authentication. External users's
connection to Access Gateway is secured by SSL.
3. Desktop Delivery Controller: Responsible for management of
virtual desktop and client connection. When a virtual desktop
boots up, it will register with Desktop Delivery Controller.
Desktop Delivery Controller will maintain the state of the
desktop. When a client initiates a connection, Desktop Delivery
Controller chooses an appropriate virtual desktop to connect.
Finally it forwards the client's connection to the desktop.
4. XenServer Resource Pool: XenServer is Citrix's virtualization
platform, provides virtual machine for virtual desktop and
manages all of the virtual machines.
5. Provisioning Server: Responsible for providing OS images. OS
images contain pre-configured profile, but applications are not
included. When virtual desktop boots up, the OS image will be
sent to virtual machine over network.
6. Application Delivery Controller: Responsible for application
delivery. User's profile contains assigned application list, and
user can choose which application to load.
7. Virtual Desktop Agent: Running on virtual desktop, which accepts
the ICA connection from client.
8. Active Directory: Responsible for user authentication.
Besides above specific components, additional general components
could be deployed, such as License server, DNS Server, DHCP Server
and so on.
Before users access their virtual desktops, they must pass the
authentication. Following is the procedure:
1. User launches the browser, and connects to Access Gateway.
Access Gateway generates the login page;
2. User inputs credentials, and Access Gateway authenticates the
user's credentials against Active Directory;
3. Upon successful authentication, Access Gateway connects to
Desktop Delivery Controller;
4. Desktop Delivery Controller retrieves the credentials from Access
Gateway, and authenticates the user against Active Directory;
Ma, et al. Expires November 14, 2011 [Page 7]
Internet-Draft survey of VDI System May 2011
5. After success authentication, Desktop Delivery Controller
determines which virtual desktops are available for the user;
6. Access Gateway creates a web page containing a list of virtual
desktops for the user, and sends the web page to user's browser.
After successful authentication, user can access virtual desktop by
clicking the icon on the web page. Following is the procedure:
1. User clicks the virtual desktop's icon on the web page, Access
Gateway sends the information to Desktop Delivery Controller;
2. Desktop Delivery Controller checks the status of user's virtual
desktop. If there is no available desktop, Desktop Delivery
Controller will request XenServer to launch one. The desktop
then opens the ICA port to wait for client connections;
3. Desktop Delivery Controller creates an ICA file for the virtual
desktop, and transfers the file to Access Gateway. Then Access
Gateway transfers the ICA file to VDI client;
4. After receiving the ICA file, VDI client executes it and sends a
connection request to Access Gateway;
5. Access Gateway forwards the connection request to virtual
desktop;
6. When detecting the connection request, the virtual desktop sends
the logon information to Desktop Delivery Controller for
validation;
7. For valid validation, Desktop Delivery Controller fetches a
license from the license server and sends credentials and license
to virtual desktop. The connection is created after virtual
desktop logon against Active Directory with the credentials.
To optimize user experience, XenDesktop provides HDX (High Definition
eXperience) technology. HDX contains several techniques as
following:
1. HDX MediaStream: Optimized for multimedia stream, the compressed
multimedia packages are transferred in raw format to client
device, and the client device plays them locally;
2. HDX RealTime: Enhances real-time voice and video using advanced
encoding and streaming to ensure a no compromise end-user
experience;
Ma, et al. Expires November 14, 2011 [Page 8]
Internet-Draft survey of VDI System May 2011
3. HDX Broadcast: Optimized for bandwidth to ensure high-performance
of virtual desktops and applications over any network, including
high-latency and low-bandwidth environments. User can set
bandwidth limits and close some features to save bandwidth;
4. HDX Plug-n-Play: Enables devices redirection for USB, printers
and peripherals;
5. HDX RichGraphics: Optimizes for 2D/3D applications by using the
rending ability of server and client;
6. HDX WAN Optimization: Adopts compression and cache technologies
to reduce bandwidth on the WAN.
2.2. Microsoft RDS
RDS (Remote Desktop Service) is next-generation product of Microsoft
TS (Terminal Service). In Windows server 2008 R2, it is named as
RDS. The protocol used in RDS between desktop client and server is
RDP (Remote Desktop Protocol).
The architecture of RDS is presented in Figure 2:
+----------+ +----------+ +-----------+ +--------------+
| RD |--| RD +---| RD |----| RD |
| Client | | Gateway | | Connection|\ |Virtualization|
+----------+ +----------+ | Broker | \ | Host |
+-----+-----+ \ +--------------+
| \
+-----+-----+ +--------------+
| Active | | RD Session |
| Directory | | Host |
+-----------+ +--------------+
Figure 2 RDS architecture
The key components in RDS:
1. RD Client: Remote desktop client software running on client
devices, which connects to virtual desktop using RDP protocol;
2. RD Gateway(RDG): RD Gateway authorizes external RD clients and
provides secure connection for external RD client to access
virtual desktop;
3. RD Connection Broker (RDCB): Responsible for assigning correct
resource to RD clients and session load balancing. User can have
Ma, et al. Expires November 14, 2011 [Page 9]
Internet-Draft survey of VDI System May 2011
a personal desktop, which means that the RDCB assigns the same
virtual machine to the user whenever he logins. RDCB also can
assign virtual machine dynamically. When user logs on, RDCB
selects one from virtual machine pool and assign it to user.
Every user shares the same virtual machine image;
4. Remote Desktop Session Host (RDSH): Responsible for hosting
windows-based programs or the full Windows desktop for RD
clients. Users can connect to an RD Session Host server to run
programs, save files, and use network resources on that server;
5. RD Virtualization Host(RDVH): RDVH integrates with Hyper-V to
provide virtual machines for virtual desktops;
6. Active Directory: Responsible for user access authentication.
The connection procedure for RD Client is shown as below:
1. A RD Session Host works as a RD Redirector. When a client
connects to RD Redirector, RD Redirector forwards the connection
to RD Connection Broker;
2. RD Connection Broker queries personal desktop configuration from
Active Directory;
3. RD Connection Broker retrieves user's virtual machine from RD
Virtualization Host. If user's virtual machine is not running,
RD Virtualization Host will launch it;
4. RD Connection Broker returns the information of virtual machine
to RD Redirector;
5. RD Redirector forwards the information to RD Client,and redirects
RD Client to virtual machine;
6. RD Client connects to virtual machine.
To improve user experience, RDS provides RemoteFX technology in RDP
7.1. RemoteFX contains a set of features shown as following:
1. Host side rendering: Allows graphics to be rendered on the host
device instead of the client device. This enables support for
all graphics types by sending highly compressed bitmap images to
the endpoint device in an adaptive manner. This also allows the
applications to run at full speed on the host computer by taking
advantage of the GPU and the CPU, providing an experience which
is similar to that of a local computer;
Ma, et al. Expires November 14, 2011 [Page 10]
Internet-Draft survey of VDI System May 2011
2. GPU virtualization: Supports several virtual GPU with one
physical GPU, and each virtual GPU is used by one virtual
machine;
3. Intelligent Screen Capture: Only the screen change will be
encoded and transferred to client. Intelligent Screen Capture
also tracks network speed and then dynamically adjusts according
to the available bandwidth;
4. RemoteFX Encoder: Allows encoding to be done either on the
processor, GPU, or dedicated hardware;
5. RemoteFX Decoder: Decodes bitmaps on the client computer which
have been remoted from the virtual desktop to the client
computer. The client computer can decode by using software in
the GPU, processor, or by using a hardware decoder;
6. USB device redirection: Supports all usb devices redirection over
RDP, no client side drivers needed.
2.3. Redhat Enterprise Virtualization for Desktops
Redhat Enterprise Virtualization for Desktops is Redhat's VDI
solution,which supports both Windows and Linux desktop. The protocol
between client and desktop is SPICE (Simple Protocol for Independent
Computing Environment).
The architecture of Redhat Enterprise Virtualization for Desktops is
shown in Figure 3:
+--------+ SPICE +-------------------------+
| SPICE |-------| Redhat Enterprise |
| Client | \ |Virtualization Hypervisor|
+--------+ \ +------------+------------+
\ |
\ +------------+------------+ +---------------+
\ | Redhat Enterprise |---|LDAP Directory/|
\|Virtualization Manager | |Active Directoy|
+-------------------------+ +---------------+
Figure 3 Redhat Enterprise Virtualization for Desktops architecture
The key components of Redhat Enterprise Virtualization for Desktops:
1. SPICE client: The client side software installed on client
devices, which connects to virtual desktop using SPICE protocol;
Ma, et al. Expires November 14, 2011 [Page 11]
Internet-Draft survey of VDI System May 2011
2. SPICE Protocol: An open source VDI protocol, used between SPICE
client and virtual desktop;
3. Red Hat Enterprise Virtualization Hypervisor(RHEV-H): Redhat
virtualization platform to provide virtual machine for virtual
desktops;
4. Red Hat Enterprise Virtualization Manager(RHEV-M): Management
System for all components in Redhat's VDI solution;
5. LDAP Directory/Active Directory: Responsible for authentication.
The connection procedure for SPICE client is described as below:
1. User launches browser and connects to RHEV-M, and RHEV-M returns
a logon page. Then user inputs corresponding ID and password
information;
2. RHEV-M authenticates user against Active Directory;
3. After successful authentication, RHEV-M returns a web page
containing a list of available virtual desktops for the user;
4. User selects the desktop by clicking the icon on the web page.
Then RHEV-M requests RHEV-H to run the specified virtual desktop;
5. The SPICE client connects to the virtual desktop with SPICE
protocol.
2.4. VMware View
VMware View is VMware's virtual desktop solution, which uses VMware
vSphere as the virtualization platform. VMware View supports several
VDI protocols, like Microsoft RDP, PCoIP and HP RGS protocols. For
HP RGS, it can only be used for connecting HP Blades.
The architecture of VMware View is shown in Figure 4.
Ma, et al. Expires November 14, 2011 [Page 12]
Internet-Draft survey of VDI System May 2011
+----------+ +----------+ +-----------+
| View | | View + | |
| Client |--|Connection|---| vSphere |
| | | Server | | |
+----------+ +-----+----+ +-----+-----+
| |
+-----+-----+ +-----+-----+
| Active | | vCenter |
| Directory | | Server |
+-----------+ +-----------+
Figure 4 VMware View architecture
The key components of VMware View:
1. View client: The client software for accessing View desktops,
which runs either on a Windows or Mac PC as a native application
or on a thin client;
2. View Connection Server: View Connection Server acts as a broker
for client connections. It authenticates users through Active
Directory and directs the request to the appropriate virtual
machine;
3. vSphere: The virtualization platform, which provides virtual
machines for virtual desktops;
4. vCenter Server: Management System for configuration, deployment
and virtual machine management;
5. View Agent: View Agent is installed on all virtual machines.
This agent communicates with View Client to provide features such
as connection monitoring, virtual printing, and access to locally
connected USB devices;
VMware View has following features:
1. VMware View supports USB, printers and other peripherals
redirection;
2. Users can configure the amount of bandwidth used by Adobe Flash
content to improve the overall Web browsing experience and make
other applications more responsive;
3. VMware View supports multimedia redirection, and the media file
is send to client to be decoded locally;
Ma, et al. Expires November 14, 2011 [Page 13]
Internet-Draft survey of VDI System May 2011
4. VMware View supports single-sign-on, which means that users need
to log in only once to access virtual desktop;
5. Besides Active Directory authentication, VMware also supports RSA
SecurID and Smart Card authentication.
3. VDI Related Protocols
In this section, current hot-discussed VDI protocols, like RDP, SPICE
and ICA, are investigated. For closed protocol, such as ICA, the
information is collected from published documents on Internet. For
each protocol, they are organized from perspective of: Basic
architecture, Bandwidth saving and User experience improvement.
Bandwidth saving and User experience improvement are two key factors
for VDI protocol success.
3.1. T.120
T.120 is listed here for better understanding of Microsoft's RDP,
which is described in next section.
3.1.1. Introduction
The T.120-series Recommendations, which are issued by ITU,
collectively define a multipoint data communication service for use
in multimedia conferencing environments. Depending on the type of
T.120 implementations, the result product can make connections,
transmit and receive data, and collaborate using compatible data
conferencing features, such as program sharing, whiteboard
conferencing, and file transfer.
The key functionalities of T.120 are:
1. Establish and maintain conferences without any platform
dependence;
2. Manage multiple participants and programs;
3. Send and receive data accurately and securely over a variety of
supported networking connections.
3.1.2. T.120 protocol suite
3.1.2.1. Basic architecture
The T.120 system model is comprised of a communications
infrastructure and the application protocols that make use of it.
Ma, et al. Expires November 14, 2011 [Page 14]
Internet-Draft survey of VDI System May 2011
Figure 5 shows the full model with both standardized and non-
standardized applications.
+-------------------------------------------------------------+
| User applications |
+-------------------------------------------------------------+
| |
+------------------+ +------------------+
| Standard appl. | |Non-standard appl.|
| protocol entity | | protocol entity |
+------------------+ +------------------+
+-------|----------|-----------------------|----------|--------+
| | +---------------------------------+ | |
| | | Generic conference control(GCC) | | |
| | | ITU Rec. T.124 | | |
| | +---------------------------------+ | |
| | | | |
| | | | |
| +---------------------------------------------------------+ |
| | Multipoint communication service(MCS) | |
| | ITU-T Recs T.122 and T.125 | |
| +---------------------------------------------------------+ |
| | |
| +---------------------------------------------------------+ |
| | Network-specific Transport protocols | |
| | ITU-T Rec. T.123 | |
| +---------------------------------------------------------+ |
| |
| ITU-T Rec. T.120 infrastructure Recommendations |
+--------------------------------------------------------------+
Figure 5 T.120 protocol
Generally, each layer provides services to the layer above and
communicates to its peer(s) by sending Protocol Data Units (PDUs) via
services provided by the layer below. The lower level layers (T.122,
T.123, T.124, and T.125) specify an application-independent mechanism
for providing multipoint data communication services to any
application that can use these facilities. The upper level
application layers define protocols, such as shared white boarding
and multipoint file transfer. Applications using these standardized
protocols can co-exist in the same conference with applications using
proprietary protocols.
Following is one brief description of each protocol:
Ma, et al. Expires November 14, 2011 [Page 15]
Internet-Draft survey of VDI System May 2011
1. T.121: T.121 provides a template for T.120 resource management
that developers should use as a guide for building application
protocols. It also provides guidance to user application
developers on how to utilize the T.120 infrastructure in a
coherent and consistent way;
2. T.122:T.122 defines the multi-point services available to the
developer. Together with T.125, they form MCS, the multi-point
"engine" of the T.120 conference. MCS relies on T.123 to
actually deliver the data. MCS is a powerful tool that can be
used to solve virtually any multi-point application design
requirement;
3. T.123: T.123 specifies transport profiles for different transport
networks like, Public Switched Telephone Networks (PSTN),
Integrated Switched Digital Networks (ISDN), TCP/IP and etc.
From perspective of MCS layer, it presents a uniform OSI
transport interface and services (X.214/X.224). Built-in error
correction facilities are also included in this layer;
4. T.124:The T.124 specifies the Generic Conference Control (GCC),
which provides a comprehensive set of facilities for establishing
and managing the multi-point conference;
5. T.125: T.125 defines: 1) Procedures for a single protocol for the
transfer of data and control information from one MCS provider to
a peer MCS provider. 2) The structure and encoding of the MCS
protocol data units used for the transfer of data and control
information.
3.2. RDP
3.2.1. Introduction
Remote Desktop Protocol, which is issued by Microsoft, provides
remote display and input capabilities over network connections for
Windows-based applications running on a server. It is based on, and
is an extension of, the T-120 family of protocol standards. So it
inherits corresponding capabilities and benefits from T.120, such as
the architectural features necessary to support multipoint and
multipoint data delivery, which allows data from an application to be
delivered in "real-time" to multiple parties without having to send
the same data to each session individually.
3.2.2. RDP protocol stack
Ma, et al. Expires November 14, 2011 [Page 16]
Internet-Draft survey of VDI System May 2011
3.2.2.1. Basic architecture
As RDP is an extension of the core T.120 protocol, it re-uses
services from T.123, T.122, T.125 and T.124 of T.120 protocol suite.
In T.120 protocol architecture, RDP is at the same place of
application protocols. It defines application PDU for information
exchange between server and client, like capability set, bitmap
update, keyboard/mouse event and so on.
+---------------------------------------+
| RDP Server |
| +----------------------------------+ |
| | RDP | |
| +----------------------------------+ |
| | | |
| | +----------------+ | +----+
| | | GCC | | | C |
| | +----------------+ |--channel--| L |
| | | | |R I |
| +----------------------------------+ |--- ... --|D E |
| | MCS | | |P N |
| +----------------------------------+ |--channel--| T |
| | | | |
| +----------------------------------+ | +----+
| | ISO transport protocol | |
| +----------------------------------+ |
| | |
| +----------------------------------+ |
| | TCP | |
| +----------------------------------+ |
+---------------------------------------+
Figure 6 RDP protocol
RDP uses channel service provided by MCS layer for lossless
communication between client and server components over the main RDP
data connection. Each channel is targeted for one specific
application data, such as printer redirection, clipboard redirection
and etc.
There are two types of virtual channels in RDP: static virtual
channel and dynamic virtual channel. A maximum of 31 static virtual
channels can be created at connection time. The list of desired
virtual channels is requested and confirmed during the Basic Settings
Exchange phase of the server-client connection sequence and the
endpoints are joined during the Channel Connection phase. Virtual
channel data is application-specific and opaque to RDP. Each virtual
Ma, et al. Expires November 14, 2011 [Page 17]
Internet-Draft survey of VDI System May 2011
channel acts as an independent data stream. The client and server
examine the data received on each virtual channel and route the data
stream to the appropriate endpoint for further processing. Dynamic
virtual channel is put forward to solve the limitation of static
virtual channel number. It is implemented on top of a static virtual
channel named DRDYNVC. In the DRDYNVC static virtual channel,
different services could be allocated and deleted dynamically.
RDP supports two security classifications: standard RDP security and
enhanced RDP security:
1. For standard RDP security, client and server use matched
encryption and decryption keys for data security. The encryption
and decryption keys are generated during connection sequence,
based on random number generated on server and client. The
client and server both generate a 32-byte random value using a
cryptographically-safe pseudorandom number generator. Then the
server sends the random value which it generated (along with its
public key embedded in a certificate) to the client in the Server
Security Data during the Basic Settings Exchange phase of the
connection sequence. After receiving that, the client sends its
random value to the server (encrypted with the server's public
key) in the Security Exchange PDU as part of the RDP Security
Commencement phase of the connection sequence. As the client
doesn't authenticate server credential, this security method
could not protect data from man in-the-middle. It still exists
in RDP for backward compatibility;
2. For enhanced security, RDP traffic is no longer protected by
using the techniques described in standard RDP security.
Instead, all security operations (such as encryption and
decryption, data integrity checks, and server authentication) are
implemented by external security protocols, like TLS. In this
way, there is no longer need to manually implement protocol
security mechanisms, which is replaced with well-known and proven
security protocol packages to provide end-to-end security.
Server redirection procedure is defined in RDP for load-balancing
scenarios. A client connection can be redirected to a specific
session on another server by using the Server Redirection PDU. In
the Server Redirection PDU, necessary information is include, such as
session ID, redirection information flag, user credential
information, load balance information, target server address and etc.
When the client receives this redirection indication, it will
disconnect from current server and try to connect target server,
which is specified in Server Redirection PDU.
In RDP framework, it's flexible to define more service using separate
Ma, et al. Expires November 14, 2011 [Page 18]
Internet-Draft survey of VDI System May 2011
static/dynamic channel.
3.2.2.2. Bandwidth saving
RDP uses a bulk compressor to compress virtual channel data and some
data in PDUs sent from server to client. During information exchange
phase of the connection sequence, server and client negotiate the
bulk compressor. One version of the bulk compressor (the RDP 4.0
bulk compressor) is based on the Microsoft Point-To-Point Compression
(MPPC) Protocol and uses an 8 kilobyte history buffer. A more
advanced version of the compressor (the RDP 5.0 bulk compressor) is
derived from the RDP 4.0 bulk compressor, but uses a 64 kilobyte
history buffer and modified Huffman-style encoding rules. Besides
employing bulk compression for generic data, RDP also uses variations
of run length encoding (RLE) rules to implement compression of bitmap
data sent from server to client. "NSCodec Extension" and "RemoteFX
Codec Extension" (lossy image codec) specify the image codec that can
be used to encode screen images by utilizing efficient and effective
compression.
As RDP is one extension of T.120 protocols, each RDP packet will be
wrapped with corresponding headers defined in T.120 protocols, like
TPKT header, X.224 Class 0 Data TPDU and etc. In some situations,
for example point-to-point connection, these additional overhead is
not necessary. In RDP protocol, it defined two choices: slow-path
which follows strictly T.120 protocols and fast-path with the goal of
improving bandwidth. For fast-path, the TPKT Header, X.224 Class 0
Data TPDU, and MCS Send Data Indication are replaced. The Security
Header is collapsed into the fast-path output header, and the Share
Data Header is replaced by a new fast-path format. The contents of
the graphics and pointer updates are also changed to reduce their
size, particularly by removing or reducing headers.
The real-time display interaction is accomplished by continuously
sending updated bitmap images from server to client. Even though
these bitmaps may be compressed, it is still not a bandwidth
efficient mechanism to employ, especially when dealing with graphics-
intensive applications that refresh regularly. "GDI Acceleration
Extension" aims to reduce the bandwidth associated with graphics
remoting by encoding the drawing operations that produce an image
instead of encoding the actual image. For example, instead of
sending the bitmap image of a filled rectangle from server to client,
an order to render a rectangle at coordinate (X, Y) with a given
width, height, and fill color is sent to the client. The client then
executes the drawing order to produce the intended graphics result.
In addition to defining how to encode common drawing operations, "GDI
Acceleration Extension" also facilitates the use of caches to store
drawing primitives such as bitmaps, color tables, and characters.
Ma, et al. Expires November 14, 2011 [Page 19]
Internet-Draft survey of VDI System May 2011
The effective use of caching techniques helps to reduce wire traffic
by ensuring that items used in multiple drawing operations are sent
only once from server to client (retransmission of these items for
use in conjunction with future drawing operations is not required
after the item has been cached on the client).
For video and audio application, "Video Redirection Virtual Channel
Extension" and "Audio Output Virtual Channel Extension" define video
and audio delivery message and procedure between server and client.
Before stream traffic starts, server and client will exchange their
own capabilities, also for media format. After successful
negotiation, media stream data will be sent between server and client
with both agreed format, for example MPEG-2, instead of transferring
raw data.
3.2.2.3. User experience improvement
For VDI applications, user experience is very important for more
widely acceptance of this technology. When using client component to
access desktop on remote side, the user hopes to get experience of
using local computer, such as real-time interactive, plug-n-play
service, bi-directional multimedia services and etc.
In RDP protocol suite, it uses techniques mentioned in previous
"bandwidth saving" section to improve interactive capability and
multi-media services.
Following extension protocols are defined to mitigate environment
experience of server and client:
1. Clipboard Virtual Channel Extension: specifies how to keep two
distinct system clipboards in sync so that at any given time, the
data available to an application on one computer (via its local
clipboard) is identical to the data available to another
application on a remote computer (via its local clipboard);
2. Remote Programs Virtual Channel Extension: provides support to
present a remote application (running remotely on the server) as
a local user application (running on the client machine). It
extends the core RDP protocol to deliver this seamless windows
experience;
3. File System Virtual Channel Extension: provides support to
redirect access from the server to the client file system. In a
typical terminal server scenario, many of the nonvolatile
resources used by the server (such as hard drives, flash drives,
and floppy disks) are located on the client. The server exposes
a file system driver that is visible to server-based applications
Ma, et al. Expires November 14, 2011 [Page 20]
Internet-Draft survey of VDI System May 2011
as a hard drive, which allows the applications to access the
client file systems;
4. Serial Port Virtual Channel Extension: provides support to
redirect serial and parallel ports from client to the server.
This allows the server to access client ports as if the connected
devices were local to the server;
5. Print Virtual Channel Extension: provides support to redirect
printers from client to the server. This allows the server
access to printers physically connected to the client as if the
devices were local to the server;
6. Smart Card Virtual Channel Extension: is designed to remotely
execute requests on a client's Smart Cards for Windows. When
Smart Card Redirection is in effect, server application smart
card subsystem calls are automatically remapped to the
client"Cside Smart Cards for Windows, which will then receive the
corresponding request;
7. Plug and Play Devices Virtual Channel Extension: This protocol is
used to redirect Plug and Play (PNP) devices from client to the
server, for example USB devices. This allows the server access
to devices that are physically connected to the client as if the
device were local to the server.
3.3. SPICE
3.3.1. Introduction
SPICE was originally developed by Qumranet, which was acquired by Red
Hat in 2008. Later Redhat open sourced its SPICE hosted virtual
desktop protocol. Now open-source SPICE project aims to provide a
complete open source solution for interaction with virtualized
desktop devices. The SPICE protocol, acting similar functions as
Microsoft RDP, provides client and server communication to support
virtual desktop infrastructure.
3.3.2. SPICE Protocol
3.3.2.1. Basic architecture
SPICE protocol defines a set of protocol messages for accessing,
controlling, and receiving inputs from remote computing devices
(e.g., keyboard, video, and mouse) across networks, and sending
output to them. SPICE uses simple messaging and does not depend on
any RPC standard or a specific transport layer.
Ma, et al. Expires November 14, 2011 [Page 21]
Internet-Draft survey of VDI System May 2011
From architecture perspective, SPICE is architected a bit different
than RDP and ICA. While RDP and ICA are made of up two components (a
remote software component that runs in the OS of the Windows host
you're connecting to, and a client), SPICE is actually made up of
three components:
1. Remote guest component: A virtual graphics adapter running in the
VM, just like RDP/ICA
2. Client component; The SPICE client software, just like RDP/ICA;
3. Remote host component: A virtual graphics device which the
hypervisor makes available to the VM.
In other words, because SPICE has a hypervisor component, it will
only work when your remote hosts are VMs.
Similar with RDP, SPICE protocol spilt the communication session into
multiple communication channels. Currently the following
communication channels are defined in the protocol: a) the main
channel serves as the main spice session connection; b) display
channel for receiving remote display updates; c) inputs channel for
sending mouse and keyboard events; d) cursor channel for receiving
pointer shape and position; e) Playback channel for receiving audio
stream; f) Record channel for sending audio capture. More channel
types will be added as the protocol evolves. Since RDP is based on
T.120, it could use channel service from lower layer. But for SPICE,
it has to do channel management along with application protocols,
which may lead to some implementation complexity.
For user authentication in SPICE, the server generates a 1024 bit RSA
key and sends the public part to the client (via RedLinkInfo).
Client uses this key to encrypt the password and send it back to
server (after RedLinkMess). Server decrypt the password, compare it
to ticket.
SPICE doesn't define encryption mechanism in application layer, which
means that it depends on external security protocols for security
guarantee so that having maximum flexibility in choosing an
encryption method.
SPICE defines full server redirection primitives to support live
migration. RDP supports server redirection for load balance purpose,
which means server redirection only occurs during 1st server access.
SPICE could support server redirection during run-time and
corresponding migration process control.
Ma, et al. Expires November 14, 2011 [Page 22]
Internet-Draft survey of VDI System May 2011
3.3.2.2. Bandwidth saving
SPICE uses different compression strategy for different media
resource. It uses QUIC/LZSS/GLZ for lossless image compression.
QUIC (based on SFALIC) and GLZ (based on LZSS with a history-based
global dictionary) are Redhat proprietary algorithms. As the video/
audio is played using different media player in the virtual machine,
it's not easy to send raw media data to client directly. In current
SPICE architecture, the video/audio media file firstly is decoded in
virtual machine, then captured by SPICE and sent to client using
algorithm MJPEG for video and CELT for audio.
Similar with RDP, SPICE supports transmission 2D graphic primitives
to client to fully re-use client computing resource and save
bandwidth. In current SPICE implementation, SPICE server also does
optimization for graphic commands by building up one graphic command
tree and removing un-necessary commands (for example, it is hidden by
other commands) to further saving bandwidth.
Caching for pixmaps, palettes and cursors are also defined in SPICE
in order to avoid redundant transmissions to the client. In current
implementation, the server is responsible for cache management, such
as add or remove from the cache. The client cache size is set by the
client and transferred to the server through the display channel
initialization message. The server monitors the current cache
capacity and when it lacks space it removes the least recently used
cache items until there is enough available cache space. The server
sends an invalidate command with these items and the client removes
them. In rendering-related messages, corresponding cache id will be
specified instead of carrying over actual image data.
3.3.2.3. User experience improvement
SPICE defines a framework to support interactive operation between
client and server based on techniques described in pervious section.
For service like device redirection, SPICE protocol currently has no
definition. But SPICE community has plan and is going on for
following:
1. Network tunneling: using virtual network interface to enable
sharing of network resources. Currently the focus is on printer
sharing but is not limited to that;
2. USB sharing: allows clients to share their USB devices with SPICE
servers. USB sharing is currently supported already in the
official RHEV versions, through a proprietary component. An open
source replacement for this is coming along nicely.
Ma, et al. Expires November 14, 2011 [Page 23]
Internet-Draft survey of VDI System May 2011
3.4. ICA
3.4.1. Introduction
Independent Computing Architecture is a proprietary protocol for an
application server system, designed by Citrix Systems. The protocol
lays down a specification for passing data between server and
clients, but is not bound to any one platform. The ICA protocol is
used within several of Citrix's products to provide desktop
virtualization across many different platforms. The three specific
Citrix products utilizing ICA are WinFrame, XenApp and XenDesktop.
The main purpose of these products is to allow a centralized set of
Microsoft Windows based servers to deliver Windows applications/
virtual machines to users on various platforms such as Linux, UNIX,
MacOS and even Windows CE.
3.4.2. ICA Protocol
3.4.2.1. Basic architecture
From perspective of 7-Layer OSI model, ICA is one protocol on
Presentation layer, which is defined for services like, data
conversion, compression, decompression, encryption, decryption and
etc.
Well known ports 1494/UDP/TCP and 2598/UDP/TCP are the two primary
ports used for the ICA protocol. Over these ports, the ICA protocol
handles the transmission of data between the client and the server.
Data transfer from the client to the server generally includes mouse
movement, events and other requests. Data transfers from the server
to the client generally involve a high-level view of the display
rather than a full image of the screen, dramatically saving bandwidth
and reducing the dependency on latency.
ICA protocol also uses channel-based architecture. It is comprised
of 32 virtual channels and each channel with a default priority. QoS
is provided based on prioritization and less important data is
sacrificed if necessary.
3.4.2.2. Bandwidth saving and User experience improvement
Since ICA is Citrix's proprietary protocol, more detailed information
like how compression is defined is Citrix's secret.
From Citrix's product view, Citrix provides HDX technology to deliver
a "high definition" desktop virtualization user experience to end
users for any application, device or network. These user experience
enhancements balance performance with low bandwidth - anything else
Ma, et al. Expires November 14, 2011 [Page 24]
Internet-Draft survey of VDI System May 2011
becomes impractical to use and scale. HDX technology provides
network and performance optimizations to deliver the best user
experience over any network, including low bandwidth and high latency
WAN connections.
3.5. RFB
3.5.1. RFB Protocol
3.5.1.1. Basic architecture
RFB protocol adopts server-client architecture. The remote endpoint
where the user sits (typically with a display, keyboard, and pointer)
is called the RFB client or viewer. The endpoint where changes to
the framebuffer originate (i.e., the windowing system and
applications) is known as the RFB server. RFB protocol works at the
framebuffer level, which means that pixel information is transferred
instead of graphics commands between RFB server and RFB client. In
this way, it makes RFB a "thin client" protocol, which has very few
requirements of the client. Thus RFB clients can run on the widest
range of hardware, and the task of implementing a client is made as
simple as possible.
RFB protocol depends on one reliable transport layer. From current
practice, it usually operates over a TCP/IP connection. During
initialization, client will setup one TCP connection with server.
After that, all information is carried over this connection. This is
different with SPICE or RDP, which defines several logical channels
and each channel has one corresponding TCP connection.
In current RFB protocol, two kinds of information are defined to be
exchanged between server and client:
o Inputs: The input side of RFB protocol is based on a standard
workstation model of a keyboard and multi-button pointing device.
Input events are simply sent to the server by the client whenever
the user presses a key or pointer button, or whenever the pointing
device is moved. These input events can also be synthesized from
other non-standard I/O devices. For example, a pen-based
handwriting recognition engine might generate keyboard events.
o Display: The display side of RFB protocol is based around a single
graphics primitive: "put a rectangle of pixel data at a given x,y
position" whenever the server found there is change in the
framebuffer or it is requested by the client explicitly. In
existing implementation, there are two practices for the server to
find out there is change in framebuffer: a) the server
periodically pulls the data from the framebuffer and compares it
Ma, et al. Expires November 14, 2011 [Page 25]
Internet-Draft survey of VDI System May 2011
with previous one. Obviously this is computing resource consuming
and not effective; b) The server utilizes mirror driver
functionality in Windows OS. It depends on notification from
mirror driver whenever there is change in framebuffer.
For RFB protocol, it has three ways for extension: a) adding new
encodings or pseudo encodings; b) adding new security types; c)
adding new message definitions. The former two methods work like the
plug-in mechanism and will not result in RFB protocol version
upgrade.
In RFB protocol, only VNC authentication method is defined. The work
flow is: 1) The server sends a random 16-byte challenge; 2) The
client encrypts the challenge with DES, using a password supplied by
the user as the key. To form the key, the password is truncated to
eight characters, or padded with null bytes on the right; 3) The
server verifies the response from client. Beside this default
security method, the client and server might also agree to use an
extended security type to encrypt the session, or the session might
be transmitted over a secure channel such as IPsec or SSH.
3.5.1.2. Bandwidth saving and User experience improvement
As described before, the display side of RFB protocol is based around
a single graphics primitive: "put a rectangle of pixel data at a
given x,y position". This might seem an inefficient way of drawing
many user interface components. However, allowing various different
encodings for the pixel data gives us a large degree of flexibility
in how to trade off various parameters such as network bandwidth,
client drawing speed, and server processing speed.
Current encoding algorithms defined in the standard includes:
CopyRect Encoding, RRE Encoding, Hextile Encoding, TRLE and ZRLE.
The core idea of these encodings is to combine different compression
techniques, like palettization/run-length encoding/zlib, to compress
the pixel data.
4. Conclusion
Through the survey of several VDI products, we found the common key
components of VDI architecture:
1. Desktop client: The software installed on client devices. It
connects to virtual desktop over protocols such as RDP, ICA and
SPICE;
Ma, et al. Expires November 14, 2011 [Page 26]
Internet-Draft survey of VDI System May 2011
2. Virtual desktop agent: The agent is installed on virtual machine
for accepting the client's connection. Not all solutions have
same architecture. For instance, in Redhat's VDI solution, SPICE
server , which runs on host machine, plays this role and is
shared by all virtual machines on the server;
3. Virtual machine pool: Virtual machine pool provides computing
resource for virtual desktops. It launches new virtual machine
when new client connects to it. Virtual machine pool could
contain huge numbers of virtual desktops,so the pool should be
highly scalable and reliable;
4. Desktop connection broker. The broker manages desktop
connections. It chooses the best virtual machine for the user
according to some policy (such as load balance) and directs the
connection to virtual machine;
5. Access Gateway. Responsible for external client's access. It
authenticates external users and provides secure connections
between client and virtual desktop;
6. Authentication Server: Provides authentication for users. It can
be directory server or others.
To optimize user experience, all solutions adopt a set of
technologies, such as multimedia compress, image cache, device
redirection, client rending and adaptive bandwidth management. These
technologies ensure that virtual desktop users feel the desktop is
running locally.
There are two modes about how the client connects to virtual desktop:
1.The client connects to agent which is running on virtual machine.
In Citrix, Microsoft and VMware's solutions, there is a virtual
desktop agent on each virtual machine. The agent opens protocol
ports to wait for client's connection, and exchange information with
the client. This modes is shown in Figure 7:
Ma, et al. Expires November 14, 2011 [Page 27]
Internet-Draft survey of VDI System May 2011
+---------------------------+
| +-----------------------+ |
| | +------------------+ | | VDI protocol +------------+
| | | Virtual Desktop |--+-+---------------| VDI Client |
| | | Agent | | | +------------+
| | +------------------+ | |
| | Guest OS | |
| +-----------------------+ |
| Virtual Machine |
+---------------------------+
Figure 7 Agent on virtual machine
2.The client connects to agent which is running on host. In Redhat's
solution, for each virtual machineGBP[not]there is a SPICE server
playing the role of virtual desktop agent, which is installed on
host, instead of being installed in every virtual machine. The SPICE
server captures the virtual machine's screen information, and
transfers it to the client. This mode is shown in Figure 8
+---------------------+
| +-------+ |
| |Virtual| |
| |Machine| |
| +---+---+ |
| | |
| +---+---------+---+ | SPICE protocol +-------------+
| | SPICE Server |-+----------------| SPICE Client|
| +-----------------+ | +-------------+
| Host |
+---------------------+
Figure 8 Agent on host
For different VDI protocols, they have similarities from perspective
of functionality:
1. Support experience of operating local-computer when accessing
remote server, through defining multi-channels and each channel
is for one specific data type, like display/audio/input;
2. Enhance user experience through bandwidth saving techniques and
more value-added services like Plug-n-Play: 1) define framework
to support client and server negotiation of compression method
and cache management; 2) define different protocol extensions to
support different services, like device redirection; 3) define
framework for graphic command transmission for 2D and 3D
Ma, et al. Expires November 14, 2011 [Page 28]
Internet-Draft survey of VDI System May 2011
applications instead of large-size image.
Looking inside each protocol, they are different with each other,
especially for:
1. Since they are proposed by different vendors and targeted for
different purpose at initial time, detailed message and procedure
are totally different, even for the architecture. For example,
RDP is based on T.120, while SPICE is self-contained and ICA is
proprietary;
2. Compression codec definition in each framework is incompatible.
For example, NSCodec and RemoteFX codec are defined in RDP
framework for image compression, while SPICE uses GLZ/LZ/QUIC/
JPEG to compress the image;
3. Service definition completeness of each protocol is different.
RDP protocol currently contains rich extension for some services,
like file-system and device redirection, Plug-n-Play and etc.
For SPICE, the community is working hard on that to catch it up.
5. Acknowledgements
6. Security Considerations
Related security issues will be addressed in subsequent draft.
7. References
7.1. Normative References
[ITUT120] ITU, "ITU T.120", 2009,
<http://www.itu.int/rec/T-REC-T.120/en>.
[MCPP] Microsoft, "Windows Communication Protocols webpage",
2011, <http://msdn.microsoft.com/zh-cn/library/cc216513>.
[MSRDS] Microsoft, "Microsoft RDS webpage", 2011, <http://
www.microsoft.com/windowsserver2008/en/us/
rds-product-home.aspx>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[SPICE] Redhat, Spice project., "Spice remote computing protocol
Ma, et al. Expires November 14, 2011 [Page 29]
Internet-Draft survey of VDI System May 2011
definition v1.0", 2009.
[VMWARE] VMware, "VMware View webpage", 2011,
<http://www.vmware.com/products/view/>.
[XENDESKTOP]
Citrix, "Citrix XenDesktop webpage", 2011,
<http://www.citrix.com/xendesktop>.
7.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
Authors' Addresses
Suan Ma (editor)
ZTE Corporation
No.68 Zijinghua Road
Nanjing,
CN
Phone: +86 15950586953
Email: ma.suan@zte.com.cn
Liang Liang
ZTE Corporation
No.68 Zijinghua Road
Nanjing,
CN
Phone: +86 18913825360
Email: liang.liang12@zte.com.cn
Jun Wang
ZTE Corporation
No.68 Zijinghua Road
Nanjing,
CN
Phone: +86 13770604455
Email: wang.jun17@zte.com.cn
Ma, et al. Expires November 14, 2011 [Page 30]