The design of AppFabric borrows from a large number of previous and current researches on network architectures. AppFabric extends some of these ideas and combines several disparate key concepts to realize its goals of an open network architecture for service/application delivery.
• Content Distribution Networks (CDN): Unlike CDNs, AppFabric is designed for highly dynamic data that cannot be cached; or, when the data owner wants to keep complete control of their data and the data generation processes and cannot trust the CDN with full view of the data, e.g., in medical, banking, and defense applications. • Active Networks: In active networks [132], routers are required to execute code in
packet headers. The idea was never adopted by industry because no service provider will allow others code to run on its routers thereby relinquishing control of its routers to others. AppFabric is specifically designed to avoid this flaw. ISPs are always in complete control of their network. ISPs own the policies and control the translation and implementation of ASP specified rules in the forwarding plane.
• Rule-Based Forwarding (RBF): In RBF [111], which is also designed to avoid the flaws of active networks, packets carry rules that are processed in the forwarding plane to determine an action on the packet. Four possible actions are defined. These are: 1) drop the packet, 2) forward the packet over the underlying IP forwarding plane, 3) invoke a local router function, and 4) update an attribute in the packet. Again, the users directly control the ISPs routers behavior which may not be acceptable to the ISP. In contrast, packets do not carry any rules in the AppFabric data plane. All they will have is the application meta-tag which will allow the ISPs to handle the packet as agreed with the ASP in the control plane. Second, in the AppFabric data plane, the forwarding actions may change as soon as the state of the application server or the network changes. In RBF the receiver entity (that specifies the rules) cannot change the way packets are processed until the communicating entity asks for the rules again or the rule lifetime ends. The third di↵erence is that the AppFabric data plane allows specifying forwarding rules based upon application-level semantics such as packet flows, messages and application sessions while RBF is simply packet based. The flow-based
design allows a compute once, use many-times design for the forwarding plane. There are several other subtle di↵erences between these two architectures. We believe that AppFabric is a simple, robust, flexible, scalable, and more easily implementable and deployable design.
• Serval: Serval [90] is another recent work addressing the problem of accessing ge- ographically distributed services. Serval provides a point solution for accessing dis- tributed services through a service router infrastructure. The service router infras- tructure is similar to the requirement of outsourcing application-level routing in the AppFabric data plane. However, AppFabric provides a generic middlebox switching solution which allows flexible implementation of any service access mechanism by com- posing specific mechanisms such as CBR, load balancer, cluster fault-manager, etc. Also, OpenADN includes the application context into the switching abstraction. Other distinguishing features include support for switching across middlebox sequences both in the data and control planes and support for both sender and receiver policies. • Delegation Oriented Architectures: Delegation based architectures such as DOA
[139] proposed a mechanism for o↵-path, middlebox deployments. AppFabric provides a more fundamental primitives that will allow a more realistic approach to realize the requirements of application deployments.
• ALTO: More recently, the ALTO [56] working group at IETF is developing an application- layer traffic optimization service that will provide network information to applications to inform peer selection for P2P services, content delivery, mirror selection, etc. Net- work information provides only one set of parameters among others (cost of deploy- ment, usage patterns, application replication and partitioning) that inform application delivery policies in AppFabric. The ALTO architecture provides a subset of the services provided by AppFabric.
There have been several research e↵orts to motivate architectural changes to address the problem of adding explicit support for middleboxes into the Internet architecture. However, the non-standard network configuration techniques and support for forward and reverse proxies in HTTP somehow managed the show and curbed the motivation for adopting a general architectural change. We believe that in the context of cloud computing the problem is more urgent and di↵erent as application deployments move to third party infrastructures and have more dynamic and distributed deployments. None
of the previous proposals try to abstract out application-level semantics into standard representation for a generic and high-performance implementation while still preserving some richness of application diversity. Also, none of them o↵er any discussion on the control plane; and how application level policies may be enforced on third-party infrastructures.
In this chapter, we provided some background that will help the reader appreciate the mo- tivations that led to the di↵erent design choices in AppFabric. In the rest of this thesis, we will discuss the specific details of the AppFabric architecture, the design details and a proof-of-concept prototype implementation of the platform.
Chapter 3
AppFabric High-level Architecture
In this chapter we will present a high-level architecture of the AppFabric platform. The design of AppFabric has been motivated by the need to address some general issues and architectural deficiencies in current application delivery solutions. It is especially important that we address these issues now, in light of the recent advances in infrastructure virtualiza- tion technologies and a shift towards Software-Defined Infrastructures (SDI). We will discuss these issues and how AppFabric addresses them in more detail in this chapter.
The discussion in this chapter is divided in two parts. In the first part, we will discuss some of the high-level requirements that motivate our design. In the second part, we will discuss the high-level goals of the AppFabric architecture.