How does your concept of collaboration apply to the emerging field of desktop virtualization? Desktop virtualization is another perfect example where we can no longer get by without some sort of collaboration between the users of the network and the network itself. There are two types of desktop virtualization today. You have the light client like Citrix, where you have a back end in the data center. The second area is running virtualization...
software like hypervisors on end stations to manage different environments and personas. That second [area] is where a huge number of opportunities [exist] to really simplify the experience for the end users. I don't think the model of virtualization that's used in the data center should directly apply to the desktop. It's a little bit too much administrative management. For me, if I'm an enterprise IT organization managing desktops, the value proposition lies in being able to create a corporate [desktop] image that I can secure and put in a virtual machine that can be locked up and managed. People can take it home on their laptop or have it on their desktop. But we can secure it properly so we don't have to worry about the data threat.
There is opportunity for success with collaboration between the hypervisor and the network. What we really want is that corporate image virtual machine to always be connected to the network in exactly the same way. In other words, to have that virtual machine think it is always on the corporate network, regardless of where it is -- Starbucks, at home, at a customer site. The way we do that is to have the networking function built into the hypervisor, which collaborates with the actual network outside to provide a VPN service, to have more knowledge about where it's connected, what its capability is so it can properly translate and communicate in the most efficient fashion. You have begun promoting this notion that enterprise networks and the people who manage them must start collaborating more with the consumers of network services. What do you mean by this?
I believe a new relationship between the users of the network and the network [itself] is going to be required going forward. It's really the result of convergence. We've all heard the term convergence, but what is the real impact of convergence as we move forward on some of these technologies? The real impact is the need for collaboration between users of the network and the network itself. Typically, we have a service provider-consumer kind of model. But what needs to take place as we add more capability into the network and converge on technologies is really more of a collaborative kind of environment rather than a provider-consumer environment.
One of the key thrusts of that is security. To me the next big thing in security is really about the vulnerabilities of the control system and securing the infrastructure and securing the end-to-end conversations. That brings a challenge of having the network do its normal operation of reverse engineering everything that flies through it in order to add advanced features. If you look at IDS, IPS or a firewall, all they do is get a packet and they try to reverse engineer where it came from and what happened so they can apply some kind of policy. As speeds go up and capabilities go up and encryption begins to show its face a little more, that just isn't a scalable model. So one of the key things that come up is collaboration between the network provider and the network consumer that is beyond the expectations of today. What does this collaboration look like?
You've got to look at the various services that the network is providing you and how you can ensure delivery of those services in order to get a sense of what the collaboration needs to look like. As we move toward more media-rich communication, there is obviously a need for a more finely grained quality of service (QoS) control. If you want to stream video or do video conferencing and even go down to the VoIP level, you need to have some differentiation of your traffic. Somehow, we need to first establish trust between the network and consumers of the network so they can begin that collaborative experience.
Maybe we will have something that is like the return of RSVP [Resource Reservation Protocol], but obviously without the scalability issues, where applications can signal to the network some of their intentions and their needs. If we do that in a secure fashion and establish trust between those two, we can reliably begin to put the controls in place to do that without the network having to reverse engineer everything. The applications work as they do and the network tries to figure out what they do. There's no requirement to converge the management schemes or to have a trusted conversation. But again, as we scale in performance and technology and the need to secure the infrastructure and secure conversations, that gets a little more challenging to implement.
You can look at this in the data center, another place where we are converging the infrastructure. We are trying to get both storage and compute running over Ethernet, and we're getting networking embedded in the server itself from virtualization. We have this need to collaborate on the management tools, collaborate on how things are provisioned, and what kind of requirements each application needs in order to provide the experience you need. This leads into the notion of converged data centers and converged Ethernet, which is emerging as a hot topic right now. What is ProCurve's approach to data center convergence, and what do networking professionals need to know about it?
We believe in a distributed model of computing and switching, not so much a centralized command and control. I think Cisco's UCS model is really all about making the network the command center for everything in the data center. They have all the traffic following that same path to the command center. You're forwarding everything up into the middle of the network so you can do your advanced networking on it. We believe in a much more distributed environment where we push more of the capability toward the edge of the network. We establish this collaborative environment between the hypervisors and the network. We've been pushing on the VEPA standard. And we've been pushing Flex-10 as a capability for multiplexing multiple servers over a single physical wire. We give people a choice of where they want their traffic delivered, and it's not mandated by a proprietary system. How will the need for more collaboration manifest itself in a converged data center and with converged Ethernet?
Today, we have network administrators who manage network and server administrators who are provisioning servers, and storage administrators doing that for storage, and all these guys have to collaborate to make the data center function properly. We recognize that data centers have processes and business functions aligned with those roles, and we're not trying to eliminate those roles by any means. What we're trying to do is optimize the relationships between those roles. At HP, with our FlexFabric vision, we're creating a common vision tool, and we're abstracting many of the functions within the data center so that different disciplines can manage and configure those abstractions from a common database.
For example, with Data Connection Manager from ProCurve, a network administrator can define the needs of a network connection -- what VLAN it is, what ACLs (access control lists) are associated with that, what routes and quality of service settings. We define all the networking knobs and parameters that give the right end experience, and we label that -- this connection type for Web servers or that connection type for SQL application servers. Then we plug that into a database. So there's this label that represents the network configuration. Then the server guy -- when he's provisioning the actual application and the server -- goes to that database and requests one of those types of connections. And all he has to do is say, "I need a database connection or Web server connection." He doesn't have to get into ACLs and VLANs and quality of service settings. Those have already been set up by the networking guy.
So our common tool allows these guys to collaborate and build provisioning off that. Over time, as we smooth out the implementation of that and get it into a resource where these guys can make it part of a business process, we can then streamline those business processes, and you can begin to conceive of an administrator who takes on a role [that is] more data center wide and not asked to be myopically compartmentalized into one discipline or another. You're still going to need network specialists, but perhaps at a higher layer we can streamline the process. How will ProCurve's products evolve to fit into the converged data center vision articulated by HP?
What we have today are traditional switches inside a blade enclosure. Then you have Virtual Connect that is helping to abstract for the security guy. Then you look at the industry technologies we are defining -- VEPA, Flex-10. You can imagine there is no reason not to have that all wrapped into a single function. So I want a switch -- a network function -- that is abstracted by the server to provide network interfaces or virtual system interfaces (VSIs) so that all the server guy needs to deal with is NICs. But he also has the right APIs, protocols and outward facing support for a network guy. So I can run the multi-pathing schemes; I can run routing if I need to; I have rich topology management, QoS settings and all that stuff. We will really combine those different functions that you see today into an independent product, and many of these features will become common capabilities. That will take time. We want to move customers easily with that. We want to make sure we have the right tools in place to make that migration seamless.