idnits 2.17.1 draft-ma-appsawg-vdi-survey-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (May 13, 2011) is 4725 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ITUT120' is defined on line 1294, but no explicit reference was found in the text == Unused Reference: 'MCPP' is defined on line 1297, but no explicit reference was found in the text == Unused Reference: 'MSRDS' is defined on line 1300, but no explicit reference was found in the text == Unused Reference: 'SPICE' is defined on line 1307, but no explicit reference was found in the text == Unused Reference: 'VMWARE' is defined on line 1310, but no explicit reference was found in the text == Unused Reference: 'XENDESKTOP' is defined on line 1313, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 1319, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Applications Area Working Group S. Ma, Ed. 3 Internet-Draft L. Liang 4 Intended status: Informational J. Wang 5 Expires: November 14, 2011 ZTE Corporation 6 May 13, 2011 8 Survey of Virtual Desktop Infrastructure System 9 draft-ma-appsawg-vdi-survey-00 11 Abstract 13 This document presents a survey of VDI (Virtual Desktop 14 Infrastructure) system. Current popular VDI solutions are focused 15 on, such as Microsoft RDS, Citrix XenDesktop, Redhat enterprise 16 virtualization for desktops and VMware View. By analyzing the 17 architecture and protocol flows of these solutions, the common 18 features of VDI architecture and protocol are summarized. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 14, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 56 1.2. Terminology and Abbreviation . . . . . . . . . . . . . . . 4 57 2. Survey of VDI System . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Citrix XenDesktop . . . . . . . . . . . . . . . . . . . . 6 59 2.2. Microsoft RDS . . . . . . . . . . . . . . . . . . . . . . 9 60 2.3. Redhat Enterprise Virtualization for Desktops . . . . . . 11 61 2.4. VMware View . . . . . . . . . . . . . . . . . . . . . . . 12 62 3. VDI Related Protocols . . . . . . . . . . . . . . . . . . . . 14 63 3.1. T.120 . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 3.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14 65 3.1.2. T.120 protocol suite . . . . . . . . . . . . . . . . . 14 66 3.1.2.1. Basic architecture . . . . . . . . . . . . . . . . 14 67 3.2. RDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 3.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 16 69 3.2.2. RDP protocol stack . . . . . . . . . . . . . . . . . . 16 70 3.2.2.1. Basic architecture . . . . . . . . . . . . . . . . 17 71 3.2.2.2. Bandwidth saving . . . . . . . . . . . . . . . . . 19 72 3.2.2.3. User experience improvement . . . . . . . . . . . 20 73 3.3. SPICE . . . . . . . . . . . . . . . . . . . . . . . . . . 21 74 3.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 21 75 3.3.2. SPICE Protocol . . . . . . . . . . . . . . . . . . . . 21 76 3.3.2.1. Basic architecture . . . . . . . . . . . . . . . . 21 77 3.3.2.2. Bandwidth saving . . . . . . . . . . . . . . . . . 23 78 3.3.2.3. User experience improvement . . . . . . . . . . . 23 79 3.4. ICA . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 80 3.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 24 81 3.4.2. ICA Protocol . . . . . . . . . . . . . . . . . . . . . 24 82 3.4.2.1. Basic architecture . . . . . . . . . . . . . . . . 24 83 3.4.2.2. Bandwidth saving and User experience 84 improvement . . . . . . . . . . . . . . . . . . . 24 85 3.5. RFB . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 86 3.5.1. RFB Protocol . . . . . . . . . . . . . . . . . . . . . 25 87 3.5.1.1. Basic architecture . . . . . . . . . . . . . . . . 25 88 3.5.1.2. Bandwidth saving and User experience 89 improvement . . . . . . . . . . . . . . . . . . . 26 90 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 94 7.1. Normative References . . . . . . . . . . . . . . . . . . . 29 95 7.2. Informative References . . . . . . . . . . . . . . . . . . 30 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 99 1. Introduction 101 Virtual desktop infrastructure (VDI) is the practice of hosting a 102 desktop operating system within a virtual machine (VM) running on a 103 centralized server. VDI provides services for users to access their 104 desktops remotely and users can choose PC, tablet computer or mobile 105 phone as the client device. The OS (Operating System) and 106 applications of the desktop are running on virtual machines which are 107 deployed in Data Center. All desktops are managed under a central 108 management system. 110 The benefits of VDI include reduction of IT cost and improvement of 111 security. Centralized desktop management makes IT maintenance tasks 112 more effective, for example backup and upgrade can be done on Data 113 Center side. Since enterprise's data is kept in Data Center, it will 114 not be lost even when client devices are broken. Users can access 115 the data but can't copy it out of the datacenter, so the data 116 security is guaranteed. 118 The mainstream VDI products include Microsoft's RDS, Citrix's 119 XenDesktop, Redhat's Enterprise Virtualization for Desktops and 120 VMware's VMware View. The architecture, features and VDI protocols 121 of these products are analyzed in this document. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 1.2. Terminology and Abbreviation 131 o Device redirection: In VDI system, remote desktop must provide the 132 same user experience as local desktop, so the physical interfaces 133 of client device, such as USB, audio/video interface and serial/ 134 parallel ports should be accessed by Guest OS on remote desktop. 135 So client device's interfaces must be redirected to remote virtual 136 machine. 138 o GCC: Generic Conference Control 140 o GPU: Graphic Processor Unit 142 o Guest OS: An OS runs on top of a virtual machine manager. 144 o HDX: High-Definition user eXperience 145 o ICA: Independent Computing Architecture 147 o MCS: Multipoint Communication Service 149 o OS: Operation System 151 o PDU: Protocol Data Unit 153 o RD: Remote Desktop 155 o RDP: Remote Desktop Protocol 157 o RDS: Remote Desktop Service 159 o Resource pool: Resource pool is based on a large quantity of 160 physical server. The computing and storage resources of the 161 servers are managed as a whole, and it is a logical resource pool 162 to users. Users need not to know which server the resource is on 163 when he use it. Resource pool can improve resource's utilization 164 and scalability, and resource will be managed more effectively. 166 o RFB: Remote Framebuffer 168 o SPICE: Simple Protocol for Independent Computing Environment 170 o TPKT: ISO transport services on top of the TCP 172 o VDA: Virtual Desktop Agent, which acts as the bridge between 173 virtual machine and VDI client, such as accepting VDI connection, 174 taking input from VDI client, transferring graphics output of 175 virtual machine to VDI client and etc. 177 o VDI: Virtual Desktop Infrastructure 179 o VM: Virtual machine is a logical machine. Several virtual 180 machines can share one physical machine's resource. The virtual 181 CPU, memory and storage are allocated from physical resource by 182 virtualization layer software, and they can be scheduled under 183 certain policy. 185 o VMM: Virtual Machine Manager 187 2. Survey of VDI System 189 Remote terminal technology was brought into market very early, such 190 as X-WINDOW, Microsoft's Terminal Services and RealVNC's VNC. Early 191 products are used for server sharing, remote collaboration, and 192 remote control. The messages transferred between server and client 193 contain screen images and the keyboard/mouse events. VDI inherits 194 from the remote terminal technology, with exception that the desktops 195 are not running on physical servers, but in virtual machines. 196 Virtual machines can be allocated on demand, so VDI is more flexible 197 and has higher resource utilization. VDI also adopts variety of 198 technologies to improve user experience, such as enhanced desktop 199 display quality, supporting for USB/audio/video device redirection 200 and etc. 202 2.1. Citrix XenDesktop 204 XenDesktop is Citrix's VDI solution. For Guest OS in XenDesktop, it 205 could only be Microsoft's Windows. For Client device, it could 206 support different platforms, like Windows, Linux and Mac OS. 207 Virtualization platform can be Citrix's XenServer, or 3rd party's 208 products, such as Microsoft Hyper-V and VMware ESX. The protocol 209 between client and server is ICA (Independent Computing 210 Architecture). 212 The architecture of XenDesktop is shown in Figure 1: 214 +-----------+ 215 | Desktop | 216 | Delivery | 217 | Controller| 218 /+-----+-----+ 219 / | 220 +----------+ +----------+/ +-----+-----+ +--------------+ 221 | Desktop |--| Access |---| +-------+ | | Application | 222 | Receiver | | Gateway | | |Virtual| |---| Delivery | 223 +----------+ +----------+ | |Desktop| | | Controller | 224 | | +-------+ | +--------------+ 225 +-----+-----+ | XenServer | +--------------+ 226 | Active | | Resource |---| Provisioning | 227 | Directory | | Pool | | Server | 228 +-----------+ +-----------+ +--------------+ 230 Figure 1 XenDesktop architecture 232 The key components of XenDesktop: 234 1. Desktop Receiver: The client-side software, which is running on 235 client devices, connects to remote desktop through ICA protocol. 237 2. Access Gateway: Responsible for external user authentication. 238 Before the external user accesses the desktop, he must connect to 239 the Access Gateway and pass the authentication. External users's 240 connection to Access Gateway is secured by SSL. 242 3. Desktop Delivery Controller: Responsible for management of 243 virtual desktop and client connection. When a virtual desktop 244 boots up, it will register with Desktop Delivery Controller. 245 Desktop Delivery Controller will maintain the state of the 246 desktop. When a client initiates a connection, Desktop Delivery 247 Controller chooses an appropriate virtual desktop to connect. 248 Finally it forwards the client's connection to the desktop. 250 4. XenServer Resource Pool: XenServer is Citrix's virtualization 251 platform, provides virtual machine for virtual desktop and 252 manages all of the virtual machines. 254 5. Provisioning Server: Responsible for providing OS images. OS 255 images contain pre-configured profile, but applications are not 256 included. When virtual desktop boots up, the OS image will be 257 sent to virtual machine over network. 259 6. Application Delivery Controller: Responsible for application 260 delivery. User's profile contains assigned application list, and 261 user can choose which application to load. 263 7. Virtual Desktop Agent: Running on virtual desktop, which accepts 264 the ICA connection from client. 266 8. Active Directory: Responsible for user authentication. 268 Besides above specific components, additional general components 269 could be deployed, such as License server, DNS Server, DHCP Server 270 and so on. 272 Before users access their virtual desktops, they must pass the 273 authentication. Following is the procedure: 275 1. User launches the browser, and connects to Access Gateway. 276 Access Gateway generates the login page; 278 2. User inputs credentials, and Access Gateway authenticates the 279 user's credentials against Active Directory; 281 3. Upon successful authentication, Access Gateway connects to 282 Desktop Delivery Controller; 284 4. Desktop Delivery Controller retrieves the credentials from Access 285 Gateway, and authenticates the user against Active Directory; 287 5. After success authentication, Desktop Delivery Controller 288 determines which virtual desktops are available for the user; 290 6. Access Gateway creates a web page containing a list of virtual 291 desktops for the user, and sends the web page to user's browser. 293 After successful authentication, user can access virtual desktop by 294 clicking the icon on the web page. Following is the procedure: 296 1. User clicks the virtual desktop's icon on the web page, Access 297 Gateway sends the information to Desktop Delivery Controller; 299 2. Desktop Delivery Controller checks the status of user's virtual 300 desktop. If there is no available desktop, Desktop Delivery 301 Controller will request XenServer to launch one. The desktop 302 then opens the ICA port to wait for client connections; 304 3. Desktop Delivery Controller creates an ICA file for the virtual 305 desktop, and transfers the file to Access Gateway. Then Access 306 Gateway transfers the ICA file to VDI client; 308 4. After receiving the ICA file, VDI client executes it and sends a 309 connection request to Access Gateway; 311 5. Access Gateway forwards the connection request to virtual 312 desktop; 314 6. When detecting the connection request, the virtual desktop sends 315 the logon information to Desktop Delivery Controller for 316 validation; 318 7. For valid validation, Desktop Delivery Controller fetches a 319 license from the license server and sends credentials and license 320 to virtual desktop. The connection is created after virtual 321 desktop logon against Active Directory with the credentials. 323 To optimize user experience, XenDesktop provides HDX (High Definition 324 eXperience) technology. HDX contains several techniques as 325 following: 327 1. HDX MediaStream: Optimized for multimedia stream, the compressed 328 multimedia packages are transferred in raw format to client 329 device, and the client device plays them locally; 331 2. HDX RealTime: Enhances real-time voice and video using advanced 332 encoding and streaming to ensure a no compromise end-user 333 experience; 335 3. HDX Broadcast: Optimized for bandwidth to ensure high-performance 336 of virtual desktops and applications over any network, including 337 high-latency and low-bandwidth environments. User can set 338 bandwidth limits and close some features to save bandwidth; 340 4. HDX Plug-n-Play: Enables devices redirection for USB, printers 341 and peripherals; 343 5. HDX RichGraphics: Optimizes for 2D/3D applications by using the 344 rending ability of server and client; 346 6. HDX WAN Optimization: Adopts compression and cache technologies 347 to reduce bandwidth on the WAN. 349 2.2. Microsoft RDS 351 RDS (Remote Desktop Service) is next-generation product of Microsoft 352 TS (Terminal Service). In Windows server 2008 R2, it is named as 353 RDS. The protocol used in RDS between desktop client and server is 354 RDP (Remote Desktop Protocol). 356 The architecture of RDS is presented in Figure 2: 358 +----------+ +----------+ +-----------+ +--------------+ 359 | RD |--| RD +---| RD |----| RD | 360 | Client | | Gateway | | Connection|\ |Virtualization| 361 +----------+ +----------+ | Broker | \ | Host | 362 +-----+-----+ \ +--------------+ 363 | \ 364 +-----+-----+ +--------------+ 365 | Active | | RD Session | 366 | Directory | | Host | 367 +-----------+ +--------------+ 369 Figure 2 RDS architecture 371 The key components in RDS: 373 1. RD Client: Remote desktop client software running on client 374 devices, which connects to virtual desktop using RDP protocol; 376 2. RD Gateway(RDG): RD Gateway authorizes external RD clients and 377 provides secure connection for external RD client to access 378 virtual desktop; 380 3. RD Connection Broker (RDCB): Responsible for assigning correct 381 resource to RD clients and session load balancing. User can have 382 a personal desktop, which means that the RDCB assigns the same 383 virtual machine to the user whenever he logins. RDCB also can 384 assign virtual machine dynamically. When user logs on, RDCB 385 selects one from virtual machine pool and assign it to user. 386 Every user shares the same virtual machine image; 388 4. Remote Desktop Session Host (RDSH): Responsible for hosting 389 windows-based programs or the full Windows desktop for RD 390 clients. Users can connect to an RD Session Host server to run 391 programs, save files, and use network resources on that server; 393 5. RD Virtualization Host(RDVH): RDVH integrates with Hyper-V to 394 provide virtual machines for virtual desktops; 396 6. Active Directory: Responsible for user access authentication. 398 The connection procedure for RD Client is shown as below: 400 1. A RD Session Host works as a RD Redirector. When a client 401 connects to RD Redirector, RD Redirector forwards the connection 402 to RD Connection Broker; 404 2. RD Connection Broker queries personal desktop configuration from 405 Active Directory; 407 3. RD Connection Broker retrieves user's virtual machine from RD 408 Virtualization Host. If user's virtual machine is not running, 409 RD Virtualization Host will launch it; 411 4. RD Connection Broker returns the information of virtual machine 412 to RD Redirector; 414 5. RD Redirector forwards the information to RD Client,and redirects 415 RD Client to virtual machine; 417 6. RD Client connects to virtual machine. 419 To improve user experience, RDS provides RemoteFX technology in RDP 420 7.1. RemoteFX contains a set of features shown as following: 422 1. Host side rendering: Allows graphics to be rendered on the host 423 device instead of the client device. This enables support for 424 all graphics types by sending highly compressed bitmap images to 425 the endpoint device in an adaptive manner. This also allows the 426 applications to run at full speed on the host computer by taking 427 advantage of the GPU and the CPU, providing an experience which 428 is similar to that of a local computer; 430 2. GPU virtualization: Supports several virtual GPU with one 431 physical GPU, and each virtual GPU is used by one virtual 432 machine; 434 3. Intelligent Screen Capture: Only the screen change will be 435 encoded and transferred to client. Intelligent Screen Capture 436 also tracks network speed and then dynamically adjusts according 437 to the available bandwidth; 439 4. RemoteFX Encoder: Allows encoding to be done either on the 440 processor, GPU, or dedicated hardware; 442 5. RemoteFX Decoder: Decodes bitmaps on the client computer which 443 have been remoted from the virtual desktop to the client 444 computer. The client computer can decode by using software in 445 the GPU, processor, or by using a hardware decoder; 447 6. USB device redirection: Supports all usb devices redirection over 448 RDP, no client side drivers needed. 450 2.3. Redhat Enterprise Virtualization for Desktops 452 Redhat Enterprise Virtualization for Desktops is Redhat's VDI 453 solution,which supports both Windows and Linux desktop. The protocol 454 between client and desktop is SPICE (Simple Protocol for Independent 455 Computing Environment). 457 The architecture of Redhat Enterprise Virtualization for Desktops is 458 shown in Figure 3: 460 +--------+ SPICE +-------------------------+ 461 | SPICE |-------| Redhat Enterprise | 462 | Client | \ |Virtualization Hypervisor| 463 +--------+ \ +------------+------------+ 464 \ | 465 \ +------------+------------+ +---------------+ 466 \ | Redhat Enterprise |---|LDAP Directory/| 467 \|Virtualization Manager | |Active Directoy| 468 +-------------------------+ +---------------+ 470 Figure 3 Redhat Enterprise Virtualization for Desktops architecture 472 The key components of Redhat Enterprise Virtualization for Desktops: 474 1. SPICE client: The client side software installed on client 475 devices, which connects to virtual desktop using SPICE protocol; 477 2. SPICE Protocol: An open source VDI protocol, used between SPICE 478 client and virtual desktop; 480 3. Red Hat Enterprise Virtualization Hypervisor(RHEV-H): Redhat 481 virtualization platform to provide virtual machine for virtual 482 desktops; 484 4. Red Hat Enterprise Virtualization Manager(RHEV-M): Management 485 System for all components in Redhat's VDI solution; 487 5. LDAP Directory/Active Directory: Responsible for authentication. 489 The connection procedure for SPICE client is described as below: 491 1. User launches browser and connects to RHEV-M, and RHEV-M returns 492 a logon page. Then user inputs corresponding ID and password 493 information; 495 2. RHEV-M authenticates user against Active Directory; 497 3. After successful authentication, RHEV-M returns a web page 498 containing a list of available virtual desktops for the user; 500 4. User selects the desktop by clicking the icon on the web page. 501 Then RHEV-M requests RHEV-H to run the specified virtual desktop; 503 5. The SPICE client connects to the virtual desktop with SPICE 504 protocol. 506 2.4. VMware View 508 VMware View is VMware's virtual desktop solution, which uses VMware 509 vSphere as the virtualization platform. VMware View supports several 510 VDI protocols, like Microsoft RDP, PCoIP and HP RGS protocols. For 511 HP RGS, it can only be used for connecting HP Blades. 513 The architecture of VMware View is shown in Figure 4. 515 +----------+ +----------+ +-----------+ 516 | View | | View + | | 517 | Client |--|Connection|---| vSphere | 518 | | | Server | | | 519 +----------+ +-----+----+ +-----+-----+ 520 | | 521 +-----+-----+ +-----+-----+ 522 | Active | | vCenter | 523 | Directory | | Server | 524 +-----------+ +-----------+ 526 Figure 4 VMware View architecture 528 The key components of VMware View: 530 1. View client: The client software for accessing View desktops, 531 which runs either on a Windows or Mac PC as a native application 532 or on a thin client; 534 2. View Connection Server: View Connection Server acts as a broker 535 for client connections. It authenticates users through Active 536 Directory and directs the request to the appropriate virtual 537 machine; 539 3. vSphere: The virtualization platform, which provides virtual 540 machines for virtual desktops; 542 4. vCenter Server: Management System for configuration, deployment 543 and virtual machine management; 545 5. View Agent: View Agent is installed on all virtual machines. 546 This agent communicates with View Client to provide features such 547 as connection monitoring, virtual printing, and access to locally 548 connected USB devices; 550 VMware View has following features: 552 1. VMware View supports USB, printers and other peripherals 553 redirection; 555 2. Users can configure the amount of bandwidth used by Adobe Flash 556 content to improve the overall Web browsing experience and make 557 other applications more responsive; 559 3. VMware View supports multimedia redirection, and the media file 560 is send to client to be decoded locally; 562 4. VMware View supports single-sign-on, which means that users need 563 to log in only once to access virtual desktop; 565 5. Besides Active Directory authentication, VMware also supports RSA 566 SecurID and Smart Card authentication. 568 3. VDI Related Protocols 570 In this section, current hot-discussed VDI protocols, like RDP, SPICE 571 and ICA, are investigated. For closed protocol, such as ICA, the 572 information is collected from published documents on Internet. For 573 each protocol, they are organized from perspective of: Basic 574 architecture, Bandwidth saving and User experience improvement. 575 Bandwidth saving and User experience improvement are two key factors 576 for VDI protocol success. 578 3.1. T.120 580 T.120 is listed here for better understanding of Microsoft's RDP, 581 which is described in next section. 583 3.1.1. Introduction 585 The T.120-series Recommendations, which are issued by ITU, 586 collectively define a multipoint data communication service for use 587 in multimedia conferencing environments. Depending on the type of 588 T.120 implementations, the result product can make connections, 589 transmit and receive data, and collaborate using compatible data 590 conferencing features, such as program sharing, whiteboard 591 conferencing, and file transfer. 593 The key functionalities of T.120 are: 595 1. Establish and maintain conferences without any platform 596 dependence; 598 2. Manage multiple participants and programs; 600 3. Send and receive data accurately and securely over a variety of 601 supported networking connections. 603 3.1.2. T.120 protocol suite 605 3.1.2.1. Basic architecture 607 The T.120 system model is comprised of a communications 608 infrastructure and the application protocols that make use of it. 610 Figure 5 shows the full model with both standardized and non- 611 standardized applications. 613 +-------------------------------------------------------------+ 614 | User applications | 615 +-------------------------------------------------------------+ 616 | | 617 +------------------+ +------------------+ 618 | Standard appl. | |Non-standard appl.| 619 | protocol entity | | protocol entity | 620 +------------------+ +------------------+ 621 +-------|----------|-----------------------|----------|--------+ 622 | | +---------------------------------+ | | 623 | | | Generic conference control(GCC) | | | 624 | | | ITU Rec. T.124 | | | 625 | | +---------------------------------+ | | 626 | | | | | 627 | | | | | 628 | +---------------------------------------------------------+ | 629 | | Multipoint communication service(MCS) | | 630 | | ITU-T Recs T.122 and T.125 | | 631 | +---------------------------------------------------------+ | 632 | | | 633 | +---------------------------------------------------------+ | 634 | | Network-specific Transport protocols | | 635 | | ITU-T Rec. T.123 | | 636 | +---------------------------------------------------------+ | 637 | | 638 | ITU-T Rec. T.120 infrastructure Recommendations | 639 +--------------------------------------------------------------+ 641 Figure 5 T.120 protocol 643 Generally, each layer provides services to the layer above and 644 communicates to its peer(s) by sending Protocol Data Units (PDUs) via 645 services provided by the layer below. The lower level layers (T.122, 646 T.123, T.124, and T.125) specify an application-independent mechanism 647 for providing multipoint data communication services to any 648 application that can use these facilities. The upper level 649 application layers define protocols, such as shared white boarding 650 and multipoint file transfer. Applications using these standardized 651 protocols can co-exist in the same conference with applications using 652 proprietary protocols. 654 Following is one brief description of each protocol: 656 1. T.121: T.121 provides a template for T.120 resource management 657 that developers should use as a guide for building application 658 protocols. It also provides guidance to user application 659 developers on how to utilize the T.120 infrastructure in a 660 coherent and consistent way; 662 2. T.122:T.122 defines the multi-point services available to the 663 developer. Together with T.125, they form MCS, the multi-point 664 "engine" of the T.120 conference. MCS relies on T.123 to 665 actually deliver the data. MCS is a powerful tool that can be 666 used to solve virtually any multi-point application design 667 requirement; 669 3. T.123: T.123 specifies transport profiles for different transport 670 networks like, Public Switched Telephone Networks (PSTN), 671 Integrated Switched Digital Networks (ISDN), TCP/IP and etc. 672 From perspective of MCS layer, it presents a uniform OSI 673 transport interface and services (X.214/X.224). Built-in error 674 correction facilities are also included in this layer; 676 4. T.124:The T.124 specifies the Generic Conference Control (GCC), 677 which provides a comprehensive set of facilities for establishing 678 and managing the multi-point conference; 680 5. T.125: T.125 defines: 1) Procedures for a single protocol for the 681 transfer of data and control information from one MCS provider to 682 a peer MCS provider. 2) The structure and encoding of the MCS 683 protocol data units used for the transfer of data and control 684 information. 686 3.2. RDP 688 3.2.1. Introduction 690 Remote Desktop Protocol, which is issued by Microsoft, provides 691 remote display and input capabilities over network connections for 692 Windows-based applications running on a server. It is based on, and 693 is an extension of, the T-120 family of protocol standards. So it 694 inherits corresponding capabilities and benefits from T.120, such as 695 the architectural features necessary to support multipoint and 696 multipoint data delivery, which allows data from an application to be 697 delivered in "real-time" to multiple parties without having to send 698 the same data to each session individually. 700 3.2.2. RDP protocol stack 701 3.2.2.1. Basic architecture 703 As RDP is an extension of the core T.120 protocol, it re-uses 704 services from T.123, T.122, T.125 and T.124 of T.120 protocol suite. 705 In T.120 protocol architecture, RDP is at the same place of 706 application protocols. It defines application PDU for information 707 exchange between server and client, like capability set, bitmap 708 update, keyboard/mouse event and so on. 710 +---------------------------------------+ 711 | RDP Server | 712 | +----------------------------------+ | 713 | | RDP | | 714 | +----------------------------------+ | 715 | | | | 716 | | +----------------+ | +----+ 717 | | | GCC | | | C | 718 | | +----------------+ |--channel--| L | 719 | | | | |R I | 720 | +----------------------------------+ |--- ... --|D E | 721 | | MCS | | |P N | 722 | +----------------------------------+ |--channel--| T | 723 | | | | | 724 | +----------------------------------+ | +----+ 725 | | ISO transport protocol | | 726 | +----------------------------------+ | 727 | | | 728 | +----------------------------------+ | 729 | | TCP | | 730 | +----------------------------------+ | 731 +---------------------------------------+ 733 Figure 6 RDP protocol 735 RDP uses channel service provided by MCS layer for lossless 736 communication between client and server components over the main RDP 737 data connection. Each channel is targeted for one specific 738 application data, such as printer redirection, clipboard redirection 739 and etc. 741 There are two types of virtual channels in RDP: static virtual 742 channel and dynamic virtual channel. A maximum of 31 static virtual 743 channels can be created at connection time. The list of desired 744 virtual channels is requested and confirmed during the Basic Settings 745 Exchange phase of the server-client connection sequence and the 746 endpoints are joined during the Channel Connection phase. Virtual 747 channel data is application-specific and opaque to RDP. Each virtual 748 channel acts as an independent data stream. The client and server 749 examine the data received on each virtual channel and route the data 750 stream to the appropriate endpoint for further processing. Dynamic 751 virtual channel is put forward to solve the limitation of static 752 virtual channel number. It is implemented on top of a static virtual 753 channel named DRDYNVC. In the DRDYNVC static virtual channel, 754 different services could be allocated and deleted dynamically. 756 RDP supports two security classifications: standard RDP security and 757 enhanced RDP security: 759 1. For standard RDP security, client and server use matched 760 encryption and decryption keys for data security. The encryption 761 and decryption keys are generated during connection sequence, 762 based on random number generated on server and client. The 763 client and server both generate a 32-byte random value using a 764 cryptographically-safe pseudorandom number generator. Then the 765 server sends the random value which it generated (along with its 766 public key embedded in a certificate) to the client in the Server 767 Security Data during the Basic Settings Exchange phase of the 768 connection sequence. After receiving that, the client sends its 769 random value to the server (encrypted with the server's public 770 key) in the Security Exchange PDU as part of the RDP Security 771 Commencement phase of the connection sequence. As the client 772 doesn't authenticate server credential, this security method 773 could not protect data from man in-the-middle. It still exists 774 in RDP for backward compatibility; 776 2. For enhanced security, RDP traffic is no longer protected by 777 using the techniques described in standard RDP security. 778 Instead, all security operations (such as encryption and 779 decryption, data integrity checks, and server authentication) are 780 implemented by external security protocols, like TLS. In this 781 way, there is no longer need to manually implement protocol 782 security mechanisms, which is replaced with well-known and proven 783 security protocol packages to provide end-to-end security. 785 Server redirection procedure is defined in RDP for load-balancing 786 scenarios. A client connection can be redirected to a specific 787 session on another server by using the Server Redirection PDU. In 788 the Server Redirection PDU, necessary information is include, such as 789 session ID, redirection information flag, user credential 790 information, load balance information, target server address and etc. 791 When the client receives this redirection indication, it will 792 disconnect from current server and try to connect target server, 793 which is specified in Server Redirection PDU. 795 In RDP framework, it's flexible to define more service using separate 796 static/dynamic channel. 798 3.2.2.2. Bandwidth saving 800 RDP uses a bulk compressor to compress virtual channel data and some 801 data in PDUs sent from server to client. During information exchange 802 phase of the connection sequence, server and client negotiate the 803 bulk compressor. One version of the bulk compressor (the RDP 4.0 804 bulk compressor) is based on the Microsoft Point-To-Point Compression 805 (MPPC) Protocol and uses an 8 kilobyte history buffer. A more 806 advanced version of the compressor (the RDP 5.0 bulk compressor) is 807 derived from the RDP 4.0 bulk compressor, but uses a 64 kilobyte 808 history buffer and modified Huffman-style encoding rules. Besides 809 employing bulk compression for generic data, RDP also uses variations 810 of run length encoding (RLE) rules to implement compression of bitmap 811 data sent from server to client. "NSCodec Extension" and "RemoteFX 812 Codec Extension" (lossy image codec) specify the image codec that can 813 be used to encode screen images by utilizing efficient and effective 814 compression. 816 As RDP is one extension of T.120 protocols, each RDP packet will be 817 wrapped with corresponding headers defined in T.120 protocols, like 818 TPKT header, X.224 Class 0 Data TPDU and etc. In some situations, 819 for example point-to-point connection, these additional overhead is 820 not necessary. In RDP protocol, it defined two choices: slow-path 821 which follows strictly T.120 protocols and fast-path with the goal of 822 improving bandwidth. For fast-path, the TPKT Header, X.224 Class 0 823 Data TPDU, and MCS Send Data Indication are replaced. The Security 824 Header is collapsed into the fast-path output header, and the Share 825 Data Header is replaced by a new fast-path format. The contents of 826 the graphics and pointer updates are also changed to reduce their 827 size, particularly by removing or reducing headers. 829 The real-time display interaction is accomplished by continuously 830 sending updated bitmap images from server to client. Even though 831 these bitmaps may be compressed, it is still not a bandwidth 832 efficient mechanism to employ, especially when dealing with graphics- 833 intensive applications that refresh regularly. "GDI Acceleration 834 Extension" aims to reduce the bandwidth associated with graphics 835 remoting by encoding the drawing operations that produce an image 836 instead of encoding the actual image. For example, instead of 837 sending the bitmap image of a filled rectangle from server to client, 838 an order to render a rectangle at coordinate (X, Y) with a given 839 width, height, and fill color is sent to the client. The client then 840 executes the drawing order to produce the intended graphics result. 841 In addition to defining how to encode common drawing operations, "GDI 842 Acceleration Extension" also facilitates the use of caches to store 843 drawing primitives such as bitmaps, color tables, and characters. 845 The effective use of caching techniques helps to reduce wire traffic 846 by ensuring that items used in multiple drawing operations are sent 847 only once from server to client (retransmission of these items for 848 use in conjunction with future drawing operations is not required 849 after the item has been cached on the client). 851 For video and audio application, "Video Redirection Virtual Channel 852 Extension" and "Audio Output Virtual Channel Extension" define video 853 and audio delivery message and procedure between server and client. 854 Before stream traffic starts, server and client will exchange their 855 own capabilities, also for media format. After successful 856 negotiation, media stream data will be sent between server and client 857 with both agreed format, for example MPEG-2, instead of transferring 858 raw data. 860 3.2.2.3. User experience improvement 862 For VDI applications, user experience is very important for more 863 widely acceptance of this technology. When using client component to 864 access desktop on remote side, the user hopes to get experience of 865 using local computer, such as real-time interactive, plug-n-play 866 service, bi-directional multimedia services and etc. 868 In RDP protocol suite, it uses techniques mentioned in previous 869 "bandwidth saving" section to improve interactive capability and 870 multi-media services. 872 Following extension protocols are defined to mitigate environment 873 experience of server and client: 875 1. Clipboard Virtual Channel Extension: specifies how to keep two 876 distinct system clipboards in sync so that at any given time, the 877 data available to an application on one computer (via its local 878 clipboard) is identical to the data available to another 879 application on a remote computer (via its local clipboard); 881 2. Remote Programs Virtual Channel Extension: provides support to 882 present a remote application (running remotely on the server) as 883 a local user application (running on the client machine). It 884 extends the core RDP protocol to deliver this seamless windows 885 experience; 887 3. File System Virtual Channel Extension: provides support to 888 redirect access from the server to the client file system. In a 889 typical terminal server scenario, many of the nonvolatile 890 resources used by the server (such as hard drives, flash drives, 891 and floppy disks) are located on the client. The server exposes 892 a file system driver that is visible to server-based applications 893 as a hard drive, which allows the applications to access the 894 client file systems; 896 4. Serial Port Virtual Channel Extension: provides support to 897 redirect serial and parallel ports from client to the server. 898 This allows the server to access client ports as if the connected 899 devices were local to the server; 901 5. Print Virtual Channel Extension: provides support to redirect 902 printers from client to the server. This allows the server 903 access to printers physically connected to the client as if the 904 devices were local to the server; 906 6. Smart Card Virtual Channel Extension: is designed to remotely 907 execute requests on a client's Smart Cards for Windows. When 908 Smart Card Redirection is in effect, server application smart 909 card subsystem calls are automatically remapped to the 910 client"Cside Smart Cards for Windows, which will then receive the 911 corresponding request; 913 7. Plug and Play Devices Virtual Channel Extension: This protocol is 914 used to redirect Plug and Play (PNP) devices from client to the 915 server, for example USB devices. This allows the server access 916 to devices that are physically connected to the client as if the 917 device were local to the server. 919 3.3. SPICE 921 3.3.1. Introduction 923 SPICE was originally developed by Qumranet, which was acquired by Red 924 Hat in 2008. Later Redhat open sourced its SPICE hosted virtual 925 desktop protocol. Now open-source SPICE project aims to provide a 926 complete open source solution for interaction with virtualized 927 desktop devices. The SPICE protocol, acting similar functions as 928 Microsoft RDP, provides client and server communication to support 929 virtual desktop infrastructure. 931 3.3.2. SPICE Protocol 933 3.3.2.1. Basic architecture 935 SPICE protocol defines a set of protocol messages for accessing, 936 controlling, and receiving inputs from remote computing devices 937 (e.g., keyboard, video, and mouse) across networks, and sending 938 output to them. SPICE uses simple messaging and does not depend on 939 any RPC standard or a specific transport layer. 941 From architecture perspective, SPICE is architected a bit different 942 than RDP and ICA. While RDP and ICA are made of up two components (a 943 remote software component that runs in the OS of the Windows host 944 you're connecting to, and a client), SPICE is actually made up of 945 three components: 947 1. Remote guest component: A virtual graphics adapter running in the 948 VM, just like RDP/ICA 950 2. Client component; The SPICE client software, just like RDP/ICA; 952 3. Remote host component: A virtual graphics device which the 953 hypervisor makes available to the VM. 955 In other words, because SPICE has a hypervisor component, it will 956 only work when your remote hosts are VMs. 958 Similar with RDP, SPICE protocol spilt the communication session into 959 multiple communication channels. Currently the following 960 communication channels are defined in the protocol: a) the main 961 channel serves as the main spice session connection; b) display 962 channel for receiving remote display updates; c) inputs channel for 963 sending mouse and keyboard events; d) cursor channel for receiving 964 pointer shape and position; e) Playback channel for receiving audio 965 stream; f) Record channel for sending audio capture. More channel 966 types will be added as the protocol evolves. Since RDP is based on 967 T.120, it could use channel service from lower layer. But for SPICE, 968 it has to do channel management along with application protocols, 969 which may lead to some implementation complexity. 971 For user authentication in SPICE, the server generates a 1024 bit RSA 972 key and sends the public part to the client (via RedLinkInfo). 973 Client uses this key to encrypt the password and send it back to 974 server (after RedLinkMess). Server decrypt the password, compare it 975 to ticket. 977 SPICE doesn't define encryption mechanism in application layer, which 978 means that it depends on external security protocols for security 979 guarantee so that having maximum flexibility in choosing an 980 encryption method. 982 SPICE defines full server redirection primitives to support live 983 migration. RDP supports server redirection for load balance purpose, 984 which means server redirection only occurs during 1st server access. 985 SPICE could support server redirection during run-time and 986 corresponding migration process control. 988 3.3.2.2. Bandwidth saving 990 SPICE uses different compression strategy for different media 991 resource. It uses QUIC/LZSS/GLZ for lossless image compression. 992 QUIC (based on SFALIC) and GLZ (based on LZSS with a history-based 993 global dictionary) are Redhat proprietary algorithms. As the video/ 994 audio is played using different media player in the virtual machine, 995 it's not easy to send raw media data to client directly. In current 996 SPICE architecture, the video/audio media file firstly is decoded in 997 virtual machine, then captured by SPICE and sent to client using 998 algorithm MJPEG for video and CELT for audio. 1000 Similar with RDP, SPICE supports transmission 2D graphic primitives 1001 to client to fully re-use client computing resource and save 1002 bandwidth. In current SPICE implementation, SPICE server also does 1003 optimization for graphic commands by building up one graphic command 1004 tree and removing un-necessary commands (for example, it is hidden by 1005 other commands) to further saving bandwidth. 1007 Caching for pixmaps, palettes and cursors are also defined in SPICE 1008 in order to avoid redundant transmissions to the client. In current 1009 implementation, the server is responsible for cache management, such 1010 as add or remove from the cache. The client cache size is set by the 1011 client and transferred to the server through the display channel 1012 initialization message. The server monitors the current cache 1013 capacity and when it lacks space it removes the least recently used 1014 cache items until there is enough available cache space. The server 1015 sends an invalidate command with these items and the client removes 1016 them. In rendering-related messages, corresponding cache id will be 1017 specified instead of carrying over actual image data. 1019 3.3.2.3. User experience improvement 1021 SPICE defines a framework to support interactive operation between 1022 client and server based on techniques described in pervious section. 1023 For service like device redirection, SPICE protocol currently has no 1024 definition. But SPICE community has plan and is going on for 1025 following: 1027 1. Network tunneling: using virtual network interface to enable 1028 sharing of network resources. Currently the focus is on printer 1029 sharing but is not limited to that; 1031 2. USB sharing: allows clients to share their USB devices with SPICE 1032 servers. USB sharing is currently supported already in the 1033 official RHEV versions, through a proprietary component. An open 1034 source replacement for this is coming along nicely. 1036 3.4. ICA 1038 3.4.1. Introduction 1040 Independent Computing Architecture is a proprietary protocol for an 1041 application server system, designed by Citrix Systems. The protocol 1042 lays down a specification for passing data between server and 1043 clients, but is not bound to any one platform. The ICA protocol is 1044 used within several of Citrix's products to provide desktop 1045 virtualization across many different platforms. The three specific 1046 Citrix products utilizing ICA are WinFrame, XenApp and XenDesktop. 1047 The main purpose of these products is to allow a centralized set of 1048 Microsoft Windows based servers to deliver Windows applications/ 1049 virtual machines to users on various platforms such as Linux, UNIX, 1050 MacOS and even Windows CE. 1052 3.4.2. ICA Protocol 1054 3.4.2.1. Basic architecture 1056 From perspective of 7-Layer OSI model, ICA is one protocol on 1057 Presentation layer, which is defined for services like, data 1058 conversion, compression, decompression, encryption, decryption and 1059 etc. 1061 Well known ports 1494/UDP/TCP and 2598/UDP/TCP are the two primary 1062 ports used for the ICA protocol. Over these ports, the ICA protocol 1063 handles the transmission of data between the client and the server. 1064 Data transfer from the client to the server generally includes mouse 1065 movement, events and other requests. Data transfers from the server 1066 to the client generally involve a high-level view of the display 1067 rather than a full image of the screen, dramatically saving bandwidth 1068 and reducing the dependency on latency. 1070 ICA protocol also uses channel-based architecture. It is comprised 1071 of 32 virtual channels and each channel with a default priority. QoS 1072 is provided based on prioritization and less important data is 1073 sacrificed if necessary. 1075 3.4.2.2. Bandwidth saving and User experience improvement 1077 Since ICA is Citrix's proprietary protocol, more detailed information 1078 like how compression is defined is Citrix's secret. 1080 From Citrix's product view, Citrix provides HDX technology to deliver 1081 a "high definition" desktop virtualization user experience to end 1082 users for any application, device or network. These user experience 1083 enhancements balance performance with low bandwidth - anything else 1084 becomes impractical to use and scale. HDX technology provides 1085 network and performance optimizations to deliver the best user 1086 experience over any network, including low bandwidth and high latency 1087 WAN connections. 1089 3.5. RFB 1091 3.5.1. RFB Protocol 1093 3.5.1.1. Basic architecture 1095 RFB protocol adopts server-client architecture. The remote endpoint 1096 where the user sits (typically with a display, keyboard, and pointer) 1097 is called the RFB client or viewer. The endpoint where changes to 1098 the framebuffer originate (i.e., the windowing system and 1099 applications) is known as the RFB server. RFB protocol works at the 1100 framebuffer level, which means that pixel information is transferred 1101 instead of graphics commands between RFB server and RFB client. In 1102 this way, it makes RFB a "thin client" protocol, which has very few 1103 requirements of the client. Thus RFB clients can run on the widest 1104 range of hardware, and the task of implementing a client is made as 1105 simple as possible. 1107 RFB protocol depends on one reliable transport layer. From current 1108 practice, it usually operates over a TCP/IP connection. During 1109 initialization, client will setup one TCP connection with server. 1110 After that, all information is carried over this connection. This is 1111 different with SPICE or RDP, which defines several logical channels 1112 and each channel has one corresponding TCP connection. 1114 In current RFB protocol, two kinds of information are defined to be 1115 exchanged between server and client: 1117 o Inputs: The input side of RFB protocol is based on a standard 1118 workstation model of a keyboard and multi-button pointing device. 1119 Input events are simply sent to the server by the client whenever 1120 the user presses a key or pointer button, or whenever the pointing 1121 device is moved. These input events can also be synthesized from 1122 other non-standard I/O devices. For example, a pen-based 1123 handwriting recognition engine might generate keyboard events. 1125 o Display: The display side of RFB protocol is based around a single 1126 graphics primitive: "put a rectangle of pixel data at a given x,y 1127 position" whenever the server found there is change in the 1128 framebuffer or it is requested by the client explicitly. In 1129 existing implementation, there are two practices for the server to 1130 find out there is change in framebuffer: a) the server 1131 periodically pulls the data from the framebuffer and compares it 1132 with previous one. Obviously this is computing resource consuming 1133 and not effective; b) The server utilizes mirror driver 1134 functionality in Windows OS. It depends on notification from 1135 mirror driver whenever there is change in framebuffer. 1137 For RFB protocol, it has three ways for extension: a) adding new 1138 encodings or pseudo encodings; b) adding new security types; c) 1139 adding new message definitions. The former two methods work like the 1140 plug-in mechanism and will not result in RFB protocol version 1141 upgrade. 1143 In RFB protocol, only VNC authentication method is defined. The work 1144 flow is: 1) The server sends a random 16-byte challenge; 2) The 1145 client encrypts the challenge with DES, using a password supplied by 1146 the user as the key. To form the key, the password is truncated to 1147 eight characters, or padded with null bytes on the right; 3) The 1148 server verifies the response from client. Beside this default 1149 security method, the client and server might also agree to use an 1150 extended security type to encrypt the session, or the session might 1151 be transmitted over a secure channel such as IPsec or SSH. 1153 3.5.1.2. Bandwidth saving and User experience improvement 1155 As described before, the display side of RFB protocol is based around 1156 a single graphics primitive: "put a rectangle of pixel data at a 1157 given x,y position". This might seem an inefficient way of drawing 1158 many user interface components. However, allowing various different 1159 encodings for the pixel data gives us a large degree of flexibility 1160 in how to trade off various parameters such as network bandwidth, 1161 client drawing speed, and server processing speed. 1163 Current encoding algorithms defined in the standard includes: 1164 CopyRect Encoding, RRE Encoding, Hextile Encoding, TRLE and ZRLE. 1165 The core idea of these encodings is to combine different compression 1166 techniques, like palettization/run-length encoding/zlib, to compress 1167 the pixel data. 1169 4. Conclusion 1171 Through the survey of several VDI products, we found the common key 1172 components of VDI architecture: 1174 1. Desktop client: The software installed on client devices. It 1175 connects to virtual desktop over protocols such as RDP, ICA and 1176 SPICE; 1178 2. Virtual desktop agent: The agent is installed on virtual machine 1179 for accepting the client's connection. Not all solutions have 1180 same architecture. For instance, in Redhat's VDI solution, SPICE 1181 server , which runs on host machine, plays this role and is 1182 shared by all virtual machines on the server; 1184 3. Virtual machine pool: Virtual machine pool provides computing 1185 resource for virtual desktops. It launches new virtual machine 1186 when new client connects to it. Virtual machine pool could 1187 contain huge numbers of virtual desktops,so the pool should be 1188 highly scalable and reliable; 1190 4. Desktop connection broker. The broker manages desktop 1191 connections. It chooses the best virtual machine for the user 1192 according to some policy (such as load balance) and directs the 1193 connection to virtual machine; 1195 5. Access Gateway. Responsible for external client's access. It 1196 authenticates external users and provides secure connections 1197 between client and virtual desktop; 1199 6. Authentication Server: Provides authentication for users. It can 1200 be directory server or others. 1202 To optimize user experience, all solutions adopt a set of 1203 technologies, such as multimedia compress, image cache, device 1204 redirection, client rending and adaptive bandwidth management. These 1205 technologies ensure that virtual desktop users feel the desktop is 1206 running locally. 1208 There are two modes about how the client connects to virtual desktop: 1210 1.The client connects to agent which is running on virtual machine. 1211 In Citrix, Microsoft and VMware's solutions, there is a virtual 1212 desktop agent on each virtual machine. The agent opens protocol 1213 ports to wait for client's connection, and exchange information with 1214 the client. This modes is shown in Figure 7: 1216 +---------------------------+ 1217 | +-----------------------+ | 1218 | | +------------------+ | | VDI protocol +------------+ 1219 | | | Virtual Desktop |--+-+---------------| VDI Client | 1220 | | | Agent | | | +------------+ 1221 | | +------------------+ | | 1222 | | Guest OS | | 1223 | +-----------------------+ | 1224 | Virtual Machine | 1225 +---------------------------+ 1227 Figure 7 Agent on virtual machine 1229 2.The client connects to agent which is running on host. In Redhat's 1230 solution, for each virtual machineGBP[not]there is a SPICE server 1231 playing the role of virtual desktop agent, which is installed on 1232 host, instead of being installed in every virtual machine. The SPICE 1233 server captures the virtual machine's screen information, and 1234 transfers it to the client. This mode is shown in Figure 8 1236 +---------------------+ 1237 | +-------+ | 1238 | |Virtual| | 1239 | |Machine| | 1240 | +---+---+ | 1241 | | | 1242 | +---+---------+---+ | SPICE protocol +-------------+ 1243 | | SPICE Server |-+----------------| SPICE Client| 1244 | +-----------------+ | +-------------+ 1245 | Host | 1246 +---------------------+ 1248 Figure 8 Agent on host 1250 For different VDI protocols, they have similarities from perspective 1251 of functionality: 1253 1. Support experience of operating local-computer when accessing 1254 remote server, through defining multi-channels and each channel 1255 is for one specific data type, like display/audio/input; 1257 2. Enhance user experience through bandwidth saving techniques and 1258 more value-added services like Plug-n-Play: 1) define framework 1259 to support client and server negotiation of compression method 1260 and cache management; 2) define different protocol extensions to 1261 support different services, like device redirection; 3) define 1262 framework for graphic command transmission for 2D and 3D 1263 applications instead of large-size image. 1265 Looking inside each protocol, they are different with each other, 1266 especially for: 1268 1. Since they are proposed by different vendors and targeted for 1269 different purpose at initial time, detailed message and procedure 1270 are totally different, even for the architecture. For example, 1271 RDP is based on T.120, while SPICE is self-contained and ICA is 1272 proprietary; 1274 2. Compression codec definition in each framework is incompatible. 1275 For example, NSCodec and RemoteFX codec are defined in RDP 1276 framework for image compression, while SPICE uses GLZ/LZ/QUIC/ 1277 JPEG to compress the image; 1279 3. Service definition completeness of each protocol is different. 1280 RDP protocol currently contains rich extension for some services, 1281 like file-system and device redirection, Plug-n-Play and etc. 1282 For SPICE, the community is working hard on that to catch it up. 1284 5. Acknowledgements 1286 6. Security Considerations 1288 Related security issues will be addressed in subsequent draft. 1290 7. References 1292 7.1. Normative References 1294 [ITUT120] ITU, "ITU T.120", 2009, 1295 . 1297 [MCPP] Microsoft, "Windows Communication Protocols webpage", 1298 2011, . 1300 [MSRDS] Microsoft, "Microsoft RDS webpage", 2011, . 1304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1305 Requirement Levels", BCP 14, RFC 2119, March 1997. 1307 [SPICE] Redhat, Spice project., "Spice remote computing protocol 1308 definition v1.0", 2009. 1310 [VMWARE] VMware, "VMware View webpage", 2011, 1311 . 1313 [XENDESKTOP] 1314 Citrix, "Citrix XenDesktop webpage", 2011, 1315 . 1317 7.2. Informative References 1319 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1320 June 1999. 1322 Authors' Addresses 1324 Suan Ma (editor) 1325 ZTE Corporation 1326 No.68 Zijinghua Road 1327 Nanjing, 1328 CN 1330 Phone: +86 15950586953 1331 Email: ma.suan@zte.com.cn 1333 Liang Liang 1334 ZTE Corporation 1335 No.68 Zijinghua Road 1336 Nanjing, 1337 CN 1339 Phone: +86 18913825360 1340 Email: liang.liang12@zte.com.cn 1342 Jun Wang 1343 ZTE Corporation 1344 No.68 Zijinghua Road 1345 Nanjing, 1346 CN 1348 Phone: +86 13770604455 1349 Email: wang.jun17@zte.com.cn