In Part 1 of this three-part series on cloud computing, we introduced you to the concept of reference points (RPs) as a means for software designers and network architects to better understand and address specific problems in the cloud communications infrastructure. Now let’s look at one of the most common communication paths within the cloud, the client-to-server reference point, and the challenges faced in delivering a high quality of experience for cloud service users.
The client-to-server RP corresponds to communication between a client device and the application server in the cloud. These reference points are labeled 1 and 6 in the diagram we shared with you last time (see figure below).
- continuity of connection
- loopback response from intermediate nodes
- trace of intermediate nodes on the path
- frame delay measurement
- frame loss measurement.
In addition, MEF services use Layer 2 Ethernet service definitions. This practice minimizes problems with migrating IP addresses across IP networks. As a result, the service can transparently switch to another computer with the same IP address in a different geographical location as long as they are connected using MEF EVC.
Server-to-server communication
Server-to-server communication occurs among the application servers within the cloud. This communication happens in very specific and well-defined scenarios. The server-to-server RP is shown at Point 2 in the figure above.
An example of server-to-server communication is when the application uses multiple geographically distributed machines to work together to accomplish certain intensive computing tasks. This is sometimes called clustered applications. Often these computers are collocated, and therefore the high bandwidth they require is relatively inexpensive to provision in a data center environment.
Another example of server-to-server communication requirements is when a virtual machine with applications running on it is migrated from one physical box to another. This may be done for load-balancing, maintenance, or other operational reasons. This presents a different communications challenge for the cloud network.
For a virtual machine to be moved smoothly and semi-transparently for the client, it is better to be moved with its IP address unchanged. This way the state of the TCP connection is preserved inside the networking stack and the communication may be resumed immediately after the virtual machine state image is transferred to another box. The fact that the IP address does not change means that servers must be connected at Layer 2, which fits well with the MEF Layer 2 communication model.
Bandwidth-wise, migration of a virtual machine usually requires communication of gigabytes of traffic between machines. If it is to be done within a reasonable amount of time, up to 1-Gbps sustained-rate bandwidth should be provided. No encryption of traffic is required in this case since the information is not application-specific and is communicated in a controlled cloud environment, often within the same room, building, or campus.
Future work
Communication technologies are key enablers of cloud computing. Protocols, traffic management, and control of wide-area communications are rapidly evolving. The reference points defined above are offered to facilitate discussion about communications within the cloud. Applying industry standard techniques to these reference points can assure cloud network designers and application developers robust application performance on cloud networks
More work is being done on cloud communications protocols. As cloud networks grow, new separations will occur between and among cloud elements. New cloud elements will arise. New and specialized APIs to connect cloud elements will be developed. These will also further integrate telco and Web applications into cloud networks.
However, there are already sufficient bandwidth and adequate traffic management techniques to ensure the continued growth of cloud networks. Looking out a few years, it is easy to imagine a time when cloud services become indispensable to business operations and to people’s daily activities.
Mannix O’Connor is director of technical marketing at MRV Communications. He was chair of the Access Working Group for the MEF and founding secretary of the IEEE 802.17 Working Group. Mannix is a coauthor of the recent book Delivering Carrier Ethernet, published by McGraw-Hill.
Vladimir Bronstein is an independent consultant and has more than 20 years’ experience in telecom and data networking as a systems architect and director of software engineering. His experience encompasses broadband access, optical networking, and wireline and wireless networking as well as cable technologies. He has several patents pending for his networking innovations and has participated in industry standardization activities.